IM7 sRGB v4 rendering intent

[NicolasRobidoux]

I'm not sure the following is flexible enough: How would it handle a stripped image that contains, say, sRGB v4 data which you want to process literally, but convert at the end to another colour profile? To do that, you need something like my suggested -tag or -interpretation, which does more or less what the old -colorspace did (I think).
Not sure of anything yet. Just stirring the pot. Because, however, you already have decided to change what -colorspace does for IM7, a clean break, as suggested in the Developers forum, may be a good idea.

Posible solution...

Images that are read with a ICC/ICM profile probably should be marked as having a colorspace of "profile".

That way when you do -colorspace RGB it first converts the colors from the 'profile' to RGB. Later when you do -colorspace 'Profile' it converts back to the colors as per the current profile (whatever that is at that moment).

In this scheme -profile to -profile conversion will ONLY happen if the -colorspace is currently set to 'profile'.

Also in this scheme a ICC profile is ONLY saved if the image is using colorspace 'profile', though I supose it could remain the users responsability to either remove or set the profile right if -colorspace is not set to 'profile' ???

Does this sound reasonable? It should solve quite a few problems, and looks to be mostly backward compatible. That is -profile to -profile conversion still works when it is appropriate, but it links better to the -colorspace image attribute.


Questions: How do profiles list image colors? In terms of XYZ coordinates? I have no idea about the mysterious internals of profiles. Perhaps I don't really need to know!

I think that you basically have a choice of one of three definition "anchors": XYZ, linear RGB, or CMYK. And that things are actually more complicated than that.

If I understand correctly, IM basically has two "colourspaces" (correct me if I'm wrong): linear RGB(A) and sRGB(A). Again if I understand correctly, all that's needed is a clean way to:
1) navigate between linear RGB(A) and sRGB(A) (this involves two pieces: tagging, and converting.)
2) import into/export from each of them with a profile, ideally with some control over the rendering intent (again, this involves two pieces: tagging, and converting).
(In some cases, explicit tagging is unnecessary, but not always.)

2) could be simplified by deciding to always ICC into and out of as if one is in one of the two "colourspaces", which means that a user who knows what he/she is doing would have to remember to convert back to this one if they're not already, before exporting. Not so good in 8-bit.

I sort of see the attraction of always seeing import and export as two halves of a unit, but I think that there are strong advantages as seeing them as separate operations. I think it's more powerful to see import (or tag)/colorspace and colorspace/export as separate pairs.

An added bonus would have to do with having defaults being reasonably picked when the incoming image does not have an embedded profile, and when writing. However, if one sees profile/colourspace handling as an expert setting, this is not as needed.

[NicolasRobidoux]

@Anthony: I'll postpone thinking about this carefully until later. I'm rushing my opinions out, and I'm not sure that this is most conducive to progress.
I still believe that my -import/-export/-colorspace/-interpretation (and, ideally, -intent) solution is conducive to clean toolchains, and that it should be reasonably easy to implement given what's in IM already. But I can't tell whether your proposed solutions are a clear step in the right direction without thinking slowly and probably studying profiles and looking at the code, and I can't these days.

[anthony]

Subject: IM7 sRGB v4 rendering intent

If I understand correctly, IM basically has two "colourspaces" (correct me if I'm wrong): linear RGB(A) and sRGB(A).

ImageMagick has about a dozen colorspaces!!!

Code: Select all

  magick -list colorspace  | fmt

CMY CMYK Gray HSB HSL HWB Lab Log OHTA Rec601Luma Rec601YCbCr Rec709Luma Rec709YCbCr RGB sRGB Transparent XYZ YCbCr YCC YIQ YPbPr YUV

Colorspaces keep track of what the image channel values mean in terms of color. That is all it does! Sounds exactly like what a profile does

In IMv6 it also specifies what channels exists (CMYK == black channel). In IMv7 any channel can exists (or not) as long as channels 'required' by the colorspace exists.

Other points under discussion...

• At this time more operators do not look at or worry about colorspace, and just assume the user knows what he is doing.
  • This makes 'drawing' in linear RGB with a sRGB named color VERY difficult.
  • composing or appending images in different colorspaces does not work right.
• There is erratic discussion about whether we should have a 'sGray' colorspace, and my thinking is YES.
  • Mostly due to 'auto-colorspace' conversion to Gray, for write to MIFF and TXT images, causing loss of sRGB/RGB status on read.
• Also when reading/writing PNG image saves, should it allow saves of linear 'RGB' type PNG images, or only on a coder define.
• PbmPlus images historically are linear-RGB values only, not sRGB (only exception?)
• -colorspace setting effects on some coders! (change to a special coder define?)
• Should gradient (which generates a linear gradient) default to a linear-RGB colorspace?
• Should "gray()" colors be RGB or sRGB?
• what about the colorspace of "#RRGGBB" colors

[NicolasRobidoux]

I actually have used some of the alternate colourspaces myself! (How could I forget?)

[NicolasRobidoux]

@Anthony:

There is something I just don't understand.

Now that you have removed the "interpret the image as belonging to this colorspace" meaning for -colorspace, and instead have it mean "convert this image data to this colorspace", I don't understand how you communicate to IM that the pixel data is, say, already sRGB or YCbCr, and that you'd like to convert it to, say, (linear) RGB.

The way I understand thing, you need a pair:
-interpretation tells IM how to interpret the pixel values
-colorspace tells IM to convert to a colorspace

For example, to tell IM that what is in the incoming image is YCbCr, to resize in linear light, and to save as stripped sRGB, you could do something like

Code: Select all

magick INPUT.IMG -interpretation YCbCr -colorspace RGB -resize WIDTHxHEIGHT -colorspace sRGB -strip OUTPUT.IMG

(Of course I'm being a bit sloppy RE: how YCbCr is gamma'd... Let's assume that YCbCr is always used with the same "profile". I'm also ignoring ICC issues. One thing at a time.)

[fmw42]

Perhaps use -set colorspace

magick INPUT.IMG -set colorspace YCbCr -colorspace RGB -resize WIDTHxHEIGHT -colorspace sRGB -strip OUTPUT.IMG

[NicolasRobidoux]

Fred: Indeed! http://www.imagemagick.org/script/comma ... ns.php#set.

Signed: Nicolas "RTFM" Robidoux

[NicolasRobidoux]

...
Does this sound reasonable?
...

Yes.

[fmw42]

I was not sure if that had changed in IM 7. As I understand it, other than RGB,sRGB,CMYK,Gray IM does not keep track of any other colorspace. So for those one has to identify it to IM using -set colorspace. But I don't know how/if this will eventually change in IM7. We are now just getting all the ramifications of the RGB vs sRGB swap worked out in IM6/IM7. It needed to be done, but I am sure was lots of work for Magick. I am still working on my scripts to deal with this issue. I am not sure, but there may still be issues with grayscale (Gray vs sGray). Then there is still the issue of defining colors as rgb(...) vs srgb(...). I am not sure how all this will work out yet, even in IM6. I think this will take some time for it to all get worked out.

see my recent bug reports at:
viewtopic.php?f=3&t=20806
viewtopic.php?f=3&t=20751

[NicolasRobidoux]

Fred: Many many thanks! viewtopic.php?f=3&t=20751#p83509 definitely has the potential to mess up my student Adam Turcotte's thesis, and we use bleeding edge.

[fmw42]

Fred: Many many thanks! viewtopic.php?f=3&t=20751#p83509 definitely has the potential to mess up my student Adam Turcotte's thesis, and we use bleeding edge.

Apart from the CMYK separation, we believe that all the other tests are working in both IM6 and IM7 as of the current release 6.7.6.6. But please report any odd issues you may find so that we can verify.

[NicolasRobidoux]

I verified that the tests pass, and once Adam runs the test suite (still tweaking, and, from scratch, it runs for a long time) it will reveal "oddities".

[henrywho]

Fred: Many many thanks! viewtopic.php?f=3&t=20751#p83509 definitely has the potential to mess up my student Adam Turcotte's thesis, and we use bleeding edge.

Please also make sure that all his test images are colored. viewtopic.php?f=3&t=20789#p83737

[fmw42]

Fred: Many many thanks! viewtopic.php?f=3&t=20751#p83509 definitely has the potential to mess up my student Adam Turcotte's thesis, and we use bleeding edge.

Please also make sure that all his test images are colored. viewtopic.php?f=3&t=20789#p83737

All my previous tests used sRGB or CMYK ( color images, e.g rose: or logo:). I suspect so did Anthony

But the post you referenced regards grayscale. Can you explain further? I don't really understand the issue. However, perhaps the IM developers know what you are questioning/asking.

[NicolasRobidoux]

I think that henriwho was saying that Adam and I should only use colour images for Adam's test suite, to avoid whatever complications greyscale may bring. (Earlier versions of the test suite did use some greyscale images.) The new test image bank will only contain sRGB colour images: http://web.cs.laurentian.ca/nrobidoux/m ... 840images/