icc:description: GIMP built-in sRGB, so that name could be strpos()'d. Sometimes the name of the profile suggests it's for RGB, e.g. If it's not determinable how many channels an icc profile is for (I personally don't know how to do it), then a poor-man's method could be employed, where imagemagick uses 'heuristics' to determine if the icc profile is for and RGB colourspace (the greyscale image vs rgb icc profile is arguably the 100% of cases of this problem). Also, a warning should be printed to stderr that imagemagick silently dropped the profile because it didn't match the image data. But perhaps something may be done about it?Īn immediate idea: when imagemagick determines that the number of channels in the image data doesn't match the number of channels the embedded icc profile is expecting, then imagemagick should not embed that profile when converting to pdf. ghostscript will fail to render it correctly to png.Īs I mentioned, this is not imagemagick's fault that the pdf is corrupted because the source file itself is technically corrupted. Still, however, the pdf remains corrupted and e.g. It works now.īy replacing the exclamation mark with letter 'a' above, the embedded icc profile in the pdf file gets corrupted which makes Adobe Reader silently fall back to interpret the image data with /DeviceGray colourspace, which display the document correctly. Vim will scroll to the following Save the file. Convert the IMG_4849.jpg mentioned in this ticket to IMG_4849.pdf.Once you manage to produce a corrupted pdf (it opens in latest Adobe Reader with error stating 'Insufficient data for an image.'), in order to prove that the error is icc-related, follow these steps:

So it might be worthwhile to look for a solution on an imagemagick level (similar to how ghostscript gracefully attempts to work with poorly written pdf files).Īgain, I'm not sure why you're not able to reproduce it but I'd like to ask you to try again. the image is 1 channel greyscale, but the profile is for a 3-channel RGB).Įven though imagemagick is doing the right thing during the conversion and the problem is clearly on the app that created the raster files, this issue is regrettably quite common. The quick&dirty solution is for the end user to either drop all icc profiles from greyscale images prior to conversion to pdf or drop the icc profiles only after ascertaining that they don't match the number of channels in the image (i.e. This is the same problem as the one worked out in the following thread: Version: ImageMagick 7.0.10-14 Q16 x86_64 Ĭopyright: © 1999-2020 ImageMagick Studio LLCįeatures: Cipher DPC HDRI Modules OpenMP(3.1)ĭelegates (built-in): bzlib freetype gslib heic jng jp2 jpeg lcms ltdl lzma openexr png ps tiff webp xml zlib

Pdf insufficient data for an image 2017