On 11/26/2016 2:28 PM, Ive wrote:
> Am 11/26/2016 um 18:02 schrieb Mike Horvath:
>> On 11/20/2016 7:32 AM, Mike Horvath wrote:
>>> Done.
>>>
>>> https://commons.wikimedia.org/wiki/File:Cielch_color_solid_cylinder.png
>>
>> Done again.
>>
>>
https://commons.wikimedia.org/wiki/File:SRGB_gamut_within_CIELCH_color_space_isosurface.png
>>
>>
>
> Your description on the wiki page is partial misleading and partial wrong.
> It is not L*C*h, it's just LCh without asterix.
> CIE LCh(uv) means the polar representation of the CIE Luv color space.
> But what you are actually calculating is CIE LCh - the polar
> representation of the CIE L*a*b color space (just for historical reasons
> with asterix).
> sRGB fits very well into L*a*b and Luv as both cover the full range of
> visible colors - and there is no visa versa.
> So the question is: why are small bits hanging out at the corners?
> To me it indicates that there is something seriously wrong with that
> graphical representation.
>
> And while I'm at it, why do you use
> XYZEpsilon = 0.008856 and XYZKappa = 903.3
> where the CIE recommendation is 216/24389 and 24389/27 to avoid the
> discontinuity at the junction point for the lightness function.
> And why do you use D65 as reference white while e,g, the ICC, Adobe, HP
> and myself do use D50?
>
> And finally the appearance of your images at the page
> https://en.wikipedia.org/wiki/HCL_color_space
> doesn't make sense as this page is about LCh(uv) and not LCh.
>
> -Ive
>
>
>


You got me thinking, and I remembered something that confused me.

In the LCH to LAB conversion formula

#declare funcLCH2LABa1 = function(L,C,H) {L}
#declare funcLCH2LABa2 = function(L,C,H) {cosd(H) * C}
#declare funcLCH2LABa3 = function(L,C,H) {sind(H) * C}

the variable C is in the range of 0..100. However, A and B are supposed 
to be in the range of -128..128. As you can see, there is a difference 
of +-28 units. Thus, the sRGB space may extend outside LCH space in 
places, but still fit snugly within LAB space.

You can see here that the issue exists in the ColorMine library as well:

https://github.com/THEjoezack/ColorMine/blob/master/ColorMine/ColorSpaces/Conversions/LchConverter.cs

         internal static IRgb ToColor(ILch item)
         {
             var hRadians = item.H * Math.PI / 180.0;
             var lab = new Lab
                 {
                     L = item.L,
                     A = Math.Cos(hRadians) * item.C,
                     B = Math.Sin(hRadians) * item.C
                 };
             return lab.To<Rgb>();
         }

And when I use the easyrgb.com converter, I get correct output every 
time I test it. I suppose there's a chance both ColorMine and 
easyrgb.com are wrong. But I don't know where else to look.


Mike

Post a reply to this message