Joel de Guzman wrote:

Tom Brinkman wrote:

...

The review of Generic Image Library (GIL) begins today, October 5, 2006, and continues through October 15, 2006.

I'd like to do a formal review of GIL. But, given the extent of the library and the time constraint, it's hard to do it on or before Oct 15. Is it possible to have an extension?

I second that request. I'm struggling to find some time to do the library justice, hopefully over the coming weekend. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of rasmus ekman Sent: Thursday, October 12, 2006 7:25 PM To: boost@lists.boost.org Subject: [boost] Review of Generic Image Library (GIL)

I vote that GIL is rejected this time.

This is not because I doubt the usefulness or quality of implementation, more due to the fact that there is at least one other generic library (Vigra), which covers much of the same field, that has been around longer, and supplies many more algorithms.

First of all, as far as we know we don't have a formal proposal from Vigra on the table, so we feel it is unfair to reject for this reason. This is like rejecting a job interview candidate because there is someone out there who is more knowledgeable. Will that other person be even interested in the job you are offering? Is knowledge the only skill you are looking for and, if not, does that other person have all other required skills? Will the current job candidate be interested in interviewing for your job again once rejected? Often not. Here is another perhaps more important question to the boost audience: If you have to make a choice, would you choose a library with a better design and a minimal set of existing algorithms or a library that has more stuff in it, but with not so good a design? Please note: We are NOT suggesting that Vigra has inferior design. In fact, we praise Vigra in our design guide. We refrain from comparison, at the very least, because Vigra is not even on the table. However, we want to address this logical question if design is more important than present functionality, because it seems to be in the basis for Rasmus's vote. A related question: Which one is easier - building new functionality on top of a solid design, or extending the design of a library with lots of existing algorithms that are built on top of the old design?

...

- What is your evaluation of the design?

The design is GIL's strong point. It provides useful extensions to STL iterators, reference views on data etc. Similar interfaces are provided also in other libraries, but GIL looks like being up to par (without doing detailed comparison with MTL, Blitz and others). It already uses Boost components, and claims STL compliance.

Thank you.

...

- What is your evaluation of the implementation?

The implementation also looks up to the task, for what it does. Everything I saw looks clean and is separated into small units. Naming is generally to the point. The systematic naming schemes are informative, but should be exposed more prominently in docs.

...

- What is your evaluation of the potential usefulness of the library?

GIL provides useful extensions to STL algorithms (copy, generate, transform), extended (multidimensional, strided) iteration support, non-ownership data views, and convenience classes for various color encodings.

This is very useful, but it does not provide full image processing. GIL lacks support for signal processing. Pixel images are just sample points of a continuous space. Therefore algorithms from numerical analysis are regularly used on images: FFT, convolution kernels for 2D filtering etc.

FYI, we do have image processing algorithms in our GIL numeric extension. You can do arbitraty affine transformations, nearest-neighbor and bilinear resampling and convolution. It has no external dependencies, so if you need this stuff you can use it even if not in boost. It is not currently part of the review, but if GIL makes it into boost one day we may have a follow-up proposal. Why not submit together? Aside from the fact that the numeric extension is far from being comprehensive and well optimized, we want to see GIL used extensively and make sure the fundamentals are absolutely solid before making heavy-duty algorithms, because it is much harder to change your foundations after you have built the house (which suggests my opinion to the earlier question I posed).

Vigra provides interface to FFTW, filters and convolution. GIL may have better design. But both Vigra and Anti-Grain are richer.

The Vigra question is discussed above. I don't think we should even mention Anti-Grain here, as it has a very different focus, as discussed in a separate thread.

I would also require transparent handling of those dreary outer-edge conditions. This is glossed over in tutorial. How do I switch between treating the (-1, -1) lines as black (zero) and as copy of the outer (0,0) edges?

The goal of the tutorial is not to show you how to make a production-quality algorithm, but to teach you the basics of the GIL interface. Once you know how to navigate the pixels in the image, how to get/set their values and once you understand what the performance implications are, it should be straightforward for you to handle the corner cases. We certainly don't suggest using the x_gradient algorithm as-is. It doesn't handle corner cases, and central difference is a poor approximation to the gradient. On the other hand, real GIL algorithms do handle corner cases. Our convolution, for example, gives you a multitude of options for the corner cases - you can ignore them, pad them, clear them, reuse the nearest value, etc.

Would GIL look better if it is only viewed as a generic N-dimensional data access framework? Then we should be comparing it to Matrix Template Library. Lubomir has already answered Oleg that this is not the intention.

So a merge with or reimplementation of Vigra/AGG functionality seems in order. This could maybe be just a rounded package of convenience functions that supports common transformations efficently, with minimal end-user typing (keystrokes).

Merging between GIL/Vigra or especially GIL/AGG would be interesting. But how is your rejection helping here? If anything, it makes this possibility less likely.

Oh, I saw just now that some more algorithms were posted recently. Good, but late. Were they included in the review submission? Or more like proof of concept sketches?

Why is it late? The review period is not over. And I am not sure which algorithms you are referring to. The numeric extension is not part of the submission for the above-listed reasons, and it was posted before the review began.

Again, GIL looks good for what it does. Actually, after this review I'm more inclined to use it than before, but not for image processing - rather for some complex iteration tasks over plain 1-dim data.

...

- What is your evaluation of the documentation?

Not so well organized, and a little thin. The design document interleaves technical detail and very brief overview. The tutorial is impressionistic, and the code examples look like it's going to be a rough ride using GIL (lots of indexing src[x+1], src[x-1] etc, - that's how image processing looks in C, can't we have kernel functors instead?)

Sure you can - see the kernel from the numeric extension as an example. Being able to use the indexing operator and being able to use a kernel functor are not exclusive.

Concept docs looks as if copied verbatim from header files, though now I know it isn't so. They look cluttered. Documentation is often scanty, or inane repetition of class/concept names. Perhaps the authors trust that naming is so good that code will be self-explaining.

Not at all. In addition to the design guide and tutorial, we have Doxygen documentation for every public interface and lots of private ones. Which part of the code you feel is not well documented?

Maybe so, but when it's broken up in many pages, the overview one gets in the header files disappears. Perhaps a left-side browsing tree would help?

The Models reference doc tree almost but not quite repeats the Concepts tree.

Because we want to separate the models from the concepts. This is common in other libraries too.

I'm not sure whether I'd like them merged or just cross-linked, but the present setup separates related things.

We do often provide links from the models to their concepts. But you are right, they are not consistently present. In the design guide after we discussing a concept we point to its models.

Links in the tutorial point to places that don't help understanding at all, whereas the places where something substantial is said are buried 2-4 links away from the TOC of reference docs. (Eg class image_view. I posted about this a while ago.)

Rasmus - these links are automatically generated by Doxygen, which might explain why some of them may not feel logically placed. We could look into suppressing some of these links that don't make sense. Thanks for the suggestion. Thanks for your review, Lubomir & Hailin

Rasmus Ekman wrote:

The worries I try to express are: (1) Will the design work out in the long run? - GIL is not proven yet.

Rasmus Ekman wrote:

...

we want to see GIL used extensively and make sure the fundamentals are absolutely solid

Exactly. Can I say it now? Me too!

Design, documentation, broad domain, code quality - these are all valid criteria for a successful boost submission. But does boost require that a library be extensively used by many people before being accepted? How many of the boost libraries have been extensively used and proven in the long run upon their initial acceptance? Can we please have the same criteria used for other boost submissions be used for GIL. That said, GIL is not a toy project. At least one feature in the next generation of Photoshop will use GIL. You can buy today Photoshop Elements and its Photo Organizer mode will let you find human faces in your photographs to help with tagging: http://opensource.adobe.com/gil/facetagging.pdf This is using a very early version of GIL. We have published a CVPR paper on our (GIL-based) face detector and shown that it compares well against the fastest and most accurate published face detectors. GIL has been ported to the camera phone platform. This feature automatically zooms on the people in your picture: http://opensource.adobe.com/gil/facezoom.pdf We have been in contact with other companies that also use GIL. So, having industrial-level applications using GIL is a good endorsement. Of course, that doesn't mean that the GIL design is rock-solid and future changes won't be necessary. As with every library, we expect the GIL code to evolve and get improved over time.

(2) Where is GIL going? - If it is accepted, this gives more or less blank cheque to make additions - or not.

True for every other library. We are pursuing GIL and would like to see it improved, but we cannot promise any specific improvements.

From the download page: "It is in a very early stage of development; it is not documented and has not been optimized for performance."

I'm sure you're partly just being modest here, but I didn't consider downloading it when the review was first announced, then didn't look back until yesterday.

Yes, when we said "not optimized for performance" what we meant to say is that the code does not meet our internal expectations for performance. That doesn't mean it is not fast enough for many real applications. For example, our convolution uses compile-time recursion to avoid the overhead of explicit loop. You may find that some of the well established libraries don't have this.

The ones where the comment just repeats the class or concept name. Eg, the full documentation for MutablePixelIteratorAdaptorConcept reads: "Pixel iterator adaptor that is mutable." Actually I'm suggesting they be removed to save us from skimming repetitions.

Yes, perhaps we should remove the comments for obvious classes.

At the top levels of models and concepts there is hardly any documentation. It might be forgiven that Point, Pixel and Color have brief oneliners, but see Channel: "Concept for channel and mutable channel." Most users getting this far will know what it is, but having the word "color" somewhere on the page would not be affrontery would it?

Yes, we could add a few more sentences in the Doxygen structure to describe the concepts channel, pixel, image, etc. Please note though that a Doxygen structure is not even required for a boost submission. Those concepts you mention are already described in the design guide. And again, let's compare with the other libraries. Granted, GIL is larger than the average boost library, but we provide 40 pages of design guide, 12 pages of tutorial, an hour of video presentation with 150+ slides and a full Doxigen browsing tree. The lines of code of our documentation far exceed the lines of GIL code. That said, your comment is well taken and we will work on improving the documentation and making it more streamlined. Thanks for your input. Lubomir

On Fri, Oct 13, 2006 at 01:43:50PM -0700, Lubomir Bourdev wrote:

First of all, as far as we know we don't have a formal proposal from Vigra on the table, so we feel it is unfair to reject for this reason.

See http://lists.boost.org/Archives/boost/2001/11/19803.php

Here is another perhaps more important question to the boost audience: If you have to make a choice, would you choose a library with a better design and a minimal set of existing algorithms or a library that has more stuff in it, but with not so good a design?

This is IMO not a question of either or - both GIL and Vigra have spots where they shine, and areas where they could learn from the other lib.

A related question: Which one is easier - building new functionality on top of a solid design, or extending the design of a library with lots of existing algorithms that are built on top of the old design?

What if you need to revert your design, because certain functionality is not (or not easily) implementable - and you only find out while doing that one, specific algorithm? So, seeing a lib with lots of (algorithmic) functionality kind of increases my confidence that the basic design is sound...

Merging between GIL/Vigra or especially GIL/AGG would be interesting.

To repeat: I'd at least like to have Vigra's concept of pixel accessors and promotion traits merged/applied in GIL. Cheers, -- Thorsten

On Sun, Oct 15, 2006 at 12:16:15PM -0700, Lubomir Bourdev wrote:

Thorsten wrote:

...

On Fri, Oct 13, 2006 at 01:43:50PM -0700, Lubomir Bourdev wrote:

...

A related question: Which one is easier - building new functionality on top of a solid design, or extending the design of a library with lots of existing algorithms that are built on top of the old design?

What if you need to revert your design, because certain functionality is not (or not easily) implementable - and you only find out while doing that one, specific algorithm? So, seeing a lib with lots of (algorithmic) functionality kind of increases my confidence that the basic design is sound...

Your argument is generally true, but not in the case of GIL.

:-) Well. You've asked a general question, I've responded generally.

As for Vigra's pixel accessors... I read the documentation and I am still struggling to understand the difference between using them and using a PixelDereferenceAdaptor. If they indeed serve the same purpose, that would be an argument against including them in GIL. Can you post a simple example that illustrates how pixel accessors in Vigra are used?

accessor_t src_a, dst_a; iterator_t src_i, dst_i; // copy pixel from src_i to dst_i dst_a.set(src_a(src_i), dst_i); So, there's more to them than just a way to interpose a function object into setting/getting a pixel value (which is what a PixelDereferenceAdaptor does): One can totally customize the interaction between accessor and iterator, thus leaving considerably more leeway to both implementer and compiler, when applying Vigra algorithms (which all employ a stanza like above). Whereas GIL's iterator_t src_i, dst_i; // copy pixel from src_i to dst_i *dst_i = *src_i; glues access and iteration together (N1550's new iterator concepts are there for a reason - STL iterators do mix several aspects). True, there's a way to customize access, by wrapping a value type with e.g. planar_ptr. But that's kind of involved, and buries things that could be right at ones fingertips deep down in the innards of GIL. And to ask the other way 'round: are there any reasons *not* to use the accessor concept? It's for free in all cases you don't need it, makes clear the dichotomy between access and traversal (which is especially apparent for the domain of image pixel), and is used successfully in a state-of-the-art image processing framework. Cheers, -- Thorsten

Hi all, Quoting Lubomir Bourdev <lbourdev@adobe.com>:

So, to summarize, GIL incorporates the pixel transformation function into the iterator itself, whereas Vigra uses accessor objects separately, and goes through their interface explicitly to get/set the values of pixels, correct?

If so, I think accessors are a major limitation.

There are two major reasons why I think Data Accessors are a good idea: 1. incorporating pixel transformation functions into the iterator is much more work than writing an accessor because all the navigation functionality is (unnecessarily) repeated. This is not a big deal for a simple forward iterator, but becomes much more involved for complicated iteration patterns such as 2-dimensional navigation. Handling orthogonal concepts (navigation and data access) in separate classes just makes sense to me. 2. more importantly: the STL data access idiom via *iterator has a major limitation in that the (non-const) iterator::operator* must be able to handle rvalue and lvalue semantics simultaneously: value = *iterator; *iterator = value; However, lvalue and rvalue transformations may require very different implementations. For example, consider an RGB pixel in 565 format packed into a 16 bit unsigned int. Suppose you need an iterator adaptor whose operator* just reads/writes the green channel -- implementing this is very tricky and requires a proxy. Similarly, how do you implement "RGBValue & iterator::operator*()" when the color channels are located in different bands? In contrast, implementing either functionality by means of the separate get and set functions of a data accessor is trivial. This was the main motivation for introducing accessors. If the C++ language allowed for separate implementations of the lvalue and rvalue operator*, I'd reconsider the matter.

Or do you always provide accessors (the default ones doing a noop) and use their set method?

That's what we do in VIGRA, and the noops are nicely optimized away by all compilers we tested.

Second, isn't it cumbersome to provide an accessor separately from the iterator and to have to pass it around everywhere you need it?

That's not a big deal. Most of the time, you use the dafault accessor, which is automatically passed to the algorithms by means of an argument object. Admittedly, "dst_a.set(src_a(src_i),dst_i)" is not as nice as "*dest_i = *src_i" in terms of syntax, but it is much more powerful in terms of semantics (see above).

Third, perhaps the most severe limitation, expressions like "dst_a.set(src_a(src_i),dst_i)" do not follow standard iterator interfaces and cannot be used in any standard generic algorithms.

Yes, and I didn't take the decision lightly. But as I said, I consider this a limitation of the STL and the operator* semantics rather than a limitation of VIGRA.

For example, how can you invoke any STL algorithm on images that have custom accessors?

You can invoke them because operator* is always available in any VIGRA iterator. I.e., VIGRA provides the possibility to write GIL-style iterator adaptors. Regards Ulli Koethe (VIGRA maintainer)

Hi Thorsten,

Lubomir, I really don't want to be a nag, and I'm getting the impression that this discussion is leading nowhere.

I will reply to the other parts of your post separately, but I am puzzled by this paragraph. I thought our discussion is going very well - we are exploring the benefits and drawbacks of using accessors vs pixel dereference adaptors. This discussion has been very valuable for me and I hope for other people following the list, so lets keep doing it. We are both using logical arguments and code to illustrate our points. I call this a very constructive discussion. A discussion that is based on subjective arguments would be going nowhere, but I thought this is not the case here. Please don't take it personally! And yes, email is a horrible means of communication... ;-) Lubomir

On 10/16/06, koethe@informatik.uni-hamburg.de < koethe@informatik.uni-hamburg.de> wrote:

Due to the renewed interest in image libraries, I'd like to repeat my offer now -- I still think that boost would be a good home for VIGRA. I also consider some integration with GIL an option, although one has to check what is technically possible and can be done by volunteers. In any case, I like GIL's extensive use of the view concept.

It would be great news if the GIL authors and yourself can manage to integrate both libraries. I haven't sent my GIL review, but while GIL provides a sound design it would benefit most by combining with the more mature VIGRA library. I believe that GIL without a broad set of imaging algorithms is not very useful (although there is an expectation that many will contribute algorithms, I don't think it is realistic !). On the other hand, you provide a broad set of algorithm implementations (not just image processing) that have been available for several years (and that have improved the design of the core imaging libray) One approach, assuming GIL authors cooperation, would be to add what's missing to GIL (as you discuss in other messages) and then have a common unique image container library that the algorithms can be ported to. thank you for offering the VIGRA library !

On 10/16/06, Lubomir Bourdev <lbourdev@adobe.com> wrote:

However, what we don't want to see is the review of GIL postponed to the indefinite future or the current GIL submission rejected because of the lack of VIGRA's algorithms.

Has anybody implied this ? GIL core is a library with a very specific goal - to provide efficient

and representation-independent access to the pixels of an image. Providing an extensive set of image processing algorithms has never been the design goal of GIL core. While no library can ever be complete, we believe GIL provides a comprehensive solution to the stated goal.

My point of view is of the library user, not the library developer, and I am asking for a library users can use without having to develop established algorithms. Would STL be useful without STL algorithms ? I know GIL does provide basic algorithms but I am arguing about image-specific algorithms which you've started to provide in the numerics extension 1. The set of image algorithms is fundamentally open-ended. Vigra has a

good set of them, but so do other libraries, like Intel's IPP, and ITK. Why stop with VIGRA, why not take advantage of all of them? And why stop at imaging algorithms; why not include computer vision algorithms like the ones in OpenCV? And why not add vector graphics algorithms, like the ones in AGG and Cairo? And when would we be ever done?

That's fine but no excuse for providing the basic ones in GIL. There's also a huge set of algorithms/structures not in STL (tries, TST, b-trees, ..) but STL has the most common ones. I hope the analogy with STL helps get the point across ! 2. A library with multiple goals that could logically and easily be

separated should be broken down into multiple libraries. Notably, image processing algorithms (like the ones in VIGRA) constitute a separate goal and deserve a separate library. Vector graphics (AGG) is another separate goal and deserves a separate library. Of course, it makes sense for both of them to make heavy use of a core library (like GIL) that abstracts away the image representation.

The only goal that matters is that the library is used. I think a few reviewers/comments hit on the point that GIL has only the container, iterators and very basic algorithms (but this is changing with the numerics extension) 3. As Matt Gruenke states, the goal that GIL addresses is sufficiently

important in itself to justify it constituting a separate submission. There are many cases where you deal with images in which you don't need to deal with image processing algorithms.

To be specific, which cases are you referring to and how useful/important are ? I mean end user cases. If I were a library developer then GIL might be pretty useful as it is right now to build my own library on top of it. By providing GIL in boost

today, we will address the needs of this set of people that would otherwise have to wait for an unspecified amount of time for something they don't need.

But the VIGRA author also pointed out that as they were developing new algorithms the core design evolved/changed 4. GIL is a large library. Adding an extensive set of algorithms to it

will make it really huge. This will put a big burden on the boost review process and it will be hard to ensure high quality for a very large library. We believe it is better for boost to consume large libraries as a set of smaller, solid and self-contained component libraries.

Sorry to be blunt but it looks like you're searching for excuses ! I am not trying to jiggle the review. The review is great as it is but many times the library is accepted and some libraries don't continue to evolve as they should (not blaming anybody but just suggesting this should be considered in the review) 5. One argument I heard mentioned is, before writing lots of algorithms,

how do you know that your core is solid? It seems more appropriate to start with algorithms and derive the data structures from them. While we think this is generally the right approach, we are confident that GIL can handle any imaging algorithm. This is because all GIL does is provide an efficient and representation-independent access to the pixels of an image, and this is all you need to be able to write any imaging algorithm. We have certainly provided a proof of concept by providing fully generic algorithms for convolution, resampling and generating the gradient.

Confidence is good but results/data is better :-) We are not saying that the core is complete, in a sense that it provides

you with all the tools you need in designing image processing algorithms.

Well, then we're agreeing! In writing GIL image processing algorithms you may discover

useful abstractions, like, for example, the need for promotion traits.

Let me state first that I am no expert but I read the book Applied C++ - Stroustrup C++ In-Depth Series, which uses as an example for the whole book the design of an image library. One of the basic things is what they call campling (== promotion traits ?) In page 29 (memory allocation) they mention "We needed such a function inside our image processing functions to control the behaviour in overflow and underflow conditions. Specialized versions of this function test for overflow and clamp the output value at the maximum value for that data type ... " The fact that GIL doesn't provide campling makes me argue it is not a mature library. It's such a basic need (I get this from reading the book!) None of the above should be interpreted as criticism. My only wish is that the imaging library that is included in boost is as good as it can be. Also, I've not praised many of the good aspects of GIL as these have been pointed out already.

On 10/17/06, Michael Walter <michael.walter@gmail.com> wrote:

On 10/17/06, Jose <jmalv04@gmail.com> wrote:

...

One of the basic things is what they call campling (== promotion traits ?)

Are you referring to what is commonly called "clamping"? If yes, I don't think this is what promotion traits are for (but maybe my definition of the latter is off).

I stated that I am not an expert so I hope this gets explained by the experts. Actually I only now about clamping as per the mentioned C++ book but I have not looked at promotion traits (but I inferred from the messages that promotion traits handle the overflow/underflow cases)

The fact that GIL doesn't provide campling makes me argue it is not a mature library. It's such a basic need (I get this from reading the book!)

To clamp a channel in GIL you can just say: T channel; T clamped = std::min(channel, channel_max_value<T>()); We actually had a set of primitive channel-level algorithms that also included clamp, but we decided to remove things you can do with a simple one-line expression so we don't clutter the interface. Lubomir

Hi Ullrich and Jose -- GIL has something similar to promotion traits in the numeric extension. Moreover, it is designed so that users can easily override the default behaviors without sacrificing performance. More specificly, the algorithms in the numeric extension allow users to specify types for holding intermediate results. The intermediate types are then passed into a set of pre-defined structs for doing fundamental numerical operations such as addition, subtraction, etc (see extension/numeric/pixel_numeric_operations.hpp). All the structs are templated over input types (one, two or more) and output types, which are often the intermediate types, and these structs are consistently used throughout the numeric extension. As a result, the user can specify either "float" or "double" as the intermediate type for convoluting a "unsigned char" image with a "float" kernel. Hailin Ullrich Koethe wrote:

Lubomir Bourdev wrote:

...

...

The fact that GIL doesn't provide campling makes me argue it is not a mature library. It's such a basic need (I get this

from reading the book!)

To clamp a channel in GIL you can just say:

T channel; T clamped = std::min(channel, channel_max_value<T>());

But that's not how things work in practice. When the data are already stored as type T, overflow has already occured. Moreover, the possibility of overflow typically arises deep inside some algorithm, where you cannot simply call std::min(), but need another mechanism (e.g. promotion traits).

Ulli

Quoting Lubomir Bourdev <lbourdev@adobe.com>:

Promotion traits, as I stated in another thread, are handy and there is definitely a value in providing them. But I think they are an integral part of the imaging algorithms and therefore belong in the numeric extension. So stay tuned!

I my experience promotion traits are absolutely necessary to implement genereric image processing algorithms. Consider the simple matter of adding two or more byte images. In order to avoid overflow, intermediate results should be stored in a short or an int. If the result is to be written back to a byte image, the destination accessor can take care of shifting the result back into the appropriate range or clipping at the range limits. Promotion traits control this behavior. Hardly any algorithm in VIGRA can do without them. Regards Ulli

Alexander Nasonov wrote:

...

I my experience promotion traits are absolutely necessary to implement genereric image processing algorithms.

Since I didn't watch this thread closely I don't know if you're talking about recent addition to boost.type_traits (http://lists.boost.org/boost-announce/2006/04/0084.php) or something completely different. My guess is that you use different version of promotion traits in VIGRA. Is it correct?

Yes. Originally, I learned the concept from the blitz++ library. Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

Hi Lubomir, Lubomir Bourdev wrote:

We don't believe the type of the result could automatically be inferred simply from the types of arguments. The optimal type depends on your intent and the context.

True. But the result type is usually not automatically inferred in VIGRA (it is inferred from the destination image you passed in). Promote traits are mainly used for the definition of intermediate types (e.g. temporary images). Essentially, promotion traits make explicit what the compiler is doing anyway. For example, the type of an expression adding two signed chars is always int, regardless of the type of the variable the result is ultimately assigned to. We wanted to achieve the same for the addition of images. (We did not always get it right, but this can be corrected.)

For example, VIGRA's promotion traits choose double as the promotion for int when dealing with floating point operations. Why not float? On many architectures float is faster, and precision may not be an issue in the context in which you use it.

Right, some customization would be nice. But the defaults have worked very well for us most of the time, so we didn't feel an urgent need to change the behavior.

Why should int always be the result type of adding two ints?

Because that's what the C++ standard says (AFAIR).

Int for summing two shorts will not overflow, but what if you are building, say, the integral image and you want to sum the values of all pixels in your image?

This can be handled by means of an appropriate Inspector with value_type double or BigInt. The VIGRA Inspector concept is like a Functor, except that it doesn't return a value, but collects some statistics about the values it has seen. (Note that VIGRA is also defined in terms of concepts, although not quite as nice as GIL.)

This is why in GIL we allow the type of the result to be specified explicitly upon invoking the operation. Promotion traits can at best be useful for a reasonable default,

Resonable defaults are everything in generic programming, otherwise it's unusable.

We feel that promotion traits belong in boost::type_traits and not in an image library, as the problem generalizes beyond images.

I agree. Regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

Hi David, David Greene wrote:

Because that's what the C++ standard says (AFAIR).

But the standard isn't always the best answer for all promotion situations. For example, some years back I wrote some expression template code for simulation purposes. I wanted a simple user interface so I promoted int / int to double to avoid loss of precision.

Right. So VIGRA supports two promotions standard Promote (what the compiler does by default) and RealPromote (the floating point promotion is guaruanteed)

Stuffed away in some cobweb-infested dusty disk sector I have a library that implements promotion "strategies" using a table-driven configuration of (operator/operand type -> promotion type) rules.

That's how VIGRA's promotion traits essentially work.

I'll see if I can dig it out and post it as a starting point. I'm not sure if it's what we want as a Boost library but it might be a start for discussion.

Will be interesting to look at. Regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

...

We don't believe the type of the result could automatically be inferred simply from the types of arguments.

The type of the result is fixed by the types of the arguments, therefore, simply ... the type of the result is automatically inferred simply from the types of arguments.

What I meant to say is that the OPTIMAL type cannot be inferred automatically from the types of arguments. It depends on the many criteria I listed. Lubomir

Joel de Guzman wrote:

Lubomir Bourdev wrote:

...

This is why in GIL we allow the type of the result to be specified explicitly upon invoking the operation. Promotion traits can at best be useful for a reasonable default, but even then we feel that they belong in boost::type_traits and not in an image library, as the problem generalizes beyond images.

I agree. I am not quite fond of monolithic libraries that do everything. Promotion traits and clamping, for example, can also be useful for, say, signal processing of audio, among other things.

True. But on the other hand, one has to control the number of external dependencies -- if a potential user must install 5 or 10 other libraries first, he might quickly loose interest. In image processing, one wants at least libjpeg, libtiff, libpng (which in turn requires zlib), perhaps a fourier transform library, possibly boost, a linear algebra library (for warping and curve fitting), a GUI library (which often already comes with incompatible image import/export functionality) and so on -- there is certainly a trade-off between internal and external solutions. Of course, there are platforms where installation is easy, but you want to be general. Regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

Rene Rivera wrote:

This might OT for this particular thread, so feel free to ignore my question. But it might be topical for Boost.Build and installing Boost in general, so I'm asking :-)

Ullrich Koethe wrote:

...

Of course, there are platforms where installation is easy, but you want to be general.

I only know of one platform where that is true, but essentially no one uses it any more. Which are you referring to? And what makes them "easy"?

Well, I should have said "relatively easy". I specifically refered to platforms were binary installation is possible and can be expected to work correctly with reasonable probability (some Linux variants?), as opposed to platforms were all packages (including dependencies) must be compiled from the sources (certainly all traditional Unixes, and Windows when a particular configuration or compiler build is not available in binary form). For what it's worth: VIGRA tries to provide basic functionality in a number of areas simply to get you started (e.g. it can natively import/export Windows BMP and a few other image formats, it has a simple lambda library, basic linear algebra functions), but allows the ambitious to use more sophisticated libraries when necessary (e.g. boost::lambda). Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|

Ullrich Koethe wrote:

Joel de Guzman wrote:

...

Lubomir Bourdev wrote:

...

This is why in GIL we allow the type of the result to be specified explicitly upon invoking the operation. Promotion traits can at best be useful for a reasonable default, but even then we feel that they belong in boost::type_traits and not in an image library, as the problem generalizes beyond images.

I agree. I am not quite fond of monolithic libraries that do everything. Promotion traits and clamping, for example, can also be useful for, say, signal processing of audio, among other things.

True. But on the other hand, one has to control the number of external dependencies -- if a potential user must install 5 or 10 other libraries first, he might quickly loose interest.

In image processing, one wants at least libjpeg, libtiff, libpng (which in turn requires zlib), perhaps a fourier transform library, possibly boost, a linear algebra library (for warping and curve fitting), a GUI library (which often already comes with incompatible image import/export functionality) and so on -- there is certainly a trade-off between internal and external solutions. Of course, there are platforms where installation is easy, but you want to be general.

Isn't this a problem of packaging instead of monolithic vs. modular libraries? IMO, the level of granularity of a library reflects its design. A well factored library, as a result of extensive refactoring, over time, results in small highly orthogonal, loosely coupled sub- libraries. A monolithic library, on the other hand, tend to devolve into chaos over time. Don't get me wrong. I am not referring to VIGRA; I am not familiar with it and its design. I am just talking in general terms. And, referring back to GIL, I see that it hits the exact sweet spot in terms of modularity. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Matt, If it's okay with you, your post doesn't seem to require a detailed response from me. I've made some comments, positive and negative, well-founded or misguided, and any rehashing of them just adds noise to the workload of the review manager. (IIUC he's the impartial party who will weigh various points, the willingness of library authors to change, or motivations not to, and synthesize a collective judgement. I'm under the impression we don't need to argue every millimeter, just clarify the points sufficiently for him to record them. For this reason I also underscored the limitations of my review and the underlying perspective.) So, your task is not to sway me. Outvote me instead. After seeing the numeric_examples code posted the other day I'm rather hoping this happens, but I interpreted it that the extension is not part of the submission. See also http://boost.org/more/formal_review_process.htm#Submitters - though it doesn't explicitly cover this case. Other boosters and the rev.mgr hopefully know how to judge these things, including the progress made over the last few weeks (my impression is that GIL was just a little rushed to review). Cheers, re

Stefan, Thanks for your support! Stefan Seefeld wrote:

I vote for GIL to be accepted into boost.

Design ======

* It should be possible to create row-major, as well as column-major images, to speed up column-based algorithms. As pixels have 'channels' as well as 'semantic channels', images may have 'rows' as well as 'semantic rows'.

Can't you just use transposed_view ?

* It may be worthwhile generalizing some of the API in parametrizing dimensions (for example to have a 'size(axis)' method instead of 'width()' / 'height()', or having

"get_dimensions(view)[n]" returns the size along n-th dimension If your dimensions have different types, you could use: get_dimensions(view).template axis_value<N>();

a stride(axis) method returning the step size along rows and columns...

The step in bytes is only applicable to memory-based image views. For those, you could say: "view.pixels().row_bytes()" for byte-step in y "view.pixels().pix_bytestep()" for byte-step in x For a generic N-dimensional memory-based image you could use the more generic accessors: "byte_step(view.template axis_iterator<N>())"

Implementation ==============

I think the implementation is very clean. I have only some minor points:

* The io extensions should use iostream instead of stdio (i.e. std::iostreams instead of FILE *)

Good point.

* Variable names should not start with an underscore, as such names are reserved.

We will change this if there is a strong consensus. But there are other boost libraries that do that.

I think it would be very helpful to add sections to the tutorial that describe how to introduce custom pixel and image (well, locator) types. That would demonstrate the reasoning behind lots of the chosen concepts.

Doesn't the Mandelbrot set example show how to introduce new locator/image types? As for custom pixels, perhaps even better is to make packed pixels part of GIL. Once this is done, making custom pixel types would be needed very rarely if at all...

The library should contain example programs to demonstrate all the individual aspects of the library.

You mean code snippets? Thanks for your review! Lubomir

Lubomir Bourdev wrote:

Hi Joel,

Thanks for the time you spent reviewing GIL and for your vote!

The AGG integration example is certainly very interesting, and we will add it to the list of GIL example files. Thanks for doing all this proof-of-concept work!

The Fusion integration is a neat idea and I see no immediate obstacles to doing this. The less code in GIL, the better :-) Let's discuss details off-line.

Definitely! I'd be glad to help.

...

...

- What is your evaluation of the implementation? B+. I thought I'd give some negative marks here because I was not able to see any regression tests, but Lubomir quickly pointed out that there are some in the ASL repository. Indeed there are tests. However, I give this a B+ because the tests are not extensive and do not cover a lot. I see only 6 tests. A lot more work should be invested in this area.

I am not sure if you found the regression tests.

Our regression suite is fairly extensive, though the code is not very [...]

I see. Oh, pardon me then. Can you guys make that public and easily accessible? I don't think I am the only one who looks at regression tests first and foremost? Regressions plus examples speak volumes! If only GIL was presented in the canonical boost directory structure, then, this wouldn't have been a problem. I suggest that future review managers require this prior to review to avoid any confusion. Anyway, I stick to the grade because (I forgot to mention) the lack of examples too. To me, examples by themselves, speak volumes.

I feel that if we hadn't provided Doxygen documentation at all we would have gotten higher reviews on documentation :-) The Doxygen documentation is not even required part of the submission, so it comes extra...

I disagree. The reference docs is a crucial part of the docs, as do concept docs and tutorials. I know. I've been criticized in the past for that (i.e. spirit). Hence, with Fusion comes extensive STL style reference docs. That too has not been without criticisms. Documentation is an art that I am still trying to learn.

Those concepts are described better in the design guide.

...

...

- What is your evaluation of the potential usefulness of the library?

Oh man, do I have to answer this? :-)

Well, a few people like Jose and Rasmus were not quite convinced, so a straight answer would be nice, though you implied one.

Hmmm... Ok, for the record: I find GIL to be a very useful library. I like its modularity among all its traits. GILs granularity and modularity hits a sweet spot that makes it extremely useful for integration with other libraries and even, I dare to say, as a core of many graphics libraries. It is extremely flexible, extensible and adaptable. As far as the design and implementation of the library goes, it's A+. No doubt about that. And to me, that's what matters most. All the talk about comparing GIL to other libraries is constructive, to say the least, but should not be a factor for rejecting the library. IMO. There's some precedent already in boost where multiple overlapping libraries were accepted (i.e. regex, xpressive and spirit).

Thanks again for the extensive work you put in this review!

Most welcome! I enjoyed GIL. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net