[R] HLS and HSV in package colorspace [not whitepoint related]

[Paul Murrell]

Thanks Glenn.
I also favour restricting to sRGB<->HSV/HLS top remove ambiguity (so 
there is no direct conversion RGB<->HSV/HLS).
This would also be consistent with grDevices::rgb2hsv().

Paul

On 23/06/18 13:43, Glenn Davis wrote:
> Achim and Paul,
> 
> This is an entirely different subject - unrelated to whitepoint.
> 
> In the diagram I sketched, I made direct links between HSV and sRGB, and 
> HLS and sRGB.
> This is because the man page for HLS says:
> 
> This function creates colors in the HLS color space which corresponds to 
> the standard sRGB color space (IEC standard 61966).
> 
> and similarly for HSV.  But the C code in as_HSV()  actually does this:
> 
> case RGB:
> case sRGB:
>      for(i = 0; i < n; i++) {
>          RGB_to_HSV(REAL(color)[i], REAL(color)[i+n], REAL(color)[i+2*n],
>               &REAL(ans)[i], &REAL(ans)[i+n], &REAL(ans)[i+2*n]);
>      }
>      break;
> 
> And so both linear RGB and non-linear sRGB are converted to HSV in 
> exactly the same way.
> And it's the same for HLS (though not as obvious).
> My diagram does not match the C code since the code also has /direct 
> /links between RGB and HLS/HSV.
> This means that if one transforms from RGB to sRGB and then to HLS,
> it is not the same as  transforming from RGB to HLS in one step.
> A beginner probably would be surprised by this behavior.
> See an actual example below.
> 
> I can see the dilemma here.  The Wikipedia page
> https://en.wikipedia.org/wiki/HSL_and_HSV
> says
> Also, in general, HSL and HSV are today computed directly from 
> gamma-corrected <https://en.wikipedia.org/wiki/Gamma_correction> /R/′, 
> /G/′, and /B/′—for instance in sRGB <https://en.wikipedia.org/wiki/SRGB> 
> space—but, when the models were developed, might have been 
> transformations of a linear RGB space.
> So some authors use linear RGB and some use non-linear RGB.
> In the *colorspace *package there are really 2 HLS spaces - a 
> linear-based HLS
> and a non-linear based HLS.  It is up to the user to keep things straight.
> As protection against confusion, I see that many *colorspace * 
> conversions to and from
> HLS/HSV generate the error message
> error("Ambiguous conversion");
> There is no mention of possible ambiguity in the man pages.
> 
> So what I am really bringing to your attention is a mismatch between the 
> man pages
> and the code.   I see 2 ways to fix this mismatch:
> 
>  1. pick one HLS/HSV space (linear or non-linear) and stick to it and
>     document it.  I would recommend non-linear sRGB based on the
>     Wikipedia article.  Change the C code so it matches my sketch. 
>     There will no longer be any ambiguous transformations.
>  2. change the man pages and explain that HLS and HSV are currently
>     ambiguous, and so some conversions are also ambiguous.
> 
> I do not care, since I do not use these 2 spaces and probably never will.
> Option 1 might break someone else's package,
> so I would run this mismatch by your community of HLS/HSV users and see 
> what they think.
> 
> Glenn Davis
> 
> 
> An example of a non-commutative triangle:
> 
>> as( as( RGB(0.1,0.5,0.9), 'sRGB' ), 'HLS' )
>              H         L         S
> [1,] 201.7339 0.6519387 0.8698137
> 
>> as( RGB(0.1,0.5,0.9), 'HLS' )
>         H   L   S
> [1,] 210 0.5 0.8
>> 
> 
> Note that 201.7339 0.6519387 0.8698137 != 210 0.5 0.8
> 

-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul using stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/