[PD] colour and brightness (Was: Re: [GEM-dev] Why is [hsv2rgb] implemented as an abstraction?)

[Mathieu Bouchard]

On Wed, 12 Dec 2007, Claude Heiland-Allen wrote:

> Interesting, I'm in the process of experimenting a bit with different 
> colour spaces, got in a real headache with XYZ and CIE L*a*b and so on, 
> but YUV's simplicity may win.

Yes, XYZ and Lab and Luv are quite harder to wrap one's head around (in my 
opinion). I'd rather just stick with YUV. If I wanted things to look 
better I'd spend some time with gamma correction of both inputs and 
outputs, which probably accounts for most of the incorrectness of my 
colour models, and then I wouldn't go much further than that.

> and that seems to eliminate the bad brightness mismatches, at the cost of 
> some colours seeming a bit washed out (blue) or muddy (yellow).

This can be because you start with a colour that is not vibrant, even 
though it's the most vibrant version of the hue that you can do with the 
screen, and then you rotate it to another hue which still has plenty of 
headspace for being more vibrant.

But I'm thinking that this can also be because YUV is weighted so that it 
makes better use of the precision available in the signal, for typical 
colours, so that it is more resistant to noise. Therefore, U and V are not 
adjusted to cause equivalent saturation. This is something that you can 
fix with a diagonal matrix before and after each translation... if working 
with separate floats, this probably ends up being a pair of [*] boxes on 
either just the U or just the V, but I don't know what's the scale factor 
that you should use.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada