Geoffrey Romer wrote:
I suppose something more usefull would be a colour gamut conversion or something.
template <class Gamut, class Repr> bool inGamut(Gamut g, rgb_color<Repr> c)?
and inGamut(Gamut g, yuv_color<Repr> c), etc... . Would that work?
Yes, that makes sense. Let me be devil's advocate for a moment, though, because I think this example raises some interesting issues. I assume the idea here is to convert a color so that it's within the given gamut. In practice I think there would need to be more parameters because there's no single right way to map colors into a given color gamut (it all depends on what sorts of image features you want to preserve), but I'll bypass that for now.
I think a lot of the time, you simply want the closest possible colour that can be represented.
This example implies the existence of a Gamut concept, which inGamut presumably uses to determine the mapping. The thing is, I can't think of any way to define a color gamut that isn't in terms of a specific color space (e.g. as a polyhedral region in XYZ). So really, the example would need to be more like
template <class Gamut_rgb, class Repr> bool inGamut(Gamut_rgb g, rgb_color<Repr> c)
template <class Gamut_yuv, class Repr> bool inGamut(Gamut_yuv g, yuv_color<Repr> c)
If you have to deal with gamuts or colors in more than one space, this could kind of suck.
What I'm getting at, of course, is that it would be very nice to be able to write code which is generic not only with respect to color representation, but also with respect to the color model. That way one could write a single bool inGamut() template that would work anywhere. More generally, there are many operations one could imagine wanting to apply to colors, which don't require the colors to be represented in a particular model..
Why do you think I didn't give a body :D
Off the top of my head, I can think of two ways of implementing this. One would be to choose a single color space as canonical, and define all generic operations in terms of that space. Then, each new color space just needs to define conversion operations. This has several drawbacks, most obviously the problem of performance (conversion might not be cheap). In addition, there may be subtle correctness issues associated with the convert-compute-convert model. Finally, this would restrict the system to perceptual (as opposed to physical) color models, so that (for example) spectral color models would be disallowed (this is because the canonical model would have to be a perceptual model for performance reasons, and conversion from physical to perceptual color is an information-losing operation)
Interesting. Actually, now that I think about it, not very many representations are even perceptual (ie. have a colour profile associated with them, and thus a single real-world colour to map to.) I would therefore have to say, use the ICC Lxy (? the 'tongue' shaped one) physical colourspace as the canonical, require all colours to be a part of a colourspace (ie: sRGB<rbg_color<int> >. uggh. Defaults? Common types?) and simply declare gamut conversions expensive. (They are already lossy, so noone should be trying to do this a lot) There is actually room for optimisation here, most gamut conversions will be on large amounts of different colours at once with a single conversion, therefore some sort of palleted conversion could be possible. I'm not an expert here, so take all this with a grain of salt.
The alternative would be to try to decompose all "interesting" operations on colors into some fixed set of primitive operations, which each color space template would be expected to implement. More complex operations could then be defined generically in terms of those primitives. This would be elegant and efficient, but I have my doubts as to whether it's possible.
That _would_ be cool, but it does seem to be improbable.
Of course, my bias in this area is for more abstraction, because I'm more used to thinking of colors as abstract phenomena, without really getting my hands dirty with bits and bytes, so this may not be a practical idea.
At any rate, some sort of attention to the issue of conversion between color models would be worthwhile.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
True. But all this is somewhat off the original point (but still important).