Re: [boost] GIL - is there interest for an image library in Boost?

From: Theodore Papadopoulo (Theodore.Papadopoulo_at_[hidden])
Date: 2006-06-24 16:21:49

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.