You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When defining a color with -fill (or +level-colors), a parameter may be passed as lchab() (or other colorspace). No warning or error is issued, so the User can assume this is valid. However, the resulting color is not correct (hue is shifted). Discussed here: #8083.
Either the parameter should be rejected, or ideally the color is correctly calculated from the provided to the current colorspace.
Steps to Reproduce
Minimal test case: A hue=0 in LCHab should be red, but gives green:
ImageMagick version
7.1.1-47 Q16-HDRI aarch64 22763
Operating system
MacOS
Operating system, version and so on
15.4 (24E248)
Description
When defining a color with
-fill
(or+level-colors
), a parameter may be passed aslchab()
(or other colorspace). No warning or error is issued, so the User can assume this is valid. However, the resulting color is not correct (hue is shifted). Discussed here: #8083.Either the parameter should be rejected, or ideally the color is correctly calculated from the provided to the current colorspace.
Steps to Reproduce
Minimal test case: A hue=0 in LCHab should be red, but gives green:
magick -size 1x1 xc:'lchab(70,40,0)' -colorspace sRGB txt:
Other hues are also wrong, (e.g. 120˚ should give green, but is drawn as magenta).
It seems
rgb()
andhsb()
work correctly.@snibgo reported conversion is also broken on #8083 with:
lchuv
andOHTA
.Images
Not required.
The text was updated successfully, but these errors were encountered: