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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-06-23 19:57:36

>But how specific image (or view) organized in memory (or even synthetic

>like in you example), that's what I call layout. But you mix this from 
>the very beginning (when defined RGB class) till the very end (member 
>functions of a templated class image, with arguments that specify each 
>row alignment). I think it's no good at all.

There is one important point that I keep repeating but for some reason
have failed to get through to you. Let me try again:

GIL defines abstract concepts and concrete models of those concepts.

Our design principles are that the concepts are as general as possible,
to the degree that does not affect the performance and usability of the
models.
For example, take a look at the RandomAccessNDImageConcept. Does it say
anything about the order of channels, or the color space, or that it
even operates on pixels? Does it even say that the image is two
dimensional? No. For what it's worth, that level of abstraction allows
you to create a model of a video clip or a synthetic 3D volume using
voxels if you'd like.

Then there are refinements of RandomAccessNDImageConcept that allow for
2D images, and further refinements dealing with concrete, memory-based
images, with the corresponding additional required functionality.

As for the models, you are correct to point out that the models are very
much dependent on the particular representation of the image in memory
(what you call the "layout"). This is not a design flaw; it is very much
intentional, because the models HAVE to know what they are supposed to
model. The pixel iterator concept doesn't say anything about planar vs
interleaved representation. But there is a planar model of pixel
iterator (planar_ptr) and an interleaved model, and they are different
and very much dependent on the memory organization they are
representing.

The users of the library don't have to deal directly or know the
specifics of the underlying models. VIEW::x_iterator will return a raw
pointer for interleaved images, planar pointer for planar images, step
iterator for subsampled images, or whatever is the optimal model that
will do the job. But the GIL algorithm need not be concerned with the
specifics of the design.

>I always wanted to implement most of that algorithms, but right now I 
>just don't feel GIL is the platform where I want to do it, sorry :(

Pavel - you may have given up on us, but we haven't given up on you.
Some of the points you make (decoupling the ordering of the channels and
more automatic pixel creating) are worth looking into further. Since you
obviously have spent a lot of time thinking about and working on a very
similar area your input is invaluable. If our submission is successful,
we will be sure to give you credit for your suggestions.

Also, I don't want to imply that GIL is perfect. GIL is far from
perfect, and that is why I am asking the boost list for suggestions for
improvements. The concepts need to be further refined, some important
models need to be added; we are aware of several improvements and we are
working on all of these but I do want to hear about other improvements
people might suggest to make sure we are not missing anything.

Lubomir