Re: [boost] Interest in color library.

From: Simon Buchan (simon_at_[hidden])
Date: 2005-09-26 21:33:37

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).