I am having to deal with CMYK JPEGs extracted from a PDF source. The PDFs were created with Photoshop.

The problem is that Photoshop stores JPEG CMYK data in PDF/EPS using "normal" values, whereas in standalone JPEGs it stores inverted values. So, when the DCTDecode streams are extracted bytewise and written to disk, the resulting JPEG files appear inverted.

(The actual extraction is done by an in-house utility, which simply extracts the bytes from the DCTDecode stream and writes them, unmodified, to a file ending in .jpg It's basically a binary copy-and-paste. The PDFs are available to re-process, should that be required.)

As the images must remain in their JFIF format, is there any way to place a marker into the extracted .jpg file to make Photoshop open it with the proper encoding? The process must be lossless (not involve further entropy encoding).

The JPEGs already contain the APP14 marker, and removing it has no effect.

Below is a quote from the libjpeg docs:

"... it appears that Adobe Photoshop writes inverted data in CMYK JPEG files: 0 represents 100% ink coverage, rather than 0% ink as you'd expect. ... Photoshop 3.0 [and newer]... write uninverted YCCK in EPS/JPEG files... (But the data polarity used in bare JPEG files will not change...)"

  • 2
    Can't you just batch automate the conversion of the exported JPEGs back to regular CMYK encoding? Why do you need to flag the extracted files - you say all the PDFs werre created in Photoshop? – e100 Nov 27 '12 at 19:03
  • How are you extracting the JPEGs from the PDFs? Do you already have a folder containing many JPEGs which all need to be converted? It would be good to add this info into your original question. – e100 Nov 27 '12 at 19:12
  • If you are extracting the JPEG data programmatically, can you also automate the necessary arithmetic on the colour values at the same time? Not sure how easy this is. Yes, you are right, I was really wondering whether you had control of the extraction process, or just had to handle its output – e100 Nov 27 '12 at 19:28
  • @unsigned: if the color values are stored as floats, there could be large errors, but if they are stored as integers, then inverting them ought not be so problematic. I feel like you have left out part of the workflow in your question. Note however that CMYK is not supported by the JPEG format, but rather JPG2000. I don't know if this makes a difference for your choice of libraries... – horatio Nov 28 '12 at 15:12
  • 2
    I am referring to the original JFIF standard which supports 1 or 3 color (24-bit). Lack of CMYK support was rectified in a later standard. It used to be a problem when people would create jpegs from CMYK sources and try and use them on web sites. As far as workflow, you objected to e100's suggestion of using batch automation. Photoshop supports this. If the colors are simply inverted, then Photoshop can run a batch process such as "open, invert, save as" on an arbitrary number of files. – horatio Nov 28 '12 at 17:28

Here on Adobe forums is a same problem with successful results: http://forums.adobe.com/message/4271028

Maybe the APP14 tag is not correct? Theres more to APP14 tags than it just being there. On JPEG tags: http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html#Adobe

JPEG Adobe Tags

The "Adobe" APP14 segment stores image encoding information for DCT filters. This segment may be copied or deleted as a block using the Extra "Adobe" tag, but note that it is not deleted by default when deleting all metadata because it may affect the appearance of the image.

║ Index2 ║     Tag Name     ║ Writable ║               Values / Notes               ║
║      0 ║ DCTEncodeVersion ║ N        ║                                            ║
║      1 ║ APP14Flags0      ║ N        ║ Bit 15 = Encoded with Blend=1 downsampling ║
║      2 ║ APP14Flags1      ║ N        ║                                            ║
║      3 ║ ColorTransform   ║ N        ║ 0 = Unknown (RGB or CMYK)                  ║
║        ║                  ║          ║ 1 = YCbCr                                  ║
║        ║                  ║          ║ 2 = YCCK                                   ║

But that might not help, I recall someone stating that these private markers aren't intended to guide PDF-Readers but proper decode arrays should be.

The magic seems to be

/Decode 0 1 0 1 0 1 0 1

which would invert the color mapping. (I guess that's a flag in libjpeg, something similiar should be available in any similiar tool.) Decode arrays are common in PDFs according to the PDF Reference here: http://partners.adobe.com/public/developer/en/pdf/PDFReference.pdf

I have no clue if you can add these decode arrays into PDF JPEGs or do you need to add that to the stream processing of your in-house tool. I have no example PDF to work on, so I can't do any further research (also, the reference is huge - tl;dr - but you might have to..)

  • 1
    This helped me get a Photoshop CMYK JPEG embedded into a PDF to display correctly. I had to set the Image XObject's dictionary /Decode item to [1 0 1 0 1 0 1 0]. – Brecht Machiels Jun 19 '15 at 21:02
  • This helped me as well, and I can verify that, CMYK JPEGs that were inverted now render correctly. RGB ones do not need this for me... I have one question however, will this be true for ALL CMYK images, not just some? Also, will this (always) print correctly? (Thus not just for screen) – Marius Feb 9 '17 at 18:31
  • @BrechtMachiels Where do you set this? Can it be done with a simple hex editor? – Thomas Dec 18 '20 at 6:23
  • @Thomas I ran into this when trying to embed a CMYK JPEG into a PDF produced by my application which builds the PDF from scratch (look for adobe references in github.com/brechtm/rinohtype/blob/master/src/rinoh/backend/pdf/…. For an existing PDF, if the /Decode item is present, you might be able to swap the 0's and 1's. I failed to guess what your use case is, but if you're extracting a JPEG from a PDF, I think the extraction tool should really handle this... – Brecht Machiels Dec 22 '20 at 11:16
  • 1
    @Thomas (Sorry, I only see your comment now) This might be a bug in pdfimages (poppler): gitlab.freedesktop.org/cairo/cairo/-/issues/156. Or in the tool that created the PDF... The /Decode is (or rather, may be) in the PDF. You could try to swap the 0's and 1's in the PDF prior to running pdfimages, if the /Decode item is present. Alternatively, you could add (or remove) the APP14 from the extracted PDF. If you can share the PDF, I can try to have a quick look for you. – Brecht Machiels Jan 6 at 14:32

(Dislaimer: I have no image to test with - if you could share such an image by a file-sharing site I can test and make adjustments to answer if needed).

The problem is most likely related to missing ICC profile.

To embed (or convert) such a profile you can use f.ex. ImageMagick to do this loss-les without affecting the data.


The command line utility can be used as this to embed a ICC profile:

convert cmyk.jpg -profile USWebCoatedSWOP.icc cmyk_w_icc.jpg

Optionally convert it to native RGB color-space.

See here for more details:

You can download ICC profiles from here:


You can invert the colors with ImageMagick:

convert input.jpg -negate output.jpg

The result looks fine, but it might not be lossless. At least the file size seems to be significantly smaller in some cases.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy