Legacy ImageMagick Discussions Archive

IM 6.7.6.5 Q16 Mac OSX Snow Leopard.

With the switch between RGB and sRGB, I do not think that round trip conversion are working properly.

Note that the rose: image verbose info reports Colorspace sRGB


This works fine: This should be fine before or after the swap.
convert rose: -channel R -separate tmpR.png
convert rose: -channel G -separate tmpG.png
convert rose: -channel B -separate tmpB.png
convert tmpR.png tmpG.png tmpB.png -combine rose_rgb_roundtrip00.png

This fails as expected because it is being converted to RGB This was fine before the swap.
convert rose: -colorspace RGB -channel R -separate tmpR.png
convert rose: -colorspace RGB -channel G -separate tmpG.png
convert rose: -colorspace RGB -channel B -separate tmpB.png
convert tmpR.png tmpG.png tmpB.png -colorspace RGB -combine rose_rgb_roundtrip0.png

This works, but should not because the final -colorspace is RGB and seems like it should be -colorspace sRGB
convert rose: -colorspace sRGB -channel R -separate tmpR.png
convert rose: -colorspace sRGB -channel G -separate tmpG.png
convert rose: -colorspace sRGB -channel B -separate tmpB.png
convert tmpR.png tmpG.png tmpB.png -colorspace RGB -combine rose_rgb_roundtrip1.png

This does not work, but it seems that it should since all colorspace conversions are sRGB
convert rose: -colorspace sRGB -channel R -separate tmpR.png
convert rose: -colorspace sRGB -channel G -separate tmpG.png
convert rose: -colorspace sRGB -channel B -separate tmpB.png
convert tmpR.png tmpG.png tmpB.png -colorspace sRGB -combine rose_rgb_roundtrip2.png


Similarly for a round trip via HSL

This works, but it seems that it should not because the final -colorspace is RGB
convert rose: -colorspace HSL -channel R -separate tmpH.png
convert rose: -colorspace HSL -channel G -separate tmpS.png
convert rose: -colorspace HSL -channel B -separate tmpL.png
convert tmpH.png -colorspace HSL \
tmpH.png -compose CopyRed -composite \
tmpS.png -compose CopyGreen -composite \
tmpL.png -compose CopyBlue -composite \
-colorspace RGB rose_hsl_roundtrip2.png

This fails, but it seems it should be working as the final -colorspace is sRGB
convert rose: -colorspace HSL -channel R -separate tmpH.png
convert rose: -colorspace HSL -channel G -separate tmpS.png
convert rose: -colorspace HSL -channel B -separate tmpL.png
convert tmpH.png -colorspace HSL \
tmpH.png -compose CopyRed -composite \
tmpS.png -compose CopyGreen -composite \
tmpL.png -compose CopyBlue -composite \
-colorspace sRGB rose_hsl_roundtrip3.png


Is this a bug? If not, please explain, because it is certainly not consistent terminology. And one should not have to insert -set colorspace to get around it, in my opinion.

I just realize that this is somewhat a continuation/duplication of my earlier post in the developers forum at viewtopic.php?f=3&t=20682.

However, it seems that in the switch between RGB and sRGB (as Anthony pointed out), that the gray images are not being treated correctly to be consistent with -colorspace sRGB at the end of the combine commands.

Before the switch, using -colorspace RGB (which was really sRGB) worked fine, which I think meant that gray images were actually sRGB. Now it appears that gray images are RGB and so the -colorspace sRGB at the end is converting them from RGB to sRGB, which does not return the image back as a proper round trip.

I think this should be corrected for consistency both with prior to the swap and with consistent terminology for using -colorspace at the beginning for the separate and for the combine at the end.

This way the -set colorspace will not be needed in these cases, which it appears is now necessary.

fmw42 wrote:IM 6.7.6.5 Q16 Mac OSX Snow Leopard.

With the switch between RGB and sRGB, I do not think that round trip conversion are working properly.

Note that the rose: image verbose info reports Colorspace sRGB

I confirmed that the round trip is not working.

I added some validation tests to the sources of both IMv6 and (in development) IMv7.

Average "rose:" Color 146,89,80 sRGB(rose)
Too Light Color 73,26,21 sRGB(rose)->RGB result
Too Dark Color 199,160,152 RGB(rose)->sRGB result

sRGB(rose)->RGB->sRGB TOO_LIGHT

The first are is sanity checks. the last is the round trip test, and seems to be not applying the RGB->sRGB conversion.
ASIDE: IMv7 is failing even worse!

We can reproduce the problem you posted and have a patch. Look for it in the ImageMagick 6.7.6-6 release sometime this week.

I have confirmed that colorspace tests for round trips are now all working correctly.
will show a correct (not too dark or too light) rose image.

anthony wrote:I have confirmed that colorspace tests for round trips are now all working correctly.

Code: Select all

   convert rose:  -colorspace HSL  -colorspace sRGB show:

will show a correct (not too dark or too light) rose image.

Anthony,

Not for me in IM 6.7.6.6 Q16 beta. The ones in my first post work now for HSL, HSB, but if you use YUV and some of the others, they do not work (going the long way as a round trip) as of my tests earlier today.

Fred

P.S. I will check tomorrow. Perhaps Magick fixed them after I tested twice. Perhaps you got a newer beta than I did.

I added YUV and OHTA to the round trip tests...

No problems.
Note that these tests are round trip tests, They actually do not check if the actual destination colorspace is actually correct, only that the conversion to and from that colorspace produces a symetrical result at least within 8-bit accuracy (test is done at 16 bit)

Fred and magick and Anthony: Thank you lots for fixing this!

Just one word of warning, the above are purely round-trip tests.

It does NOT actually test is a specific color is mapped correctly to a specific values in the destination colorspace.
with an exception for RGB <-> sRGB conversions (as a sanity check).

The color being used for the test is the average rose image color. Specifically...

The Dalai Lama to the rescue: http://www.4p8.com/eric.brasseur/gamma.html. If the result of 50% resize through linear light looks like His Holiness, but the straight through sRGB result looks "empty", that's a pretty good indication that IM does what it's supposed to w.r.t. RGB <-> sRGB.

It does.

From the same page I rather like the Sucks-Rules test image

However the page has been updated with the latest fixes that IM uses and IM passes the tests when images are correctly processed with colorspace or gamma correction. It also points out that the two are slightly different, but with the most differences in the extreme dark colors.

Am I missing something? I would expect rose1.ppm and rose2.ppm to be identical, but they are not.
However, withrose1.ppm and rose2.ppm are identical.

I thought that if not colorspace was set, sRGB was assumed? No more? @Anthony: Is this one of your new API changes?

magick rose: rose.ppm
rose.ppm -colorspace RGB -filter Box -resize 35x23 -colorspace sRGB rose1.ppm
magick rose.ppm -colorspace RGB roseRGB.ppm
magick roseRGB.ppm -filter Box -resize 35x23 roseSMALL.ppm
magick roseSMALL.ppm -set colorspace RGB -colorspace sRGB rose2.ppm

In your second line above, magick is missing at the beginning. Is this just a type in the forum?


Also, I don't know if this is relevant, but I think there still may be bugs in colorspace. see viewtopic.php?f=3&t=20826. I expected to see differences visually, but perhaps I am wrong.

NicolasRobidoux wrote:@Anthony: Is this one of your new API changes?

No it isn't.

All API changes so far is minimal. And listed on Porting. Major changes to various options will take place in beta development.

fmw42 wrote:In your second line above, magick is missing at the beginning. Is this just a type in the forum?

It was a typo. I use prefixed installs these days, and accidentally cut more than the prefix in the post. Now fixed.
Thank you Fred. (I need to thank Fred, Anthony and Cristy so often that there should be acronyms: TYF, TYA and TYC.)

BTW: Pointing image processing tech people to http://www.imagemagick.org/script/porting.php is getting me some \o/ in the return mail.