Frequently Asked Question:

Return to FAQ Index

I have an image from a PDF file exported by Illustrator.

<</Intent/RelativeColorimetric/Subtype/Image/Length
55411/Filter/FlateDecode/Name/X/BitsPerComponent
8/ColorSpace/DeviceRGB/Width 186/DecodeParms<</Columns 186/Predictor
15/BitsPerComponent 4/Colors 3>>/Height 209/Type/XObject>>

Notice the /BitsPerComponent has a value of 8, but inside the /DecodeParms dictionary the /BitsPerComponent is 4.

It uses a PNG predictor with a different bit depth than the image itself, strange no?

Yes, it's strange. It looks like Adobe Illustrator uses a predictor offset of 2 bytes rather than 1 byte as the PNG specification suggests. This seems to come from the fact that the PNG specification doesn't allow 4-bit color images (only 8-bit and 16-bit color). With 1-bit, 2-bit and 4-bit mono images there isn't the same problem because there's only one component.

PNG doesn't support CMYK images - but PDF does. But with CMYK there are four components rather than three - so with 4 bits per component the pixel size is 4x4=16 bits which is an even byte multiple. With RGB the pixel size is 4x3=12 bits so pixels are stored in more than one byte. Instead of using a predictor offset of 1 byte (as the PNG spec suggests) Illustrator rather uses an offset of 2 bytes.

In versions of Quick PDF Library prior to 7.21 this oddity had the potential to cause problems when rendering these types of files created from Illustrator that used RGB -- but not documents that used CMYK. This issue has now been addressed in QPL, so it shouldn't cause any further problems.