Boost logo

Boost :

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2006-06-24 08:12:51


Lubomir Bourdev wrote:
>>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:
Seems I failed do the same job too ;)
>
> 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.
But there you have row alignment support - Why?

>
> 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.

What's the point of BGR class then?

> 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.

BTW, I would reject "view" concept at all, since it's actually same as
"image" concept because every subset of original image (such as
subsampled one) is still an image :)

>>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.

Thanks for your patience and politeness to expain all your points to
such a bad listener as I am, and I think I shouldn't have acted that
way. Yeah it's still true that I like my way more, but my library is
nowhere near what your GIL already have now, so I urge you to ask for a
formal review. And I'm not planning for a submission at least for a
while, and if your library is accepted by that time, I actually see no
reason to submit my library then.

P.S. I think you should add support for sRGB too ;), of course if you
haven't done that already.

--
Pavel Chikulaev

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk