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