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