Re: [boost] VIGRA and GIL -- Review of Generic Image Library (GIL)

From: Jose (jmalv04_at_[hidden])
Date: 2006-10-17 04:25:11

On 10/16/06, Lubomir Bourdev <lbourdev_at_[hidden]> 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.