On Tue, Oct 10, 2006 at 11:16:39AM -0700, Lubomir Bourdev wrote:
Thorsten wrote:
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.
How else would you then implement paletted images?
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.
I'm not questioning the necessity to abstract away internal memory representations - quite the contrary. My point is, that using pixel accessors as an explicit concept achieves this goal in a much clearer fashion, without all the drawbacks of reference proxy objects. Accessors just provide this proverbial extra level of indirection that's needed for most of the 'interesting' pixel formats. From a design POV, I'd favor a solution that models this aspect of the problem domain explicitely, if only for the fear that reverting to proxies could be limiting in certain cases (be it compiler idiosyncracies or hard language limits - sorry, no concrete examples, just a gut feeling). Cheers, -- Thorsten