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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-09 18:36:01

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. Vigra algorithms take a pair of pixel iterators
and
> accessors for source and destination. Thus, to be able to work on a
565
> packed
> RGB pixel type, one can reuse the int16 pixel iterator, and provide a
565
> pixel
> accessor. Very easy, very clean.

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.

> that getting to the place where the pixel is
> stored and operating on the content of that in-memory representation
are
> orthogonal concepts.

I agree, and GIL provides orthogonal ways of extending them.

You can use iterator and locator adapters (such as PixelStepIterator) to
define coordinate space transformations. Separately, you can use pixel
dereference adaptors to define color space transformations. You can
combine them to create views such as the upside-down view (spatial
transformation) of the green channel (color space transformation) of a
given image view.

> When it comes to image processing algorithms (I know that this is
> currently kind
> of a weak spot for GIL - but ultimately, of how much use is this lib
> without at
> least some basic processing functionality), I'd love to see promotion
> traits
> used. Otherwise, supporting mixed types (float and int, etc) for color
> channels
> generically would become rather hard...
> 

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.

Lubomir