From: Tim Day (timday_at_[hidden])
Date: 2006-10-25 07:23:21
On Tue, 2006-10-24 at 19:49 -0700, Tom Brinkman wrote:
> Get your reviews in.
[This didn't seem to make it to the list first time;
sorry for any duplication.]
> Please always explicitly state in your review,
> whether you think the library should be accepted into Boost.
Yes, I think it should be accepted.
- What is your evaluation of the design?
- What is your evaluation of the implementation?
I don't feel qualified to comment. I like _using_ libraries like this,
but it's way beyond anything I'd contemplate putting together myself.
It certainly seems to deal with a lot of issues very elegantly.
- What is your evaluation of the documentation?
I found it quite a steep learning curve to get anything running. The
tutorial would IMHO be greatly improved if (in "hello world" tradition)
it just added the few extra lines of code to make a complete app
(perhaps loading and saving an image from/to file, or generating
something synthetic). [But, I see the collection of examples recently
put up address this]. The doxygen documentation I found fairly
pointless; usually grepping the code directly found me what I was
looking for quicker. Initially I found the most useful bit of the
design guide was the specific examples in the later chapters, but then
having used the library a bit I got more value out of the "concept"
chapters on revisiting them.
- What is your evaluation of the potential usefulness of the library?
Well I'll certainly be using it in future whether it's accepted into
boost or not. There seems to be a lot of unnecessary worrying on the
list about it not being a full-featured image processing library, but
that's not actually what I'm looking for... all I want is a flexible,
efficient STL-like container for my pixels. It's like arguing
std::vector or std::valarray shouldn't be in the standard if a heavy
duty numerics library isn't also included.
- Did you try to use the library? With what compiler? Did you have
No problems with "g++ 4.1.2 20060901 (prerelease)" in Debian Etch.
I got some GIL related compile errors with gcc 3.3.5 (Debian Sarge) but
I didn't investigate for any longer than it took to boot up the Etch
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
GIL (and things like Vigra) have been on my radar for a while but seeing
GIL was up for Boost adoption prompted me to actually try and use it.
I've now spent a few tens of hours using it in some new development (in
which I'd have probably used one of my old legacy image classes
otherwise). The experience has been entirely positive, although I have
to say I haven't done much but create images of various formats, pass
views of them around and iterate over them. The best bit so far was
finding that the gtkmm and Qt front ends for my app needed different RGB
orderings and dealing with it by simply instantiating my rendering
backend with the appropriate GIL image type.
> Are you knowledgeable about the problem domain?
I've been a C++ user since around 1990, always working in the field of
computer graphics and imaging. I've lost track of the number of times
I've written yet another templated-on-pixel-type Image/Raster class of
varying degrees of unsophistication. One of the first things I looked
for when I discovered boost was an image class; it's about time there
was one and GIL certainly seems worthy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk