[boost] Review of Generic Image Library (GIL)

From: rasmus ekman (m11048_at_[hidden])
Date: 2006-10-12 22:25:05

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.

>  - 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.

>  - 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.

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

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?

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).

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?

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?)

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.
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.
I'm not sure whether I'd like them merged or just cross-linked, but the present
setup separates related things.

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.)

I did watch the Breeze presentation a while ago, and again today, and I
still don't think one should have to sit through something like that
to get started with a library in a familiar field.
There are some good breakdowns of names and overviews of available
classes/functions that should be typed out and linked up with browsable docs.

>  - Did you try to use the library? With what compiler? Did you have
> any problems?

No. I usually just read interfaces of several comparable libraries
until I choose which one to use.

>  - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?

In-depth glance: Browsing docs for a couple hours, browsing header
files for a few hours.

>  - Are you knowledgeable about the problem domain?

Somewhat. I have written a published app for image generation and processing
some time ago, and rewritten part of it in semi-generic code more recently.
I would have loved to have something like GIL before, but would actually
go for AGG or Vigra.

=== EOR =====================================

This is my first review for Boost. I've used some Boost code since about 1.25,
followed this list about as long, but am not a professional programmer.

I know a proper "review" should go a little deeper than the above, so feel free
to factor my vote by 2/3 or something. (I'd actually prefer that, wouldn't
want to be responsible for rejection of something I just failed to comprehend...)

Cheers,

        rasmus ekman