On Sat, 2006-06-24 at 13:35 +0100, Andy Little wrote:
"David Abrahams" wrote
"Andy Little" writes:
FWIW
My initial reaction is that I would not vote to accept GIL into Boost unless it came with a cross-platform UI.
I can't imagine what a cross-platform UI has to do with an imaging library. It seems like one could make the same demand of any library that works on something visualizable. If we used that criterion we wouldn't have the Boost Graph library, or uBlas, or, heck, a smart pointer library either.
I strongly disagree.
I strongly disagree too. An image is nothing more than a multi- dimensionnal array of values. What the values are is totally user- dependent... Of course, there are some treatments (filtering, pdes, conversions, resizing, roi, ...) that are meaningful for images. I'd expect an image class to derive from an array class (which would eventually manage the all the storage problems (tiling/alignment/interleaving/....) and to provide such image specific capabilities. I skimmed quickly through GIL's documentation. Basically, I like the concepts (they look like the ones I use in my own Image library). The major drawbacks I see are (CAUTION: I may be wrong as I just had a very quick look at the design and the tutorial documents): - the iterators seem somewhat restrictive. There is no way to iterate over lines or colums of an image (which is useful eg for filtering). Also, I'm not sure what would be the efficiency of implementing eg image differences using iterators (for that you need to iterate over two similar images)... Often, one may want to iterate over the domain of one image to access an another one... - I'm not sure that the interleaving/alignment/structure really belongs in an image class. For me, it's often more an implementation detail related to storage. That being said if that comes at no cost, I have no problems with that... - I do not like the current IO scheme. From the tutorial, it seems that you have to know the image file format (jpeg,png,tiff) at coding time... But the separation between storage and memory layout is IMHO very important. Extensibility also. A plugin system would be great but this is certainly beyond GIL goals. All that being said, I'm certainly biased by my mathematical/image processing background for which images are somewhat much more than something you display on a screen. But besides these potential drawbacks, GIL is certainly a step in the right direction.