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.