ImageMagick help

Dear Lazyweb, ImageMagick is tormenting me again. Help.

I need a single incantation that I can apply to an arbitrary image, be it an RGB JPEG, a CMYK JPEG, a PDF, a PNG, or whatever, and have it resized and converted to a web-usable RGB JPEG.

Back in 2010 and earlier when I was using, I think, ImageMagick 6.6.3-0 and earlier, that incantation was:

convert -density 300x300 IN -resize 1280x1280 -colorspace RGB -strip OUT.jpg

The "-density" argument is needed to tell it to internally render vector-graphics inside Illustrator and PDF files in a high resolution instead of rendering them tiny and then scaling them up. The "-colorspace" argument is needed to tell it to convert CMYK images to RGB instead of just passing that through, because CMYK JPEGs do not display correctly in all web browsers.

However, as I bitched about a couple of months ago, something has gone completely wonky with recent versions of ImageMagick.

Here's a test case. Help me figure out how to make this work!

Three test input files:

Try running the permutations:

for c in RGB sRGB ; do
  for f in test[123].jpg ; do
    convert -density 300x300 $f -resize 1280x1280 -colorspace $c -strip `basename $f .jpg`-$c.jpg
  done
done

Desired results: 1, 2 and 3.

When using colorspace "RGB", "test1-RGB.jpg" looks fine, but the other two come out solid black.

When using colorspace "sRGB", "test1-sRGB.jpg" comes out washed out (the blacks are light gray) but the other two look fine.

Even simpler test case:

convert rose: -colorspace RGB out.jpg    → black.
convert rose: -colorspace sRGB out.jpg   → fine.

I have tested this on MacOS 10.7.3 with ImageMagick 6.7.6-0 Q32 (installed with "port install ImageMagick +perl +jbig +q32") and on CentOS 5.4 / Linux 2.6 with ImageMagick 6.7.6-3 Q32 (installed from source with "configure --with-gslib --with-lcms --with-jbig --with-quantum-depth=32").

What's the fix?


Update: Turns out, ImageMagick hates being compiled with Q32. Rebuilding it with Q24 made the "all black images" problem stop. It didn't affect the "images are too dark or too light" colorspace problem, though, which I still have no idea about.

Tags: , , , ,

21 Responses:

  1. Sam says:

    Is there a way to tell the software to use a function called Black Point Compensation?
    CMYK colors when converting to RGB can, depending on their color build, translate to a washed out gray if it is not used. It pretty much tells the conversion process to look at a color that appears black, and increase it's density so that it will still appear black once converted. Usually, only left off when converting from CMYK profile to a different CMYK profile.

    Not using ImageMagick, I get similar results your problem in scenario 2/sRGB in Photoshop.
    my conversion with black point turned off
    my conversion with it turned on

    It also looks like your software is ignoring the embedded CMYK profile of your test document in either conversion method. In your CMYK test case above, it has an embedded profile of U.S. Web Coated (SWOP) v2, and both conversions are making the colors much more saturated than they should be, even the washed out one.

    Do you have any fine tuned control over how the software does conversions in ImageMagick?
    An example of the settings for conversion from Photoshop

    • jwz says:

      I have no idea.

      • Sam says:

        Doing a search through the documentation of ImageMagick, it appears you can only set the value for rendering intent. Without finer control of how the software handles conversion, I am not sure it will properly be fixed.

        Is it possible to write your script in a way that it will convert with RGB for CMYK files and sRGB for everything else?

  2. What forced you to change ImageMagick versions?

    • jwz says:

      I don't remember. Usually the answer is something stupid like, "some other port decided I needed a newer version of Perl, and that made ImageMagick stop working". But regardless, I rarely find "use a 2-year-old version of the software" to be a solution that continues working for long. Something eventually forces you to upgrade whether you like it or not, and eventually the old version stops building on modern systems.

  3. John Lenton says:

    As far as I can tell (and... I'm no kind of expert on this), it's the profiles info in the jpegs that is messing things up. Grabbing an RGB icc file off of the web (I googled for "CMYK.icc", which led me to Adobe), this worked:
    for i in test[123].jpg; do ./src/ImageMagick-6.7.6-4/utilities/convert -density 300x300 $i -resize 1280x1280 -profile Adobe\ ICC\ Profiles\ \(end-user\)/RGB\ Profiles/ColorMatchRGB.icc -strip `basename $i .jpg`-prof.jpg; done
    (note this version of ImageMagick behaves in the same way that you describe; my system version is older and has the swapped notions of RGB and sRGB, and is missing the blank-on-RGB issue you have).

  4. Applescript+graphicconverter/debabelizer? (I mean, yeah, it seems like this is the sort of thing you should be able to do in a shell pipeline using an OSS tool, but imagemagick seems to be determined to thwart you at every turn these days...)

  5. zee says:

    If you don't need to run this thing on Linux, you can use sips (a built-in command-line image manipulation utility on OS X):
    sips -m '/System/Library/ColorSync/Profiles/Generic RGB Profile.icc' --resampleHeightWidthMax 1280 test1.jpg

  6. Stefan Bethke says:

    What John says: it appears that ImageMagick's built-in profiles might not work properly, or might be thrown off by the embedded profile in test1.jpg. Using

    convert -density 300x300 test1.jpg -intent Perceptual -profile "Adobe ICC Profiles (end-user)/RGB/AdobeRGB1998.icc" -strip test1-rgb.jpg

    I get a decent looking rendering on 10.7.3 (Preview). It does look different from test2.jpg though (not sure you're expecting it to be identical).
    Interestingly, Preview displays test1.jpg washed out, like IM's -colorspace sRGB conversion.
    With the Adobe profile, the other two images come out (nearly) identical.

    • jwz says:

      I still get washed-out blacks doing this, with 6.7.6-0 and the profiles downloaded from Adobe.

      • Stefan Bethke says:

        How odd. I've just re-run the conversions, and it still looks fine to me in Preview. I've uploaded all the images as well as a list of installed MacPorts packages to a folder on my site. My conversions are the -stb ones.

  7. gio says:

    worked ok (ok=>not all black) for me using the vanilla brew install (convert 6.7.5-7) http://dl.dropbox.com/u/41604648/jwz.png

  8. gio says:

    i just recompiled using openmp and your configure options and got the all black image you described

  9. Does ImageMagick have a bug tracker? I doubt an all-black output image is a desired feature.

  10. Lloyd says:

    Have you tried emailing the authors of imagemagick?

  11. gio says:

    compiling with "--with-quantum-depth=[16|24]" works, [32|64], not so much. don't know why.

    • jwz says:

      Interesting -- compiling with Q24 makes the "black" images come out correctly, but the "washed out" images are still washed out.

  12. I'm using brew, not ports, it has slightly outdated version of ImageMagic, but brew proved itself as source of stable apps.
    $ convert -version
    Version: ImageMagick 6.7.5-7 2012-03-21 Q16 http://www.imagemagick.org
    Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
    Features: OpenCL

    All images converted successfully and their colorspace is correct. May I suggest a switch to Homebrew for you?

  13. danny says:

    There's a competing fork of ImageMagick called GraphicMagick that appears to have the colorspace line option:
    http://www.graphicsmagick.org/FAQ.html#how-does-graphicsmagick-differ-from-imagemagick

    The temptation to say "and now you have *four* problems" is overpowering, but it might help if you want to just try throwing forks at the wall until something sticks.