Page 1 of 1
Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-12T09:16:15-07:00
by 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)
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-12T09:35:10-07:00
by snibgo
For "-profile" conversions, out-of-gamut is controlled by "-intent". See
http://www.imagemagick.org/script/comma ... php#intent
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-12T12:45:15-07:00
by 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?
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-12T13:51:51-07:00
by 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.
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-13T02:55:45-07:00
by syl_leroux
+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!
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-13T03:24:42-07:00
by snibgo
syl_leroux wrote: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.
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-14T12:58:49-07:00
by 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!
Re: Out-of-gamut pixels handling during RGB->CMYK conversion
Posted: 2017-04-15T01:21:42-07:00
by 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.