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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-10 14:16:39

Thorsten wrote:
> 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.

Being able to provide l-value for the individual channels is not a
requirement of PixelDereferenceAdaptor. For example, the virtual image
view of the Mandelbrot set (see tutorial) is created with a model of
PixelDereferenceAdaptor which does not allow for writing (i.e. changing
the values of the Mandelbrot set). Thus pixel dereference adaptors may
be mutable and immutable (see the concept description). When you attach
an immutable dereference adaptor to a view, you will get back immutable
(read-only) image view.

nth_channel_deref_fn is another model of PixelDereferenceAdaptor that
given a pixel returns a grayscale pixel of its n-th channel. Its
mutability is determined by the mutability of its source. When you use
it over a Mandelbrot set, for example, you get immutable grayscale view.
But if you apply it over a regular mutable view, you get back a mutable
grayscale view.

> 
> 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. The capacity is a property of the
channel type (see channel_max_value). If you use a
PixelDereferenceAdaptor to transform a gray16 pixel to an rgb565 pixel,
your pixel dereference adaptor defines the type of the result. That type
is picked up by constructs that use it. So your iterator/locator/image
view that has the above adaptor will report that their pixel type is
rgb565 pixel, and if you ask for the max value of the first channel you
should get 31 (assuming you have defined everything properly).

> 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.

Lubomir