COLRv2 Support CMYK #46
Comments
|
CMYK representations may be somewhat problematic in that they depend on particular inks/pigments and so are device specific. I think CMYK values would need to be accompanied by some profile metadata that mapped the CMYK primaries into a device-independent representation (e.g. XYZ, Lab). |
|
Yes, I agree with @PeterCon ... If you go down the path of specifying inks and colorants, you would have to specify fallbacks (e.g. if your renderer cannot represent extreme colours) and a whole lot of other things more in the domain of color management. Think emoji's with realistic skin tone colors... :-) |
|
Great, I agree, that will be needed. Let's do it! |
|
The right answer to this, as it is for SVG proper, is to rely on CSS-Color-4 (https://www.w3.org/TR/css-color-4/) as the way to specify non-sRGB colors (be they CMYK, ICC, etc) |
|
That sounds good, just as the svg table refers to a w3c spec and avoids
reinventing the wheel
|
|
Excuse me, please let me ask an off-topic question... a JPEG image with the CMYK color profile is acceptable in SVG (in OpenType) ? |
|
How are CMYK images processed in general? If I add a CMYK JPEG to an Illustrator file or a Google doc, how is it rendered on various output devices? To have a font that uses CMYK values seems to imply a font very much tied to a particular output device. That's not necessarily an unacceptable thing, but something we need to be aware of when specifying font formats. |
|
I suspect most software that process images would convert the image-internal CMYK representation into an RGB-based reference colour space, at least for on-screen viewing. If output to a CMYK device, potentially the CMYK values could be passed through, but most likely some transform would be needed if the CMYK colourant values for the capture and output are different. The image should have an ICC profile that characterizes the capture colourant values; if not, some default CMYK values would need to be assumed. In ICC profiles, the colour space of a capture (or output) device is expressed in relation to a reference RGB colour space, which is the CIEXYZ colour space. If exact colour matching matters, then a CMYK specification isn't complete unless it is accompanied with an ICC profile (or equivalent) that provides a transform to a known reference colour space, or else it also specifies the particular device and inks that are assumed. I'm not sure I see any reason why colour fonts would need to support a CMYK representation of colours, Provided colours can be expressed in a known colour space with sufficiently wide gamut, any CMYK colour can be accurately as RGB values. If someone needs a colour font to have colours that match some specification expressed in CMYK, it would be a tool matter to transform that. |
|
@Lorp asked:
Just as with RGB, CMYK values without a specified ICC profile mean nothing. That's why the web, for example, pre-defines RGB (in that context) to really mean sRGB so that the numbers have meaning. Same thing would apply here, in that if you just have "raw" CMYK values, they are meaningless. But if you define them in some context (say SWOP or ISO Coated), then the process for conversion between spaces is well defined (as per ICC specs) |
|
@PeterConstable wrote:
Not necessarily RGB, but yes conversion to the current "output space" or "blending space" (in the case where transparency blending has to taken place) would be necessary.
As I pointed out in my earlier comment, I don't think the issue here should be specific to CMYK - but instead an allowance to use any valid colorspace as defined by CSS-Color-4 (https://www.w3.org/TR/css-color-4/). |
When you say, 'any valid colorspace as defined by CSS-Color-4', it's not clear what you mean. CSS-Color-4 defines the term "color space", but doesn't define "valid color space. It does talk about the colour space of tagged images, which is defined by an ICC profile attached to the image. It also talks about the colour space of untagged colours, which must be treated as being in the sRGB colour space "unless otherwise specified"; and it has a list of predefined color spaces that can be specified when using the Two separate issues that are often conflated when talking about colour spaces are the colour volume that can be described, and the representation of colours within the given volume. For example, the Or perhaps you mean All the above. I have no concern about supporting different representations for colours within colour fonts. In fact, I think if we want to integrate colours themselves with variations, then I think other representations besides RGB should be supported since hue angle might often be a preferable value for variation than combinations of R, G and B (and, in particular, variation using chroma-preserving LCH representation); and perhaps also variation of saturation or of chroma. But it's really not clear to me that it would be necessary or desirable to support ICC profiles within colour fonts so that arbitrary colour spaces can be used. And even if we talk about an enumerated list of predefined colour spaces, I'm not sure what the benefit would be of supporting multiple choices. If desired colours are in gamut either way, is a font developer really going to care whether colours are expressed in relation to Display-P3 or AdobeRGB? Do font tool developers want to add a lot of apparatus for supporting many colour spaces? My guess for these questions is that, if other things are equal, then No. As long as the colour volume is sufficiently large and the representation provides sufficient granularity, then a single colour space can be sufficient to represent any colours that the font designer wants. The ProPhoto colour space provides a large volume; ScRGB is even larger, though still not covering all human-perceivable colours; the ACES colour spaces are defined to cover all human-perceivable colours; and of course there's CIEXYZ. Wouldn't just one of those be sufficient? Granularity of numeric representation and use of imaginary colours as primaries might be two considerations. (A variation between two different imaginary colours might sound interesting but probably isn't really useful.) I'm not a colour science expert, so I'm sure there are considerations I'm overlooking. (I haven't mentioned issues like rendering intent, direction for hue variation, linear vs. non-linear scales, and dynamic luminance range.) But while CSS-Color-4 provides a lot of flexibility that might be desirable given a number of related specs that need to be supported and a wide variety of authoring environments or content sources. But fonts don't need to deal with a wide variety of authoring environments or content sources—e.g., we don't need to worry about fonts having embedded images that might come from a million different models of capture device and authors wanting to match specific colours within those images. |
|
Sorry @PeterConstable you are correct, bad choice of words. I did indeed mean that any colorspace (and its associated color values) that can be specified with CSS-Colors should be allowed in a colored font. Why?
non-colored fonts, that is certainly true - because in that case we only care about the outline. However, with colored fonts, they are bringing their own content (the color values and their associated colorspaces) that needs to be properly integrated into the authoring and output environments. For example, if the glyph contains information in sRGB that is being rendered into an ICCBased-CMYK environment (e.g., Photoshop) with an associated transparency blending operation specified, the rendering system needs to be able to properly convert all the colors to a single space in which to do the blending. |
|
You don't necessarily need to support lots of colour spaces. The real issue in the scenarios you mention is being able to support all the colours. If chosen appropriately, one colour space can do that. From a user perspective, I'm not sure what particular benefit there would be of supporting multiple colour spaces.
If a font is to be used only for printing to specific devices with specific inks, and the source graphics were designed referencing particular CMYK values for those specific devices and inks, then there might be usefulness in representing the colours in the font using those CMYK value if corresponding CIEXYZ values can't be derived. Keep in mind that all of those CMYK colours could be represented by equivalent CIEXYZ values. An ICC profile for the device/inks would provide the means to transform to CIEXYZ values, and it's likely a designer in that scenario will have an ICC profile for the device/inks, otherwise they would not be able to get a matching representation on screen when they are designing. How likely is it that there will be fonts designed for so constrained a usage scenario but without an ICC profile for the specific device/inks?
Sure. But it's not so much the colour spaces that need to be supported as it is the colours used in the content.
All that implies is that the formats for representing colours in a font may need to support a large range of luminance values. But that doesn't imply that multiple colour spaces need to be supported.
Now you're helping make my point: just as a rendering system can transform colours from disparate sources into a single colour space (and needs to do so for blending), so also inside a font colours originating from any number of different sources could be represented using a single colour space. |
|
@PeterConstable I appreciate your position here, but as you stated in a previous message, "I'm not a colour science expert, so I'm sure there are considerations I'm overlooking." On the other hand, I have been representing Adobe to the ICC for over 15 years now, and working with various industries and their color requirements for at least 10 years before that.
Unfortunately, it cannot for a number of reasons. First, there does not exist a single color space that can represent all other spaces - even more so now with HDR. If there was, everyone would be using it and we wouldn't need ICC or profiles or ... Second, in many color spaces (CMYK, being a good example), the color values actually represent a physical attribute (in the case of CMYK, it means ink percentages) which can therefore only be properly expressed in that manner.
From your perspective as a user, you mean. From the perspective of users who have specific requirements to achieve their specific use cases, job functions, industry mandates, etc. - there are LOTS of reasons! I am happy to introduce you to various users in various industries if that would be helpful.
Yes and no. Yes, you can certainly convert from CMYK->CIEXYZ and back. However, in almost all cases, the specific values are not maintained. This is why DeviceLink profiles exist (https://www.pdfa.org/why-devicelink-profiles-should-interest-you/).
Supporting ICCBased colors (aka those for which a profile exists) would be a HUGE improvement over what is in color fonts today!
It does imply that one needs to be able to specify the encoding of the values in relationship to light sources. Today, no such mechanism exists for colored fonts but CSS-Color would give us that. |
The point, I think, is not about a font being designed with bare CMYK colours. As part of print workflow, it seems realistic that an application, OS, or print driver might want to embed device-specific CMYK values in a colour font’s CPAL table dynamically, to replace whatever (RGB etc.) colours were set by the font maker, or to represent faithfully a palette specified by a user. |
That scenario doesn't imply any requirements on the font format. At most, the spec would need to make clear that colours can be overridden by apps at presentation time, |
Wonderful! You probably know a different Peter Constable that used to work at Adobe, then.
I'm in that position of knowing about enough to get myself into trouble. But I'm willing to learn.
But don't all colour spaces get defined in relation to the CIEXYZ space? Don't all ICC profiles use that as a reference? Reading from color.org:
Unless I'm misunderstanding (in which case please help me understand), if fonts can carry ICC profiles to characterize their colour space (the most flexible option in CSS-Color-4), they would characterize the colour space in reference to CIE 1931, implying CIEXYZ or (equivalent CIE-defined space).
But as you mentioned above,
Generalizing, if colours are specified in relation to some colour space Foo, those colour values mean nothing without a specified ICC profile or other comparable specification that allows transformation to a known reference colour space. No?
Ah, this part is new to me. Let me make sure I understand:
Is that accurate? I assume this issue is specific to imaging using subtractive colour mechanisms like inks or other pigments?
I gather by "in relationship to light sources" you mean that colour values are scene-referred? (Of course, an sRGB image can, in principle, have values that are scene-referred levels, though in practice images have been presented using a display-relative interpretation of levels.) It's true that fonts using the COLR, CBDT or SVG tables are limited to sRGB, which means that, per the sRGB spec, the max luminance supported is 80 nits. Supporting all of CSS-Color-4 could certainly eliminate that limitation. But wouldn't that also be possible if just CIEXYZ were supported? (Some data type would need to be used, and ultimately that will impose some upper limit on luminance. But even 10,000 nits as supported in BT.2020 is more than most current imaging systems can display. Of course, for print, HDR is not really relevant.) How luminance levels work in CIEXYZ or LAB* is still not completely clear to me. IIUC, Lab* uses the relative concept of "diffuse white" for maximum lightness, so that seems not so useful in relation to HDR. But IIUC CIE XYZ doesn't have that limitation. In discussion of a different issue, Chris Lilley indicated that the luminance component of XYZ, as defined by CIE, is an absolute, physical value, though he also mentioned the common practice of normalizing XYZ such that "media white is given as 100". But if CIEXYZ were used and it was either stipulated or else a way was provided for the font developer to indicate that luminance levels are absolute / scene referred values, wouldn't that suffice to support HDR? |
As you quoted, in ICC v4 (which is what we are talking about when we talk about ICC profiles), the PCS (profile connection space) is almost always LAB/CIEXYZ with a light source of D50. You can specify others but it is unusual. But the PCS is NOT the colorspace of the data or some magic "everything fits in here" space...it was just the best way, at the time, to provide a "consistent and predictable" middle ground for color conversion. But it's not lossless!
Correct. You need a profile associated with the values for them to mean something. However, that doesn't necessary mean that the output device is actually using the profile. In the case of a physical printer, for example, if the printer is calibrated to CMYK.foo and it receives data that is "tagged" with the CMYK.foo profile then it knows that it can use those values "raw".
Correct.
Yes, that is correct. CMYK.foo->PCS->CMYK.bar is lossy, mostly in the area of solid colorants. So if you had some text in CMYK black (which is always [0 0 0 1]) and did that transform, you would not get back the same values. Some CMY would end up "bleeding into" the color values which now means that when printed it will end up using other inks and (in a classic separated printing environment) putting that output on separate plates. You can see this in places like the Apple ColorSync Calculator.
This is why many color conversion utilities, such as the one in Adobe Acrobat, provide extra controls to preserve those values.
Corect, RGB doesn't have this problem.
Which is part of the ongoing discussions around "Color on the Web" since there are cases where different scenarios need these different options. They also need to be able to specify Rec2020 vs. P3...
Again, I wish - it would make things so much easier. But the folks who did HDR were "doing their own things" and weren't necessarily concerned with ICC compatibility or CIEXYZ. |
I can't speak to everyone involved in "doing" HDR. While working on HDR display in Windows, and interacting with people involved in VESA Display HDR specs, it was my understanding that that was being done in a manner compatible with CIEXYZ. And in the Windows display pipeline, I recall there were certain points at which image data was spec'd to get transformed to CIEXYZ (or maybe xyY, but I think it was XYZ). My main concern with all of this is that color is complicated for even tech-savvy people to understand, and so I'm concerned about adding that complexity as a burden for font tool developers, application developers, font designers, and font users. Today, the OT spec states that colours in CPAL/COLR, CBDT or SVG tables are sRGB. On the one hand, that is limiting, but on the other hand it's very freeing for most. E.g., developers don't need to do anything special for colour handling since everything they interact with assumes sRGB by default (and nobody is worrying about whether luminance and viewing conditions are exactly as in the sRGB spec). If CPAL were enhanced to support a different, larger colour space (whether XYZ or ScRGB, etc.), then font tool and app developers will have additional work, but it will be limited: they need to call APIs that support that space (on Windows, ScRGB at least is supported---it's what's used internally for desktop compositing) or do a single transform. But if CPAL were extended to support many colour spaces and ICC profiles, the developer (especially the font tool developer) now has a lot more they need to understand and implement. I certainly think we should do what's right. But we should think carefully about how to determine "right". |
Understood and I do agree that it is a complexity. But its one that already faces designers/developers as the web evolves to support HDR and other colors, joining the OS platforms and technology like PDF.
That is only true for the web (today). For all the non-web uses of fonts, sRGB is not assumed or defaulted. Granted, applications (such as Photoshop or InDesign) can handle conversion of that sRGB to CMYK (or whatever) either during authoring or PDF conversion - but that assumes that a user knows what they are doing to set them correctly. So we make things easier for font developers but more complex for font users such as content designers. Also, as the web moves to more colorspaces and HDR, that same "pain" will find itself on their plates as they try to match colors between the text on their pages and the images or videos alongside them. However, I also don't want to see different versions of a font in different colorspaces - that is only going to confuse matters for all involved!
Agree 100% |
|
Just my two cents from me. Whenever I send a PDF to a printer, I convert all colors (mostly in images) to CMJK using the profile that matches the paper and printing conditions. But then do NOT include profile in the pdf. Because otherwise the colors would be converted back and forth and I don’t want that. So just adding the CMJK values is all I would need. We don’t need to overcomplicate thing. And if someone needs a profile, it can be applied to the document like with images. And I suspect that those fonts will be used in very specific environments so the CMJK values can be set for that purpose. |
|
@schriftgestalt that's an oversimplification. There are pdf's with specific colorants, like a semi-transparent golden color company logo, which requires special inks (a special metallic gold paint on a special printer), for example. So there is the complete but very complicated solution, which is specifying both the colour values and what those value means (ie a "source" colour profile), a declaration of what your colour-mapping preferences are if exact match is not possible (ie a "link" profile - metallic gold is not printable on most common printers, what to do?), and a declaration of what colors the printer is capable of (ie a "device" profile). If you want the simple solution, you need to have at least an implicit assumption/restriction to what that source colour values are. Like source colours are restricted to RGB, and unless otherwise stated, in the sRGB color space, for example. Yes, there are pdf's with "named (special) colorants". And different printers have different ink formulations - the cyan on one brand/model might be darker than than cyan on another brand/model, for example, so to get "visually similar" results, you might have more black and less cyab on one . (This is the device profile side, of the chains of 3 profiles I wrote above). |
|
I'd like to add that most document formats are in a way dumb so that they can assign one color to some object at any given time. So the color info needs to be converted. But a font is not a document, but instead a TOOL to produce documents. The COLR table maps to entries in the CPAL table, but it's the CPAL table that holds multiple sets of "color environments" (palettes). The typesetting process makes the app responsible to actually pick the right color environment and apply the colors to the objects. Right now, we have some solutions that specify a "default" color environment and a "dark" color environment. I can generally see that the CPAL table could be extended to provide some additional data for more specific environments — CMYK with a particular named profile, and ink vendor like Pantone and others. If the app does not find a dedicated color palette for the environment the app is imaging to, it should fall back to something (which would typically be the sRGB default palette), and perform conversion. Just like today an app that displays content in "dark mode" tries palette 1 and if that's missing defaults to palette 0. I'm not trying to propose a solution, but suggesting a way of thinking. |
|
You can always find a more complex use case for everything. But "just" having plain CMJK color in a font would be super useful for a lot people. Every second time a designer asks me about color fonts, they ask about just that. Last happened last week. And I know all about those problems with different ink colors and so do most designers that do print. The use case it to be able to define the same colors in the font as are defined in the rest of the document regardless of what profile is applied to the document or what inks are used. |
But how can the font developer anticipate what CMYK colours will be used in a document? (Unless we're talking about a corporate font with specific branding colours, I'm not sure how this is expected to work.) |
|
There is some misinformation & confusion going on in the recent comments, so let me see if I can clear things up. Let's start by agreeing that there both device independent and device dependent colors - sRGB is device independent, as it means the exact same thing on all devices (because it is backed by a specific profile or definition) vs. "regular" RGB where the same values will produce different results on different devices. Same is true with CMYK (and even Gray color values), where you have things like SWOP (US) and FOGRA (EU) standards for CMYK values. This goes to @schriftgestalt 's comments, where the document that he(?) sends to the printer has been converted from device independent colors to those specific to the output device of his printer. (FWIW: you aren't following the recommendations of the German professional printing industry which recommends the use of device independent colors via the PDF/X series of standards) CSS Color Level 4 has a whole section on device independent colors - https://www.w3.org/TR/css-color-4/#lab-colors What @HinTak is referring to are known generally as Spot colors, which is basically the print-centric version of a "named color" (ala https://www.w3.org/TR/css-color-4/#named-colors), except that in the print world the name maps to a physical ink that will be placed on substrate instead of a predefined (s)RGB value as it does in CSS. Such Spot colors can also have "alternative values" in other colorspaces such as CMYK or Lab. But trying to bring that into COLRv2 would be extremely complex. |
The underlying issue here, isn't specific to CMYK, that's just a specific case. The problem with color fonts, in general, is the font author specified one set of colors for the glyph(s) BUT the content author wishes to apply a different set of colors (so that it matches the rest of the surrounding content). When this problem exists for images - there is a well defined method to "color convert" the image's colors/colorspace to that of the surrounding content. For fonts, however, such a scenario doesn't exist. @twardoch mentions the use of CPALs, which would be useful when a given font is authored to use a CPAL instead of fixed values provided that there is a way to feed a custom palette to the font renderer. I expect this issue to come up with the new HDR capabilities being introduced through the open web platform in CSS, HTML, Canvas, etc. |
In OpenType, the vector color formats (COLR, SVG) use the CPAL table to define one or more palettes. But nothing prevents an application from exposing the palette entries from a CPAL palette for content authors to customize. This is just what @font-palette-values in CSS Fonts Module Level 4 does, and is supported in Chromium- and Webkit-based browsers. |
|
@PeterCon Thanks for that reference. Seems then that the missing piece is that the values of a CPAL (and by extension, the So then the real change would be to figure out how to evolve CPAL to support any value permitted by CSS Color. |
I totally agree that this is how it should be done but I still have to find a printer that follows that or at least produces decent results if you do. Every single printer I worked with and all colleges that I spoke to will do it the way I described it above. For most general purpose color fonts, device independent will be just right. But, as I said, there are occasions that you like to say: Print this in 100% yellow + 33% red ink and nothing else. Doing so with device independent colors in not possible. So it is not about perfectly correct colors. Just doing the same thing as elsewhere in the print. CMJK colors are device dependent, always have been. If you add a profile to them doesn’t make much sense to me (the color space is much smaller than most RGB spaces). If you like a device independent color, use RGB+color profile. So we have two separate problems:
|
It remains a massive pain point for users that their color fonts can not provide specific CMYK colors that their brand book requires.
The text was updated successfully, but these errors were encountered: