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

From: Thorsten (th.behrens_at_[hidden])
Date: 2006-10-10 15:48:07

On Mon, Oct 09, 2006 at 03:36:01PM -0700, Lubomir Bourdev wrote:
> From: Thorsten Behrens [mailto:th.behrens_at_[hidden]]
> >
> > Pixel accessors make explicit what's worked-around by GIL's
> > PixelDereferenceAdaptor, namely that getting to the place where the
> > pixel is
> > stored and operating on the content of that in-memory representation
> > are
> > orthogonal concepts.
> 
> You could do the same with GIL. You could use a 16-bit unsigned pixel
> iterator (or image view) and attach to it a PixelDereferenceAdaptor that
> can provide an RGB 565 interface.
> 
> I disagree with your characterization of PixelDereferenceAdaptor as a
> "work-around". Pixel dereference adaptors are a powerful way to apply
> functional programming at the level of defining the color of a pixel
> with given coordinates. You can pipe them together similar to the way
> you can pipe image views. For example piping RGB-CMYK adaptor over
> nth_channel adaptor allows you to get the Cyan channel of an RGB image.
> 
Hi Lubomir,

ok, must have missed that aspect of the image view concept. So, if I get
all of that right, things work nicely as long as the pixel is able to
hand out an l-value for the individual channels to assign to (looking at
channel_assigns_t now), with the image views wrapping pixel_t
appropriately. 

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? 
Insofar, as then proxy objects are needed, similar to the vector<bool>
kludge?

> I agree promotion traits are useful, but they don't completely solve the
> problem. It is not always possible to provide generic definitions for
> the appropriate type to hold the result of an arithmetic operation.
> There are often multiple different choices which vary between speed and
> precision. For example, double may be a more precise holder of the
> result of float + float, but often float is a reasonable holder. It
> really depends on the requirements for your task.
> 
> This is why GIL's policy right now is to allow the client to specify the
> type of the result as a template parameter. Either way, if we end up
> using promotion traits, the proper place to place them will be together
> with imaging algorithms, in the future "numerics" extension.
> 
Fair enough - if you provide the flexibility to override the traits on
an algorithm-by-algorithm base, that's even better.

Cheers,

-- Thorsten