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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-13 16:43:50

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of rasmus ekman
> Sent: Thursday, October 12, 2006 7:25 PM
> To: boost_at_[hidden]
> 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