"Lubomir Bourdev" <lbourdev@adobe.com> wrote in message news:B55F4112A7B48C44AF51E442990015C00167861E@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