search

gtaylor / python-colormath

A python module that abstracts common color math operations. For example, converting from CIE L*a*b to XYZ, or from RGB to CMYK
python-colormath.readthedocs.org
BSD 3-Clause "New" or "Revised" License
456 stars 82 forks source link

RGB clamped to zero when converting from La*b* #87

Open pnorman opened 6 years ago

pnorman commented 6 years ago

Lab has a gamut that exceeds sRGB. A La*b* colour may require primary values which no only exceed 1.0, but also are under 1.0. The documentation states

RGB spaces tend to have a smaller gamut than some of the CIE color spaces. When converting to RGB, this can cause some of the coordinates to end up being out of the acceptable range (0.0-1.0 or 1-255, depending on whether your RGB color is upscaled).

In at least one case, the values reported are clamped, even though unclamed values are requested.

As an example,

>>> convert_color(LCHabColor(lch_l=45,lch_c=40,lch_h=230), sRGBColor)
sRGBColor(rgb_r=0.0,rgb_g=0.4690,rgb_b=0.6157)
>>> convert_color(sRGBColor(rgb_r=0.0,rgb_g=0.4690,rgb_b=0.6157), LCHabColor)
LCHabColor(lch_l=46.6732,lch_c=31.3686,lch_h=243.1561)

A bit of trial and error finds the right value for the sRGB r primary is -0.9

>>> convert_color(sRGBColor(rgb_r=-0.9,rgb_g=0.4690,rgb_b=0.6157), LCHabColor)
LCHabColor(lch_l=44.6461,lch_c=40.8891,lch_h=229.9607)

The number of significant figures has been reduced for readability in the text above.

It's also worth noting that clamping is different than a proper handling of out of gamut colours

KelSolaar commented 6 years ago

I think we will have to look at the whole clamping behaviour, ideally I think we should not clamp anything or just when performing final conversions to integers. It relates to #64.