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

From: Thorsten (th.behrens_at_[hidden])
Date: 2006-10-12 01:05:49

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.
 
And what about the pixel type / memory representation dichotomy and the 
pixel accessor solution for that?

Cheers,

-- Thorsten