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

From: Andy Little (andy_at_[hidden])
Date: 2006-10-06 08:58:56

"Lubomir Bourdev" <lbourdev_at_[hidden]> wrote in message 
news:B55F4112A7B48C44AF51E442990015C00167861E_at_namail1.corp.adobe.com...
> 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.

? "Those other contexts are quite nebulous"?  You lost me..

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

Whats so special about the pixel aspect of a pixel matrix? Spreadsheet, LCD 
display, keyboard, circuitboard, network switch, RAM

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

Yes I think this is the heart of the problem! The library claims to be generic 
but is in fact tightly coupled to one domain.

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

Serialising a  line, Changing colour of a button, Making an explosion in a 3D 
game, monitoring a chemical reaction....

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

You lost me as why  you *need* a pixel for a colour.

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

The library is designed only for working in one specialised domain, and that is 
my point.

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

Yes exactly my point....  ;-)

regards
Andy Little