Out-of-gamut pixels handling during RGB->CMYK conversion

[syl_leroux]

Hi everybody,

I use ImageMagick for many years now. But for the first time, I venture in the dangerous realms of CMYK decomposition & color profiles.

I managed to convert from RGB to CMYK without trouble by reading the doc:

Code: Select all

# RGB to CMYK conversion
convert "carte.png" \
            -profile /usr/share/color/icc/colord/sRGB.icc \
            -profile /usr/share/color/icc/colord/FOGRA39L_coated.icc \
            "carte.cmyk.tiff"
# "Verify"
display -profile /usr/share/color/icc/colord/sRGB.icc carte.cmyk.tiff 

My issue is I'm not sure to understand how are handle the out-of-gamut colors.
Were they replaced by the closest in-gamut color?
Or did they somehow pass-through the process? And if so, is there a way to identify the out-of gamut pixels in the converted image?

For refence here are my images:
* http://chicoree.fr/pub/IM/carte.png (RGB, no color profile, assuming sRGB)
* http://chicoree.fr/pub/IM/carte.cmyk.tiff (CMYK, FOGRA39L Coated color profile)

[snibgo]

For "-profile" conversions, out-of-gamut is controlled by "-intent". See http://www.imagemagick.org/script/comma ... php#intent

[syl_leroux]

Thank you for your reply Alan.

I read http://www.cambridgeincolour.com/tutori ... ersion.htm which gave me a better understanding of "-intent"

If I understand it well, after conversion IM guarantees NO color in the output file lies OUTSIDE of the gamut of the target profile. Or am I wrong?

[hr]

In all cases, that brings me back to the second part of my question: is there a way to identify which pixels were out-of-gamut?
I don't know if this is a standard practice, but I would envision some filter to produce a bitmap mask to discriminate in-gamut/out-of-gamut pixels. That would be a nice tool to see how many and where are located the out-of-gamut pixels.
Is this feasible using ImageMagick?

[snibgo]

For the meaning of "-intent", see also the ICC blurb at http://www.color.org/iccprofile.xalter

IM's "-colorspace" conversions can create pixels that are OOG, that is, they have values outside the range 0 to 100% when using HDRI, so identifying OOG is simple. But "-profile" is always inside gamut.

I think LCMS contains functions for identifying out-of-gamut pixels, but those are not used by IM.

It seems to me that the difference between an image and a round-trip "-profile" with "-intent absolute" should identify OOG. For example, IM v6 in Windows BAT:

Code: Select all

convert ^
  input.tiff ^
  ( +clone ^
    -intent absolute ^
    -profile sRGB.icc -profile CoatedFOGRA39.icc -profile sRGB.icc ^
  ) ^
  -compose Difference -composite ^
  -threshold 1%% ^
  out.png

The threshold is to ignore small rounding errors. The output is black where the input and the difference are roughly equal, so both profile conversions are inside gamut. The output is non-black where one or both conversions are OOG.

[syl_leroux]

For the meaning of "-intent", see also the ICC blurb at http://www.color.org/iccprofile.xalter

+1

IM's "-colorspace" conversions can create pixels that are OOG, that is, they have values outside the range 0 to 100% when using HDRI, so identifying OOG is simple. But "-profile" is always inside gamut.

I was suspecting something like that while reading the docs:
"The best solution for converting CMYK to RGB JPEG is to use color profiles with the "-profile" operator [rather than "-colorspace"]"

Yet, as far as I understand it, when using "-colorspace" there is no gamut involved. I mean, that operator does not take into account the physical limitations of the device. So strictly speaking, we can't talk of OOG with that operator. Or did I missed something?

It seems to me that the difference between an image and a round-trip "-profile" with "-intent absolute" should identify OOG

Great suggestion!
Indeed from what I can see, the output seems coherent with my images:
http://chicoree.fr/pub/IM/carte.err.tiff


Thanks a lot for you help!

[snibgo]

Yet, as far as I understand it, when using "-colorspace" there is no gamut involved.

For some colorspace conversions, eg between RGB, sRGB, CMY and CMYK, that is true. For these, there is a 1:1 mapping between the colorspaces, so colours are never out of gamut.

But for other conversions, that is not true. Lab, XYZ, xyY, YIQ have a larger gamut than sRGB. So all sRGB colours can be converted to Lab within gamut, but many Lab colours when converted to sRGB will be outside gamut.

"-colorspace" conversions are not specific to devices. "-profile" conversions are, eg a CMYK profile may be specific to one printer with particular inks and paper.

[syl_leroux]

Thank you a lot for all your comments and remarks Alan.

With your help, I managed to export my images as CMYK while minimizing color differences with the original RGB design.
Now this is in the hands of the printing shop. This will be the final test--result is a week or so!

[snibgo]

Good luck!

In principle, IM could be used for soft-proofing. That is, create an image on the screen that closely matches what the CYMK print should look like. But that probably needs a calibrated monitor, and experiments to get the process right.