-colorspace issue in 6.7.6-5 Win32

[henrywho]

Okay:- convert.exe rose: -resize 90% t_01.png
Very dark (not yet sRGB?):- convert.exe rose: -colorspace RGB -resize 90% -colorspace sRGB t_02.png
Okay again:- convert.exe rose: -colorspace RGB -resize 90% -set colorspace RGB -colorspace sRGB t_03.png

[fmw42]

Okay:- convert.exe rose: -resize 90% t_01.png
Very dark (not yet sRGB?):- convert.exe rose: -colorspace RGB -resize 90% -colorspace sRGB t_02.png
Okay again:- convert.exe rose: -colorspace RGB -resize 90% -set colorspace RGB -colorspace sRGB t_03.png

rose: is colorspace sRGB, which you can see from its verbose info.

The rest I will leave to Anthony to explain as it is all confusing to me also.

[henrywho]

I am just trying to do a colorspace-aware resize.

In 6.7.6-3, "convert.exe rose: -colorspace RGB -resize 90% -colorspace sRGB t_02.png" works as intended. But there were bugs with gray-colored image, as discussed in viewtopic.php?f=1&t=20658

It was said to be fixed in 6.7.6-4. Nevertheless, this time it screws up color images too. It appears that "-colorspace RGB" is not "tagging/flagging" the image data as linear RGB after conversion. Hence, we need an extra "-set colorspace RGB" to make the last "-colorspace sRGB" work as expected, converting the linear RGB data back to sRGB.

Edit: Further testing confirms this behaviour. Until fixed, I am now always "flagging" the input colorspace by "-set colorspace RGB/sRGB" according the source image, as well as "flagging" the colorspace after conversion, i.e., "-colorspace RGB -set colorspace RGB" and "-colorspace sRGB -set colorspace sRGB". Looking clumsy but still somehow logical manner. Color/Gray/Gray-stored-as-color images are all handled correctly under 6.7.6-5 when used in this way.

Edit(2): As for HSL, it seems that (s)RGB-to-HSL is always treating the source data as sRGB data (no matter the input is flagged as RGB or sRGB). On the other hand, HSL-to-(s)RGB seems to generating sRGB data flagged as linear RGB; hence, when we use "-colorspace sRGB", the sRGB data will be treated as linear RGB and converted to sRGB again, resulting in an excessively bright image. It seems to explain the "possible bugs" reported by Fred. To cater for this bug, we need "-colorspace RGB -set colorspace sRGB" after the conversion. The same applies for HSB I believe.

Edit(3): After testing all 8 combinations,

Code: Select all

for %I in (sRGB RGB) do for %J in (sRGB RGB) do for %K in (sRGB RGB) do convert rose: -colorspace %I -set colorspace %J -colorspace HSL -colorspace %K test_%I_%J_%K.png

Too bright: test_sRGB_RGB_sRGB.png, test_sRGB_sRGB_sRGB.png
Too dark: test_RGB_RGB_RGB.png, test_RGB_sRGB_RGB.png
Okay: test_RGB_RGB_sRGB.png, test_RGB_sRGB_sRGB.png, test_sRGB_RGB_RGB.png, test_sRGB_sRGB_RGB.png

Obviously, "-colorspace HSL" ignores how its input is "flagged" (i.e., %J above)

For the two "Too bright" cases, the input stays at sRGB (%I = sRGB) and the first "-colorspace sRGB" is not doing anything. So it is the second "-colorspace sRGB" which raises the brightness unnecessarily. i.e., it is fed with sRGB data "flagged" as linear RGB.

For the two "Too dark" cases, the input is converted to linear RGB (i.e., dark). As for the second "-colorspace RGB", it appears that no conversion is performed. i.e., it is really fed with something "flagged" as linear RGB.

For the four "Okay" cases, I think "test_RGB_*_sRGB.png" involves two unnecessary conversions (darken-then-brighten) and so "test_sRGB_*_RGB.png" looks like a better choice.

Hence, the correct command to use is:

convert rose: -set colorspace sRGB -colorspace sRGB -colorspace HSL -colorspace RGB -set colorspace sRGB output.png
[or]
convert rose: -colorspace HSL -colorspace RGB output.png

I believe that "convert rose: -colorspace HSL output.png" gives wrong result because it triggers an implicit sRGB conversion, making it equivalent to "convert rose: -colorspace HSL -colorspace sRGB output.png". And it produces a brightened image as explained above.

[anthony]

The colorspace cycle...

sRGB image -> HSL -> sRGB

is known to be broken, and has been reported. But no action has been taken at this time.
for example this produces a very light image (image is linear RGB not sRGB on save)

Code: Select all

  convert rose: -colorspace HSL -colorspace sRGB show:

It looks as if the HSL -> sRGB is failing as converting the image to RGB first does work!

Code: Select all

  convert rose: -colorspace HSL -colorspace RGB -colorspace sRGB show:

Strangely a sRGB -> RGB -> sRGB cycle is also coming out too dark.

Code: Select all

convert rose: -colorspace RGB -colorspace sRGB show:

The result of which is a resize with colorspace correction, which used to work but is now too dark!
convert rose: -colorspace RGB -resize 200% -colorspace sRGB show: