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

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

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
[hidden email]
http://www.stat.auckland.ac.nz/~paul/

______________________________________________
[hidden email] mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.