possible colorspace issue IM 6.7.6.4 Q16

[fmw42]

IM 6.7.6.4 Q16 Mac OSX Snow Leopard.

I am not able to get a round trip separate and combine of the rose image when specifying either -colorspace sRGB or -colorspace RGB

This is too light.

convert rose: -colorspace sRGB -channel R -separate 1rose_r.png
convert rose: -colorspace sRGB -channel G -separate 1rose_g.png
convert rose: -colorspace sRGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -colorspace sRGB -combine show:


And this is too dark.

convert rose: -colorspace RGB -channel R -separate 1rose_r.png
convert rose: -colorspace RGB -channel G -separate 1rose_g.png
convert rose: -colorspace RGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -colorspace RGB -combine show:


This however works without any colorspace.

convert rose: -channel R -separate 1rose_r.png
convert rose: -channel G -separate 1rose_g.png
convert rose: -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -combine show:

convert rose: -colorspace RGB -channel G -separate 1rose_g.png
convert rose: -colorspace RGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -colorspace RGB -combine show:

[anthony]

try using -set colorspace XXX before the -combine

Using -colorspace modifies the grayscale image data!

This is one reason why I have never been happy with this 'hack' of specifying the combine colorspace.
The destination colorspace probably should be a argument of -combine as the input images does not contain this information.

[fmw42]

try using -set colorspace XXX before the -combine

Using -colorspace modifies the grayscale image data!

This is one reason why I have never been happy with this 'hack' of specifying the combine colorspace.
The destination colorspace probably should be a argument of -combine as the input images does not contain this information.

The problem is that I am trying to make several scripts behave as they used to before the swap of RGB and sRGB.

I will have to find out how to make it work with the current release and reinstall an older IM to be sure it still works right.

I was under the impression that if the input image is sRGB and I add -colorspace sRGB before the -separate, that it should not change the image data. Similarly adding -colorspace sRGB before the combine would also be a non-change. Is this an issue of going from 3 grayscale images to any colorspace when doing -combine, even for sRGB (previously RGB)? Seems like one used to be able to use -colorspace RGB before, but perhaps I do not remember correctly.


OK. These do work.


convert rose: -colorspace sRGB -channel R -separate 1rose_r.png
convert rose: -colorspace sRGB -channel G -separate 1rose_g.png
convert rose: -colorspace sRGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -set colorspace sRGB -combine show:


convert rose: -colorspace sRGB -channel R -separate 1rose_r.png
convert rose: -colorspace sRGB -channel G -separate 1rose_g.png
convert rose: -colorspace sRGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -set colorspace sRGB -combine -colorspace sRGB show:


So I suppose the latter with the added -colorspace sRGB is redundant and is not needed.

I will modify my script again and check my trapping in an old version of IM as well. Furthermore, now I need to figure out what to do before we had -set colorspace. It is getting hard to support lots of old versions.

Thanks.

[anthony]

I was under the impression that if the input image is sRGB and I add -colorspace sRGB before the -separate, that it should not change the image data.

If the image is already sRGB then it shouldn't change. except posibly in IMv7 of ensuring a grayscale image is converted to a three image sRGB. However is that conversion from a linear-GRAY or sGRAY???? This is an aspect that has NOT been looked at.

The problem with the -colorspace option (as it currently exists, and I have not changed it) is that it is not just an operator for existing images but also used as setting for FUTURE image reads.

Though I am not certain of exactly what it does for image reads as these are buried in the library core and individual coders. You'll have to ask "magick. I think the setting typically only sets the default colorspace when not defined by the image file format.

Unsetting it +colorspace will stop it effecting new image read, but that also effects
existing images by forcing them to be RGB! I would probably regard this as a bug -- and should be removed!

Fortunatally in parenthesis their are no images to effect, so...

Code: Select all

  convert image_reads...   -colorspace sRGB \( +colorspace \)  .....

Should apply the operator, then reset the setting for image reads to, well currently 'undefined'! Again I have no idea what effects setting it to undefined has, but the default setting normally is sRGB and not undefined! But that is what existing code does!

Really it depends on just what the operator does for new images.

Suggestions welcome as to what I should do about this! Feedback from magick would be most helpful at this point.

Similarly adding -colorspace sRGB before the combine would also be a non-change.

I would think so, but in IMv7 it probably depends on how conversions from single channel images are performed!

OK. These do work.

convert rose: -colorspace sRGB -channel R -separate 1rose_r.png
convert rose: -colorspace sRGB -channel G -separate 1rose_g.png
convert rose: -colorspace sRGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -set colorspace sRGB -combine show:

convert rose: -colorspace sRGB -channel R -separate 1rose_r.png
convert rose: -colorspace sRGB -channel G -separate 1rose_g.png
convert rose: -colorspace sRGB -channel B -separate 1rose_b.png
convert 1rose_r.png 1rose_g.png 1rose_b.png -set colorspace sRGB -combine -colorspace sRGB show:

So I suppose the latter with the added -colorspace sRGB is redundant and is not needed.

Do they work for IMv7 too? if so then grayscale images are actually sGRAY.

I will modify my script again and check my trapping in an old version of IM as well. Furthermore, now I need to figure out what to do before we had -set colorspace. It is getting hard to support lots of old versions.

I suggest you make an archive of your scripts from 'before IM version X.X.X' .

But if users want new features, they need the newer IM version too.

[fmw42]

If the image is already sRGB then it shouldn't change. except posibly in IMv7 of ensuring a grayscale image is converted to a three image sRGB. However is that conversion from a linear-GRAY or sGRAY???? This is an aspect that has NOT been looked at.

My tests were with the rose: image for which the verbose info says it is sRGB

Do they work for IMv7 too? if so then grayscale images are actually sGRAY.

I have not tested and would not think they would work as magick said he has not decided how to handle grayscale image promoted to color.


________

On a similar note, what happens if one has an image that has an undefined colorspace? How does IM handle it. Does it treat it as sRGB? My concern is that I am assuming the image can be converted from some colorspace (e,g, sRGB or CMYK) to sRGB. But what if the image does not have any colorspace assigned and I use

convert image -colorspace sRGB -channel R -separate result

Will it treat it as if it was sRGB and thus the -colorspace sRGB would have not effect?

[anthony]

Soem tests...

Note show: does not seem to automatically change colorspace, it simply displays the image data AS IS.
It is really just "miff:" piped into a background "display" command.

Code: Select all

convert -size 200x200 gradient:  show:

image data is normal linear data, displayed with more black than white (as typically seen)

Code: Select all

convert -size 200x200 gradient: -set colorspace undefined -colorspace RGB show:

image data has not changed...

Code: Select all

convert -size 200x200 gradient: -set colorspace undefined -colorspace sRGB show:

image data was modified to be brighter for sRGB usage (visually more equal in intensity)

As such it looks like 'undefined' is acting more like it is linear-RGB colorspace!

[fmw42]

As such it looks like 'undefined' is acting more like it is linear-RGB colorspace!

Do you think this should be changed so that it behaves more like sRGB?

[anthony]

I am not certain what undefined should mean.

It depends on what the -colorspace setting (setting not operation) means to images that are read in later!