 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/27/2016 3:19 PM, Mike Horvath wrote:
> 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
It turns out I was mistaken because this page
http://colormine.org/color-converter
says C in LCh should be in the range of 0..100, which apparently is not
the case. Instead it should be 0..128.
You were right in that sRGB should be fully enclosed within LCh.
Thanks for bringing it to my attention!
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I spent the week learning PSTricks and added axes and labels to the images.
https://commons.wikimedia.org/wiki/File:SRGB_gamut_within_CIELCH_color_space_isosurface.png
https://commons.wikimedia.org/wiki/File:SRGB_gamut_within_CIELAB_color_space_isosurface.png
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Overhead view of the sRGB gamut contained in an CIELCh Cylinder.
1. There's still a blue corner sticking out the side.
2. R, G and B don't seem equidistant around the circumference.
Mike
Post a reply to this message
Attachments:
Download 'cielch_color_solid_cylinder_isosurface.png' (58 KB)
Preview of image 'cielch_color_solid_cylinder_isosurface.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.12.2016 um 21:30 schrieb Mike Horvath:
> Overhead view of the sRGB gamut contained in an CIELCh Cylinder.
> 2. R, G and B don't seem equidistant around the circumference.
That's why it's L*C*h*, not LCH.
To my knowledge, the L*a*b* colour space (which is just the cylindrical
parameterization of L*C*h*) was designed for the purpose of
quantitatively measuring the perceived difference between two similar
colours.
All other properties of the colour model are secondary to that feature.
Most notably, it is even unsuited for quantitiatively measuring the
perceived difference between very distinctive colours.
Another side effect is that the L*C*h* hue parameter has nothing to do
with the hue known from the HSV and HSL colour models.
(That said, your conversion formulae may still be incorrect. The
pictures on Wikipedia agree with your representation, but that obviously
doesn't mean a thing in this particular case ;))
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/1/2016 4:13 PM, clipka wrote:
> Am 01.12.2016 um 21:30 schrieb Mike Horvath:
>> Overhead view of the sRGB gamut contained in an CIELCh Cylinder.
>
>> 2. R, G and B don't seem equidistant around the circumference.
>
> That's why it's L*C*h*, not LCH.
>
What does that mean?
> To my knowledge, the L*a*b* colour space (which is just the cylindrical
> parameterization of L*C*h*) was designed for the purpose of
> quantitatively measuring the perceived difference between two similar
> colours.
>
L*a*b* is rectilinear, L*C*h* is cylindrical.
> All other properties of the colour model are secondary to that feature.
> Most notably, it is even unsuited for quantitiatively measuring the
> perceived difference between very distinctive colours.
>
> Another side effect is that the L*C*h* hue parameter has nothing to do
> with the hue known from the HSV and HSL colour models.
>
It's pretty useless to me in that case. :(
> (That said, your conversion formulae may still be incorrect. The
> pictures on Wikipedia agree with your representation, but that obviously
> doesn't mean a thing in this particular case ;))
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.12.2016 um 22:20 schrieb Mike Horvath:
>> To my knowledge, the L*a*b* colour space (which is just the cylindrical
>> parameterization of L*C*h*) was designed for the purpose of
>> quantitatively measuring the perceived difference between two similar
>> colours.
>>
>
> L*a*b* is rectilinear, L*C*h* is cylindrical.
It's the same shape, the same space; it's just a different way of
specifying locations on that space. Just like polar coordinates are a
different way of specifying locations in planar 2D space. (And,
depending on how the value is stored, there may be different limitations
to what locations can be represented in that manner.)
>> All other properties of the colour model are secondary to that feature.
>> Most notably, it is even unsuited for quantitiatively measuring the
>> perceived difference between very distinctive colours.
>>
>> Another side effect is that the L*C*h* hue parameter has nothing to do
>> with the hue known from the HSV and HSL colour models.
>
> It's pretty useless to me in that case. :(
What do you intend to use it for anyway?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/1/2016 4:32 PM, clipka wrote:
>>> All other properties of the colour model are secondary to that feature.
>>> Most notably, it is even unsuited for quantitiatively measuring the
>>> perceived difference between very distinctive colours.
>>>
>>> Another side effect is that the L*C*h* hue parameter has nothing to do
>>> with the hue known from the HSV and HSL colour models.
>>
>> It's pretty useless to me in that case. :(
>
> What do you intend to use it for anyway?
>
I was hoping to use it as a replacement for HSL when picking colors. For
instance, someone is developing a LCH color picker for GIMP.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sphere.
https://commons.wikimedia.org/wiki/File:SRGB_gamut_within_CIELCH_color_space_isosurface_spherical.png
To do:
1. Make the axes and labels thicker and larger.
2. Offset the axes a bit from the actual x, y and z axes in order to
create some padding.
3. Make the axes dark gray instead of black.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
