Difference between setColorspace and transformImageColorspace

[ameenross]

So the scenario is a CMYK PDF which I'm trying to convert to an RGB image (jpg/png). For the longest time I've been using transformImageColorspace, as @Danack pointed out to me on StackOverflow.

However, a colleague recently had the same scenario and he used setColorspace. Both solutions apparently result in a CMYK ⇒ RGB conversion. However, there's a pretty significant difference between the results. Here's a result with a test PDF.

Now I wonder what is the reason for this difference, which conversion is more "thorough", if at all? Like for example, does either method respect any embedded color profiles in the PDF? Thanks.

For reference, here's a test snippet.

$i = new Imagick;
$i->setResolution(150, 150);

$i->setColorspace(Imagick::COLORSPACE_SRGB); // Method 1.

$i->readImage("$argv[1][0]");

// $i->transformImageColorspace(Imagick::COLORSPACE_SRGB); // Method 2.

$i->mergeImageLayers(Imagick::LAYERMETHOD_FLATTEN);

$i->writeImage("$argv[1]-converted-setColorspace.jpg");

A third option would be commenting out the setColorspace line as well. That yields a CMYK jpg, which, if opened in my image viewer, looks the same as the image produced with transformImageColorspace.

[Danack]

I don't know.

I have a suspicion that one of the differences is the gamma/ramping for how intense colors are but I don't know the details.

does either method respect any embedded color profiles in the PDF?

Imagick is a pretty simple library around the ImageMagick library, and how ImageMagick works is....sometimes difficult to understand.

I actually really don't understand color profiles at all, so, please feel free to let me know what you find out.

[ameenross]

Alright fair enough. Maybe I can find out more if I know what both options are in terms of CLI switches to the Imagick binary. Could you tell me that?

[Danack]

in terms of CLI switches

That's not the right place to look for stuff, probably.

Imagick goes through the C api provided by ImageMagick. The details of that can be found on the ImageMagick pages.

https://imagemagick.org/api/magick-property.php
https://imagemagick.org/script/magick-wand.php

[ameenross]

So I've tried to use magick to extract color profiles. This PDF doesn't appear to have any, though I haven't really done this before so I'm not 100% confident that I'm doing it right. The resulting (CMYK) jpg also has no color profile. However I find it hard to believe that the actual pixel data will have changed from the CMYK PDF to CMYK JPG. So this confirms a suspicion I had and also seems to agree with this comment in the php.net docs: when using setColorspace, GhostScript is doing the CMYK ⇒ RGB conversion. Conversely, when loading the PDF as is, and then calling transformImageColorspace, ImageMagick will certainly be doing the conversion.

In the image in my OP, the left image looks closer to what various PDF viewers display when I open the PDF (various PDF viewers do not yield the exact same colors at all, by the way, but they're visually pretty close). So I suspect that GS just applies some sort of default color profile.

Actually, I think this confirms that the pixel data doesn't change:

[ameenross]

When I run the command with a higher resolution I have time to look at the gs process spawned by ImageMagick.

# setColorspace sRGB:
gs -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=pngalpha -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r600x600 -dFirstPage=1 -dLastPage=1 -sOutputFile=/tmp/magick-randomjunk%d -f/tmp/magick-randomjunk2 -f/tmp/magick-randomjunk3

# without setColorspace:
gs -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sDEVICE=pamcmyk32 -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r600x600 -dFirstPage=1 -dLastPage=1 -sOutputFile=/tmp/magick-randomjunk%d -f/tmp/magick-randomjunk2 -f/tmp/magick-randomjunk3

The filenames correspond to a link to the PDF, a file with a single byte, I'm not sure is very important, and the output file.

I called head -n 8 on the output file. In the setColorspace case:

�PNG
�
IHDR0�D*�� 	2iCCPdefault_rgb.iccH���gP�Y���<�@B�PC�*%��Z(ҫ� [snip]

And without setColorspace:

P7
WIDTH 12450
HEIGHT 17550
DEPTH 4
MAXVAL 255
TUPLTYPE CMYK
# Image generated by GPL Ghostscript
ENDHDR

Sure enough, when ImageMagick is told to work with sRGB from the get go, it asks a PNG from GhostScript. That then does the color conversion and you can even see the name of an ICC file in the resulting PNG file. If I run a similar gs command, I can debug the resulting PNG and extract the ICC file.

$ md5sum /usr/share/color/icc/ghostscript/default_rgb.icc /tmp/output.icc 
27d2435a749ae91e9974bf7a109a03e5  /usr/share/color/icc/ghostscript/default_rgb.icc
27d2435a749ae91e9974bf7a109a03e5  /tmp/output.icc

I'm assuming that GhostScript will also use default_cmyk.icc for interpreting the CMYK colors. Well, when I use GIMP to edit the PNG, without converting to sRGB, drop the color profile and export to a new PNG, I don't see any difference. So the difference must be coming from the CMYK side... which also makes sense because that is much more variable, due to wildly varying print processes, media and whatnot where CMYK is used.

So I guess that's it... Imagick must probably be told explicitly to use the default_cmyk.icc profile, then it will yield the same result (in the case of this specific PDF). But I guess when converting PDFs, it probably does make more sense to let gs handle it completely anyway.

[ameenross]

And sure enough, my theory is confirmed:

With this snippet I get the same result as with gs:

$i = new Imagick;
$i->setResolution(150, 150);

$i->setColorspace(Imagick::COLORSPACE_CMYK);

$i->readImage("$argv[1][0]");

// Tell Imagick something about color profiles.
// FOR ANYONE WHO CAME HERE VIA [insert search engine], DON'T DO THIS IN PRODUCTION.
$i->profileImage('icc', file_get_contents('/usr/share/color/icc/ghostscript/default_cmyk.icc'));
$i->profileImage('icc', file_get_contents('/usr/share/color/icc/ghostscript/default_rgb.icc'));

// Transform colors.
$i->transformImageColorspace(Imagick::COLORSPACE_SRGB);

$i->mergeImageLayers(Imagick::LAYERMETHOD_FLATTEN);

$i->writeImage("/tmp/test-tell-imagick-about-color-profiles.jpg");

[ameenross]

So to summarize:

• $i->setColorspace(Imagick::COLORSPACE_SRGB) makes sure GhostScript does the conversion to RGB
• using transformImageColorspace instead makes sure ImageMagick does the conversion to RGB
• GhostScript is better at this conversion due to how it handles color profiles
• ImageMagick could get a better result when you add extra logic around color profiles (but why bother? Just use GhostScript)
• you need to make sure you call setColorspace before readImage