-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Sent: Wednesday, October 11, 2006 10:06 PM To: boost@lists.boost.org Subject: Re: [boost] GIL & pixel accessors (was: Review of Generic ImageLibrary (GIL)begins today, Oct5, 2006)
On Wed, Oct 11, 2006 at 02:17:30PM -0700, Lubomir Bourdev wrote:
Thorsten wrote:
GIL pixels/channels should never advertise that they have larger capacity than they actually do.
How else would you then implement paletted images?
[snip]
The way indexed images can be modeled in GIL is using a PixelDereferenceAdaptor over grayscale image of the appropriate channel depth. Specifically:
1. Create an immutable pixel adapter that references the lookup
Its application operator takes an index and returns an RGB pixel value. Here is a rough synopsis for a concrete version; you can easily make it more generic and improve it in other ways:
[snip]
Now your indexed_view will behave like a regular 8-bit RGB interleaved view. It will be immutable (unless you make an advanced dereference adapter that can do some sort of reverse lookup). But you should be able to copy it to a non-indexed rgb view, compute its gradient, make n-th channel view of its green channel, save it to a file, etc.
Understood (but that's how I thought it would work).
And to your earlier question, notice that the indexed view does not advertise that it has a larger capacity.
Well, once you have a mutable indexed view as an operation's destination (that's again the interesting case for me, since it requires a reference proxy object), one could certainly tell that 'advertising more capacity' as physically available - after all, performing a nearest color lookup or dithering involves data loss. There's not much difference between an adaptor silently chopping off some bits from the color channels, and
table. this
reverse lookup operation.
And what about the pixel type / memory representation dichotomy and
We are now outside the GIL realm and in the realm of best engineering practices. You could do a number of things: 1. Disallow modifying indexed RGB images 2. Have your dereference adaptor search for a perfect match, and throw an exception upon failure 3. Switch to the nearest match, with a lossy transformation. I wouldn't recommend this, but you could do it 4. Allow modifying the data only through the grayscale view, i.e. modifying the indices directly 5. Define a custom channel model, which will make your RGB indexed image incompatible with other RGB images and will prevent copying from one to another. Define channel conversion to allow your indexed image to be assigned another image only via color conversion, which is allowed to be lossy. the
pixel accessor solution for that?
I am trying to access Vigra's web page to read more about accessors before commenting on this but it seems to be down... In the meantime, I want to clarify a possible confusion: using PixelDeferenceAdaptor does not imply using a pixel reference proxy. They are not really related. The nth_channel_view of a typical memory-based image uses a PixelDeferenceAdaptor but a built-in C reference. GIL employs pixel reference proxy only to represent a reference to a planar pixel. Lubomir