From: Thorsten Behrens [mailto:th.behrens@gmx.net]
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