Re: [boost] GIL & pixel accessors (was: Review of Generic ImageLibrary (GIL)begins today, Oct5, 2006)

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-11 19:23:03

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Thorsten
> Sent: Wednesday, October 11, 2006 10:06 PM
> To: boost_at_[hidden]
> 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
table.
> > 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
this
> reverse lookup operation.

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.

> And what about the pixel type / memory representation dichotomy and
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