On Mon, Oct 09, 2006 at 03:36:01PM -0700, Lubomir Bourdev wrote:
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.
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