Re: HLS and HSV in package colorspace [not whitepoint related]

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: HLS and HSV in package colorspace [not whitepoint related]

Paul Murrell-2

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


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
> says
> Also, in general, HSL and HSV are today computed directly from
> gamma-corrected <> /R/′,
> /G/′, and /B/′—for instance in 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
New Zealand
64 9 3737599 x85392
[hidden email]

[hidden email] mailing list -- To UNSUBSCRIBE and more, see
PLEASE do read the posting guide
and provide commented, minimal, self-contained, reproducible code.