When embedding a CMYK JPEG in a Typst document, all sorts of things go wrong.

First, the PNG export and web app preview render the file as if you had let loose a toddler on all sliders in Photoshop:

This is because the image will convert the DynamicImage's image data to RGB in a naïve way.

But this is nothing against what is going on in the PDF. I converted the tiger.jpg from typst-dev-assets to CMYK with an ICC profile in Photoshop. When displayed with proper color management, the colors in the file closely resemble the original RGB file. I posted a repro project.

When we write the PDF, we are encountering the same problem as in PNG export: image has converted the buffer to RGB. Then, we start writing a color space which is when things go really awry. The image file contains an ICC profile, which we do not read but copy into the PDF. We then say that the profile has three components because we assume this for every color image, even when CMYK ICC profiles have four components. This really flabbergasts readers. Adobe Acrobat refuses to open the file altogether. Other viewers, given the mismatch between the actual profile and its metadata, fall back to the backup profile (sRGB) we wrote (or do not support ICC profiles at all and always fall back to a Device color space, like pdf.js) to show the same horrid color reproduction that we saw in the PNG export.

Proposed solutions

• To hotfix the PDF and not write corrupt files, we can read the image's color profile with qcms which we depend on anyways and discard it if it does not have the number of components we expect (three or one). This will allow Acrobat to open files made with CMYK images but do nothing about the fact that we convert them to RGB first and screw the colors up in the process. Doing this is not enough to close this issue.
• To address this problem fully, we should stop relying on image and instead support JPEG, PNG, GIF, and TIFF directly with its underlying crates. This will allow us to correctly detect the number of color channels in an image and perform the color management ourselves for PNG export. For PDF export, this will even provide a speedup (and, in the case of lossy compression, more quality) since we can cease to decode and reencode images throughout the compilation if we do not have to resize them.

When embedding a CMYK image in a SVG, both exports also provide bad (but different) results. I will file separately on svg2pdf.