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

From: Thorsten (th.behrens_at_[hidden])
Date: 2006-10-11 09:37:12

On Tue, Oct 10, 2006 at 11:16:39AM -0700, Lubomir Bourdev wrote:
> 
> Thorsten wrote:
> > 
> > Looking further, am I right that having pixel types that advertise a
> > value type they hold no internal representation for (e.g. 1,2,4,8 bpp
> > grey scale packed pixel formats; or palette images, that present a RGB
> > truecolor interface, and internally perform palette lookups) pose
> > problems?
> 
> GIL pixels/channels should never advertise that they have larger
> capacity than they actually do.
>
How else would you then implement paletted images? 

> > Insofar, as then proxy objects are needed, similar to the vector<bool>
> > kludge?
> 
> Yes, GIL uses a reference proxy object to represent a reference to a
> planar pixel. There are a number of implications to this, among which is
> that all GIL pixel iterators cannot be Random Access Iterators, but are
> Random Access Traversal Iterators. And yes, it is not possible to create
> a class that behaves like a native C reference in all contexts, but we
> feel that the benefit of being able to abstract away the fact that the
> image could be planar or interleaved is well worth using a proxy
> reference class.
> 
I'm not questioning the necessity to abstract away internal memory
representations - quite the contrary. My point is, that using pixel 
accessors as an explicit concept achieves this goal in a much clearer
fashion, without all the drawbacks of reference proxy objects. Accessors
just provide this proverbial extra level of indirection that's needed
for most of the 'interesting' pixel formats. From a design POV, I'd
favor a solution that models this aspect of the problem domain
explicitely, if only for the fear that reverting to proxies could be 
limiting in certain cases (be it compiler idiosyncracies or hard
language limits - sorry, no concrete examples, just a gut feeling). 

Cheers,

-- Thorsten