Color Management Confusion: Swatch Definition & Color Spaces

[Mark Oehlschlager]

@Sean P

There are a number of questions and concerns I have with regard to the Color and Swatch Panel UI designs that I would like to call to your attention:

First, a question: how are we to understand the HSL color model? Is the HSL color model an alternative to the CIE Lab color model for describing the entire gamut of color visible to the human eye? If not, how are we to understand the size and limit of the HSL color gamut? How does it compare to CMYK, or sRGB?

Second, I have a concern about being able to define a color/swatch that falls outside of the color gamut of the document's color space without warning. We understand that the size of color gamuts for some working color spaces are smaller than others, and that a color that is visible in one color space (e.g. sRGB) may fall outside the color gamut of another color space (e.g., CMYK). Given that the Affinity UI allows the designer the option of defining a color/swatch using sliders and wheels of various color models (i.e., RGB, CMYK, HSL, LAB), there is the risk of a designer specifying a color using RGB slider values that falls outside the color gamut of a document's CMYK color gamut without any warning from the software UI. It would be very helpful for the UI in all the various color editing and definition panels to flag color definitions that fall outside of the document's color gamut.

Third, I have another concern related to the slider options made available to the designer when editing a color/swatch: simply toggling between color model options in the color edit panel will alter original color parameter values. For example, if I define a new orange swatch using HSL values H: 30 S: 100 L: 50, then double click the swatch to edit it, I get a contextual edit dialogue box with HSL sliders. If I toggle the color model pop-up from HSL to CMYK and then back to HSL, I find that the HSL values have changed to H: 27 S: 91 L: 54. Why should this happen? Is this the result of the software mapping an out-of-gamut HSL color to the nearest CMYK color and then translating that color back to the HSL color space?

Fourth, another question: as documents may be repurposed from screen to print, and vice-versa, and as swatch collections may be saved, shared and reimported across many documents in a project, would it be helpful to somehow graphically identify swatches as having been defined in a particular color space, or would it  be best for the software to keep track of the device-independent Lab color space definition, regardless of what color space the designer defined the color/swatch in?

I'm sure there are many other questions to be addressed here, but the general concern is that the Affinity UI should be improved to make it easier for the designer to accurately specify and manage color with confidence and to be warned when a color is outside the color gamut of the current working document. 

 

[fde101]

1 hour ago, Mark Oehlschlager said:

how are we to understand the HSL color model?

https://en.wikipedia.org/wiki/HSL_and_HSV

 

1 hour ago, Mark Oehlschlager said:

Given that the Affinity UI allows the designer the option of defining a color/swatch using sliders and wheels of various color models (i.e., RGB, CMYK, HSL, LAB), there is the risk of a designer specifying a color using RGB slider values that falls outside the color gamut of a document's CMYK color gamut without any warning from the software UI.

True... and that is very likely to happen any time photos are imported into a CMYK document as well.

 

1 hour ago, Mark Oehlschlager said:

flag color definitions that fall outside of the document's color gamut

That is probably a good idea...  though it might actually be a better fit for Publisher by being added to the Preflight panel.

 

1 hour ago, Mark Oehlschlager said:

Is this the result of the software mapping an out-of-gamut HSL color to the nearest CMYK color

Possibly, though HSL colors are not always 100% unique - it could also be that two different sets of numbers mapped to the same underlying RGB color value (as explained at the link above, HSL is built on RGB).

 

1 hour ago, Mark Oehlschlager said:

would it  be best for the software to keep track of the device-independent Lab color space definition

I believe that is basically how QuarkXPress works?

 

1 hour ago, Mark Oehlschlager said:

the Affinity UI should be improved to make it easier for the designer to accurately specify and manage color with confidence

That is always a worthy goal, but note also that there was recently another thread where people were basically requesting the opposite.  They wanted the CMYK values of swatches to remain unchanged when pasting something into a document with a different color space - they were more concerned about the numbers than the actual color for some reason related to corporate standards of clients or some such.  I can see that with the K value (for blacks) if there is a desire to conserve more expensive color ink when writing out body text, and while I personally still think it would typically be better to educate those clients, there are obviously multiple factors to be considered.

[Mark Oehlschlager]

@fde101

Hmmmm. Okay, so HSL is an alternative model used to describe color within the RGB cube model. 

And the size of the color gamut described by HSL values is determined by the specific RGB color space it's operating in. And the appearance of an HSL color will change depending upon the RGB space it's operating in. (i.e., The color values H: 30 S: 100 L: 50 will appear one way in an sRGB colorspace, and appear differently in an Adobe 1998 RGB color space.) Right?

So, HSL is not device-independent like CIE Lab.

[Jowday]

4 hours ago, Mark Oehlschlager said:

@fde101

Hmmmm. Okay, so HSL is an alternative model used to describe color within the RGB cube model. 

And the size of the color gamut described by HSL values is determined by the specific RGB color space it's operating in. And the appearance of an HSL color will change depending upon the RGB space it's operating in. (i.e., The color values H: 30 S: 100 L: 50 will appear one way in an sRGB colorspace, and appear differently in an Adobe 1998 RGB color space.) Right?

So, HSL is not device-independent like CIE Lab.

https://en.wikipedia.org/wiki/List_of_color_spaces_and_their_uses

[Mark Oehlschlager]

@Jowday

Thanks. It appears that use of HSL color components is generally associated with the sRGB color space, but can be used as a schema to describe color in other RGB color spaces. Correct?

In any case, if the Affinity software is going to allow users to use sliders from various color models (sRGB, CMYK, Lab) to define colors/swatches in documents with a specific operating color space, it seems to me that it would be useful for the UI to provide visual feedback if/when the user defines a color that lies outside the color gamut of the document's color space. Additionally, it would be useful, in the case of working with documents whose color space gamut exceeds the that of the computer display, to offer a way to highlight document colors that would be clipped by the display's relatively small color gamut.

In terms of preserving the integrity of the appearance of color on screen when working with art in different documents of different color spaces (i.e., sRGB, SWOP North America CMYK, etc.) I'm not sure what the Affinity software is designed to do. Perhaps, for each color/swatch that the user defines, regardless of what color model sliders the user employs, the software keeps track of the CIE Lab values in addition to the relative RGB and CMYK values? So, if one document is imported into another with a different color space, and "Convert" is the color management policy, the CIE Lab values are used to preserve color appearance and the RGB and CMKY values are allowed to be translated for the new color space. Whereas, if "Assign" is the color management policy, the RGB and CMYK values are preserved in the new space and the CIE Lab values are translated to describe the altered appearance. Maybe?

I just wish the Affinity UI made it easier to spec color for specific color spaces with confidence.

[fde101]

3 hours ago, Mark Oehlschlager said:

a way to highlight document colors that would be clipped by the display's relatively small color gamut

This makes the assumption that the software has accurate data related to the capabilities of the display, which may not always be the case.  It would probably only be relevant when the display is calibrated by a device that encodes the display's capabilities in some format that is accessible to the application.

Things could be further complicated in situations where the display is mirrored onto multiple monitors and they have differing profiles (such as using Sidecar between an iPad and a Mac).  Covering all of these cases may make this more complicated than it is worth as many users struggle as it is to understand the color management options which are already available in the application and this could lead to far greater confusion...

The idea is good in principle, but I'm not quite sure we are there yet with the underlying support from the technology that would make it reasonable to consider providing this within an application.

[Jowday]

6 hours ago, Mark Oehlschlager said:

@Jowday

Thanks. It appears that use of HSL color components is generally associated with the sRGB color space, but can be used as a schema to describe color in other RGB color spaces. Correct?

I believe that is correct.

https://en.wikipedia.org/wiki/CIELAB_color_space :

Quote

"The LCh (CIELAB) color space is not the same as the HSV, HSL or HSB color models, although their values can also be interpreted as a base color, saturation and lightness of a color. The HSL values are a polar coordinate transformation of what is technically defined RGB cube color space. LCh is still perceptually uniform."

This is also a great visual presentation:

 

 

[Matthias]

15 hours ago, fde101 said:

 

15 hours ago, fde101 said:

16 hours ago, Mark Oehlschlager said:

the Affinity UI should be improved to make it easier for the designer to accurately specify and manage color with confidence

… note also that there was recently another thread where people were basically requesting the opposite. They wanted the CMYK values of swatches to remain unchanged when pasting something into a document with a different color space - they were more concerned about the numbers than the actual color for some reason related to corporate standards of clients or some such.

Hi fde101,

I am one of those people you mention in this quote. The way I read Mark Oehlschlagers request me and him are sort of on the same page: I too would want it “easier for the designer to accurately specify and manage color with confidence” — which is why I think that CMYK values I myself have dialed in should stay true to my decision — for several reasons I have outlined.

I am not sure what Mark’s wish is but I’d suppose it’s not the opposite of mine.

[Mark Oehlschlager]

@Matthias

I think the whole objective of color management for the designer is to preserve the fidelity of color appearance. That is to say that if a designer selects a particular orange for his artwork in one medium (ink, paint, computer monitor), he can expect the appearance of that orange to remain constant even as the artwork is translated from one medium to the next, or from one color space to the next.

It's incumbent on the designer to understand that the color gamuts of the various color spaces (e.g., Adobe RGB 1998, sRGB, U.S. Web Coated SWOP CMYK) are of different sizes and do not perfectly overlap, and to understand the difference between the relative values of RGB and CMYK numbers for describing color in specific RGB and CMYK color spaces (an orange that is described by the relative values R: 255 G: 128 B: 0 in the sRGB color space will appear differently in the much larger Adobe RGB 1998 color space), and the more fixed, absolute and universal values of CIE Lab, which describe the full spectrum of color that the human eye can perceive – independent of device or medium. 

Equally, our software tools should make it easier to understand the target color space in which we are working (for any particular document) and easier to pick and specify color with the confidence of knowing that the appearance of the color we've selected is right for our target color space and will be preserved on output.

That's the design challenge for the software designers and engineers.

[Matthias]

Well, Mark, then we do have a different approach here. We both want to put the designer in charge — but from opposite directions. I concede your points.

What would help though is if the app would somehow memorize the originally dialed in colour values. So when the colour space would change back from a different one to the original one the colour values would jump back to what exactly one intended them to be.

[fiëé]

A technical solution would be if we could assign color spaces to swatches, i.e.: Do I want a device independent (profiled) color or a device dependent (unprofiled, CMYK or RGB “numbers“) color?

In my latest project I wanted a lot of elements to be 100% cyan, regardless of output intent or other profile. I’m still hoping that it did work, keeping everything in ISO Coated profile. If the printshop would convert to a different CMYK profile (like SWOP or ISO Uncoated), they would convert my Cyan to some CMYK value, so that everything gets rasterized.

On the other hand, I’d like to keep the “look” of RGB graphics. *And* I’d like to be able to convert RGB black to 100% K.

The current state of greyscale pictures (even from AP) is that they are always handled as DeviceGray, i.e. device dependent color space, and get rasterized in CMYK instead of just K!
(At least that is what Acrobat’s separation preview shows; I hope the printshop will do better.)