Re: [boost] GIL - Generic Image Library Review - Begins October 5

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-05 22:04:23

Andy,

I was not sure you were looking for a response from us. I thought you
were just expressing your opinion on the library (which I happen to
disagree with). 

Any large library has some concepts that could stand on their own or be
reused in other contexts. Sometimes it makes sense to do so, but
sometimes (as I believe is the case with GIL) those other contexts are
quite nebulous and doing so would be somewhat extreme.

Let's take your example of Display Matrix. You suggested that we could
take GIL's image view concept and have it be a separate library, so that
you could, for example, use it to manipulate characters in a rectangular
grid. But the intersection between the two contexts is very small. Why
not just use any 2D matrix of characters? And what is special about the
"Display" aspect of a "Display Matrix"?

Another problem is that a library cannot consist of just concepts. You
need to have concrete models. GIL provides only the models it needs in
practice - a 2D image comprised of pixels in a specific color space. So
another reason we can't have a "Display Matrix" library is that we don't
have existing models that go with it.

Let's take your perhaps most convincing example, which is separating
color out. The only practical operation on color that doesn't
necessarily involve images would be converting from one color space to
another (although ultimately I have a hard time coming up with a case
where the result won't end up on an image).

To do color conversion, you will need to store the values somewhere.
Hence you cannot go by without the concept of a channel. The color value
is a collection of channels, hence we need the concept of a pixel. And
if you have a pixel in one library, does it make sense to have the pixel
iterator and reference in another library? No. So we have a lot of GIL
that is needed to do the very basic pixel-related operations.

Now, we could conceivably separate pixel-level operations in one library
and put image-level operations in another library because pixel-level
operations don't depend on image-level ones. But the two are so closely
related and used together that it is like splitting a linear algebra
library into a vector-level operations library and a matrix-level
library. Sometimes it just doesn't make sense to do so.

We have tried our best to separate GIL functionality as much as we can;
this is why we have the extension mechanism. You can think of the GIL
core as one library that has no dependencies, and the extensions as
separate libraries that depend on the core and perhaps other extensions.
But with a few minor exceptions, the code in the core is tightly
interdependent.

Lubomir