ImageMagick / ImageMagick/ImageMagick
LCHab not correctly supported with `-fill`
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 17.5k
- Forks
- 1.7k
- Avg merge
- 10h 17m
- Merged PRs (30d)
- 28
Description
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 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:
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() and hsb() work correctly.
@snibgo reported conversion is also broken on #8083 with:
lchuv and OHTA.
Images
Not required.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the provided magick minimal test case and compare the lchab() result with the expected hue. Trace the -fill and +level-colors color parsing and conversion paths, including the related lchuv and OHTA cases from #8083. Done means the input is either rejected clearly or converted to the current colorspace with correct hues.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- cli, computer-graphics
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100