Boost logo

Boost :

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

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at