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

From: Matt Gruenke (mgruenke_at_[hidden])
Date: 2006-10-15 03:11:51

So far, the three rejections I've seen all cite GIL's scope as a 
major/primary fault.  Interestingly, the desired scope of each reviewer 
is different and possibly incompatible with the others: one desires a 
higher-level and far more general approach, one desires additional 
functionality, and one desires further decomposition.  So, I'm beginning 
to wonder whether consensus on this matter is actually possible.

I'd like to use some points made in this particular review to offer my 
understanding of GIL's scope, and my case that it encompasses a problem 
worthy of a solution in the form of a Boost library.  I will provide my 
own review, separately.

rasmus ekman wrote:

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

Since this seems to be the primary reason for your rejection of GIL, I'm 
curious whether your concern is that:
    a) it doesn't solve enough problems to be useful
or
    b) it doesn't solve as many problems as it could

My take on 'a' is that GIL absolutely does address problems concerning 
those who endeavor to write graphics and image processing routines that 
aren't tied to a specific image representation.  If you're not 
interested in this problem, why do you use that as a basis for rejecting 
the library?  Imagine you were writing fairly generic image manipulation 
routines - wouldn't you like a unified and efficient interface for 
accessing images of various precision and layout?

'b' is fundamentally open-ended and applies to a great number of 
libraries and problem domains.  As it doesn't directly relate to the 
value of a solution, I think it doesn't warrant further discussion.

I believe the core questions should be whether it solves a worth-while 
problem, and whether it does this in a way that meets Boost standards.

>Vigra provides interface to FFTW, filters and convolution.
>  
>

FYI, the FFTW library is fundamentally incompatible with boost's license 
requirements.  For commercial applications, FFTW makes it non-free, and 
thus not directly comparable.  Of course, you can compile it without 
FFTW support.

Anyhow, I see GIL as an image access library - not an image algorithms 
library.  My case for simply having a good solution to the image access 
problem follows.

Suppose an algorithm provided by a given library didn't meet your 
requirements for speed, precision, supported image formats, or memory 
footprint.  Perhaps you don't want to drag in a whole new library, just 
for one or two algorithms.  Maybe you have a novel algorithm or 
implementation approach.  For whatever reason, you can't or don't want 
to use the implementation provided by an existing library.

In practice, these issues are quite common.  Such cases would be less 
likely, if the library were written on top of a GIL-style image model.  
However, even if GIL did include a collection of algorithms - and had 
the very one you wanted - there's no guarantee that it would make an 
optimal or even acceptable performance vs. accuracy tradeoff, for your 
needs.

When you're stuck writing your own implementation, it's helpful to have 
some routines that facilitate efficient image access.  It'd be even 
better, if you could subsequently revisit decisions about your image 
representation, or reuse the same code for different types of images.  
For these reasons, even those who are simply consumers of image 
synthesis, manipulation, and transformation algorithms should see some 
value in GIL and the problem it solves.

In summary, generic image access is instrumental in facilitating generic 
image algorithms.  Since even the most generic and comprehensive 
collection of image algorithms will not suit all needs and uses, it's 
important to have a fallback solution for efficient & flexible image 
access.  As you can see by the amount of work that went into GIL, this 
is not an easy problem to solve.  IMO, it can and should be solved 
independently from the implementation of algorithms that use it.

Matt Gruenke