Csswg-drafts: [css-color-4] Predefined CMYK colorspace

[svgeesus]

Split out from the predefined RGB space issue

20 July 2016 CSS telcon:
~~ RESOLVED: add AbobeRGB and ProPhotoRGB as predefined spaces. Allow either the table of numbers or an ICC v.4 profile with relative colorimetric intent~~
RESOLVED: Add a single CMYK profile, with relative colorimetric intent, mainly to use as a fallback

[svgeesus]

CMYK ICC profiles are large, as they contain a 4D grid of measured colors sampled throughout the space. This could be added as a linked file, but could not be expressed as a table of chromaticities because printed color is non-additive.

For a single CMYK space, FOGRA 39 (ie ISO 12647-2:2004 / Amd 1) seems like a good choice as it is widely used in many countries, and is stable. Need to check with FOGRA if the profile is freely resistributable.

[Crissov]

I know next to nothing about the print industry, but from the little I just researched, if _ISO Coated_ (i.e. FOGRA 39 for v2 or FOGRA 51 for v3) was referenced in CSS, wouldnʼt support for ECI CMYK (i.e. FOGRA 53) make sense as well?

http://www.eci.org/en/colourstandards/workingcolorspaces

PS: eciCMYK has been updated in early 2020 to version 2, also known as FOGRA 59.

[Crissov]

PS: Fogra 39, which replaced Fogra 27, is equivalent to ISO 12647-2:2004 / Amendment 1:2007 (ISO Coated v2),
but apparently has been replaced by Fogra 51 and 52 which relate to ISO 12647-2:2013 (PSO Coated v3).

While earlier standards used the test chart from ISO 12642-1 = IT8/7.3 with 928 patches (S) or ECI 2002 with 1485 patches, current standards use ISO 12642-2 = IT8/7.4 with 1617 patches (L).
I assume that means new standards should not reference Fogra 39 anymore. 🤷‍♂

[svgeesus]

I attended a Color Experts day at FOGRA last year, it is follow-up from that event which leads me to suggest their characterization and profiles.

Yes, FOGRA 51 is the more recent target; it has a somewhat wider gamut and takes into account optical brighteners in the paper (which requires using a spectrometer with no UV-cut filter, for example). So if you are a commercial print house, and want consistent printing across all your sites, 51 is a better target.

For a single CSS predefined CMYK space (where people can't be bothered to create a profile), the more modest and widely supported FOGRA 39 looks like a better choice.

If people want a better profile, they can supply one.

[svgeesus]

So, device-cmyk now provides this functionality. If there is an @color-profile defined for device-cmyk, it will be used. Also, the default stylesheet now has

/* a reasonable, conservative default for device-cmyk */
@color-profile device-cmyk {
  src: url('https://drafts.csswg.org/css-color-4/ICCprofiles/Coated_Fogra39L_VIGC_300.icc');
}

so the use case for _"I want a CMYK, give me something reasonable, I don't want to bother profiling a printer"_ use case seems to be dealt with. The _"I want CMYK to mean this particular thing"_ is also dealt with (by user stylesheets).

So I think this issue can now be closed as solved.

[svgeesus]

A comment by Phil Green from the ICC leads me to re-open this issue. While the suggested color profile is correct and will give the expected results, it is larger than needed. He suggests that a smaller, custom profile with a sparser LUT could be created to meet this need. This would reduce download size while giving visually similar results.

[svgeesus]

I'm working with two Masters students from NTNU (Norway) to develop a smaller CMYK ICC profile based on the FOGRA39 characterization dataset.

[karip]

SVG Native might support FOGRA39 in the future, but embedded SVG Native renderers may not want to use complex ICC color profiles for color conversion. A set of approximation functions or a simple look-up table might be preferred.

That is also the approach taken by Firefox and Chrome PDF viewers to convert CMYK to RGB. Many PDF documents use Adobe U.S. Web Coated (SWOP) v2 color profile for CMYK colors. But, web browser PDF viewers don't use Adobe's ICC profile to convert SWOP colors to sRGB.

Firefox pdf.js uses a set of math functions for conversion:
https://github.com/mozilla/pdf.js/blob/a373137304b548620da2b82c00a4edb3538bc711/src/core/colorspace.js#L823

Chrome's PDFium uses a look-up table:
https://pdfium.googlesource.com/pdfium/+/refs/heads/chromium/2021/core/src/fxcodec/codec/fx_codec_icc.cpp#1274

I don't know why they don't use the real ICC profile, but few advantages of these approaches is that they take less space and are faster than full ICC color profile conversion. Embedded SVG Native renderers may take the same approach for FOGRA39. Just something for you to consider while developing the smaller ICC profile..

[svgeesus]

Hi @karip thanks for the pointers to CMYK conversions used by browser js-based PDF viewers. These seemed interesting so I took a deeper look. To date I just examined the PDFium approach.

I copied the PDFium code you linked to, made a few search and replace to use standard types (float, uint8_t`) and added a table of CMYK FOGRA39 values for the 24 swatches in a Macbeth color checker and wrote a main function to iterate over these, converting to sRGB. Modified code here and Macbeth color values in assorted colorspaces here. I then calculated the deltaE 2000 between the original Lab values and the sRGB values.

The result can be seen here, with an SVG of the converted colors and a table of deltaE 2000 values. For comparison, a similar analysis of roundtripping Lab -> CMYK -> Lab, again with deltaE 2000, and naive conversion from CMYK to sRGB which gives frankly comical results.

It seems that the PDFium conversion is significantly worse than the ICC approach (but as the ICC gives deltaE of like 0.04, it can be 25 times worse without actually being visible) and significantly better than the naive approach.

There are problems in the dark areas especially, which would crush shadow detail. I suspect this is because they are working on gamma-corrected sRGB values in the lookup table; if that table was populated by linear-light values, and the final linear-light sRGB value gamma corrected, I suspect this effect would be much reduced.

I will try to have a look at the pdf.js approach too.