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