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