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, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 17:28

3 Answers 3


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]. Jun 19, 2015 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, 2017 at 18:31
  • @BrechtMachiels Where do you set this? Can it be done with a simple hex editor? Dec 18, 2020 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... Dec 22, 2020 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. Jan 6, 2021 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 and acknowledge you have read our privacy policy.