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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
______________________________________________
R-help@r-project.org 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.
