Color Profiles in .afpalette files exported from AD2

[LionelD]

Two questions, probably for Serif, please.

Do .afpalette files created in and exported from AD2 include the Color Profile from the source document?

If not, how are .afpalette files treated on import, especially when the new host document has a color profile that differs from the one used when the palette was created?

Thanks

[walt.farrell]

There are several types of palettes in Affinity, @LionelD:

• System (if you're on macOS)
• Application
• Document

Of those, only Document palettes have any relation to a specific document, so I don't think the color profile of a document would be relevant for the other two, at least not at the level of the palette itself. 

But you raise an interesting question that I have not considered before. If I have an Application palette, and I add a color to it from a document that is using sRGB, and separately add a color from a document using AdobeRGB or even from a document using CMYK, I'm not sure what information Affinity saves with the swatch and whether that would affect assignment of that color to a different document.

This leads me to think that perhaps each individual swatch of a palette has (or should have) information about the color palette it came from, as well as the color values, so that a proper conversion can be done when the swatch is used later. But I don't know for sure how that is handled, and I will be interested in learning that if someone else knows. (So far, from only a simple experiment, I haven't figured it out).

[LionelD]

@walt.farrell Thanks for the response.

Assuming color palettes are color managed (as they obviously should be), I assume they must have color profile embedded.  I would hope, for the sake of simplicity, that the entire palette has a single color profile.

Regards

[walt.farrell]

18 minutes ago, LionelD said:

I would hope, for the sake of simplicity, that the entire palette has a single color profile.

I suppose there are at least three choices the developers might have made:

1. Each palette uses a standard color profile (e.g., sRGB or AdobeRGB for RGB), and then whenever a swatch is saved or applied a conversion happens from/to the document or object color space. Or
2. Each palette uses the color profile of the active document when it was created, and then a conversion takes place whenever a swatch is saved or applied. Or
3. Each swatch within a palette has a color profile, and conversions happen when saving or applying.

Options 1 or 2 might be viewed as "simpler" than option 3, but given that a conversion is potentially required for each save or apply operation the code is probably not much simpler, though the space required to save a palette will be smaller if only one set of color profile information is needed.

[LionelD]

It looks a bit as though something is fishy.  LAB space uses values with decimal fractions, and you can enter them but the fractional part disappears in AD2.  I’m going to compare Apple ColorSynch utility with AD2…

Regards

[Ldina]

5 hours ago, LionelD said:

Assuming color palettes are color managed (as they obviously should be), I assume they must have color profile embedded.  I would hope, for the sake of simplicity, that the entire palette has a single color profile.

I don't think so, but I'm not absolutely sure. I just did a very simple test.

1. Created two RGB documents...one with DCI-P3 profile, one sRGB profile
2. Opened the "Colours" Palette in Swatches, supplied by Affinity. Running my cursor over the colors, they are defined in HSL terms.
3. Selected the same color swatch (85H, 70S, 50L) and applied it to a rectangle in each document. 
4. The colors in the two documents are clearly different. 

HSL and Hex Codes are just different ways to encode an RGB color. As with regular RGB (using RGB sliders), the actual color is dependent on the Numbers AND the color space. The HSL definition is the same in both documents (i.e., 85H, 70S, 50L). The P3 document has a LAB value of 76L, -61a, 90b, which is very saturated. The sRGB document has a LAB value of 80L, -42a, 71b, which is lighter, but a lot less saturated. 

So, based on this test, my preliminary conclusion is that the palette is just a list of RGB values without any color profile. They just happen to be encoded in HSL terms instead of RGB terms. 

A color palette encoded as LAB values should show the same color in any color space (as long as the gamut of the color space is big enough to contain the color). 

 

[LionelD]

@Ldina Thanks for your response.  I will have to think about some of this, but if palettes don’t include/specify a color profile, how are they interpreted at the time you import one into AD2?  Wouldn’t that disrupts color management efforts?

Can a LAB encoded palette really appear the same regardless of the profile in effect in a host document?  The other color spaces are smaller that LAB, so some LAB values are not going to have an exact counterpart.

Regards

[Ldina]

9 minutes ago, LionelD said:

I will have to think about some of this, but if palettes don’t include/specify a color profile, how are they interpreted at the time you import one into AD2?  Wouldn’t that disrupts color management efforts?

My guess is that all the RGB, HSL and Hex Code color values and swatches assume the use of sRGB. Just a guess. 

9 minutes ago, LionelD said:

Can a LAB encoded palette really appear the same regardless of the profile in effect in a host document?  The other color spaces are smaller that LAB, so some LAB values are not going to have an exact counterpart.

Yes, I tried it. LAB is device independent, so you can define a LAB color in sRGB, P3, Adobe RGB, ProPhoto, etc, and it will display the same (as long as the gamut of the color space is large enough to contain that color). Works with CMYK as well. I ran that test this morning. And you are correct that some color spaces will not be able to display some LAB colors because the color space is too small. 

 

[LionelD]

@Ldina Thanks, that’s was useful.  I’m still concerned about color managing palettes; almost all my documents use a Document Palette, and I have some palettes that I re-use widely.  Hasn’t been a problem thus far, but every doc I create goes into ProPhoto by default, so that probably helps.

Regards

[Ldina]

6 hours ago, LionelD said:

Hasn’t been a problem thus far, but every doc I create goes into ProPhoto by default, so that probably helps.

If you always use ProPhoto, and your palettes were defined and saved using ProPhoto, you should always be okay. Just use ProPhoto. If you need to, you can always Convert (Document > Convert ICC) to a smaller gamut color space, or convert on export, which will preserve the color 'appearance' (as long as the colors fit into the smaller space). 

[Ldina]

@LionelD You can test LAB color with different document profiles as follows.

• Create a New Document using a medium-large sized color space (such as Adobe RGB or P3)
• Define a LAB color with LAB sliders and fill a rectangle with a LAB color (I used 50L 50a 50b.)
• Assign sRGB to the file. Color appearance remains the same, as do the LAB numbers.
• Assign ROMM RGB (same as ProPhoto RGB). Color Appearance remains the same, as do LAB numbers. 

The LAB values will stay constant in all three color spaces, i.e., 50L 50a 50b. The RGB, HSL and RGB Hex numbers will change with the color space to preserve the same appearance. I purposely picked a color that would be in-gamut in all three color spaces to show that LAB values do not change when converting (or assigning) if the color is defined as LAB. If the above color was in gamut for P3, but out of gamut for sRGB, the appearance would have changed as the color management engine remapped the LAB color into sRGB.

[LionelD]

@Ldina I experimented with Apple ColorSynch Utility (MacBook only, Utilities folder) and came to realize that rendering intent makes things a bit more complicated. See the discussion at https://www.cambridgeincolour.com/tutorials/color-space-conversion.htm.  In general, color space conversions are not reversible.😳

@lacerto stirred things up too by providing a link to information about the file formats used for various palettes (.ASE etc) and as far as I can tell none indicate an embedded profile. See https://www.selapa.net/swatches/colors/fileformats.php

Not to be outdone, @NotMyFault reported alerting Affinity some time ago to the fact that the way they handle the CIE LAB space is very unconventional (and wrong).  Thread here 

 

And then I remembered that the Color Panel in AD happily lets you switch from RGB to LAB to CMYK etc (not sure if these are naked color models with no profile) without explicit reference to Rendering Intent.  Perhaps these are just ways of choosing the color you need, but that still begs the question of what happens when the color you choose is out of gamut for the color space you’re using.  I’m way out of my depth here…

It all looks a bit like the Wild West to me, but your observation and recommendation to stick to one color space/profile seems the best approach for now.  Not sure what I’m going to do next time I need a Pantone color.

Thanks everyone, now we can all go dream in the color space of your choice..

Regards

[Ldina]

@LionelD Color is complicated and our best color models are not perfect. You usually can convert from LAB to an RGB colorspace and back again, and get the same color, but numbers may be slightly different due to rounding. This assumes that the LAB color you are converting to RGB is "in-gamut" for the RGB colorspace you are converting to. Most of these conversions use Colorimetric rendering intent (in fact, most RGB profiles, e.g., sRGB, Adobe RGB, etc, are matrix based don't even support Perceptual Intent, since they don't have tables in the profile for that purpose). So, when converting, any "out of gamut" colors are simple clipped to the closest possible color at the border of the destination colorspace. 

If you convert a LAB or RGB color to a smaller colorspace that isn't large enough to define that color, the color will definitely change so it fits into the target colorspace. In that case, converting back again (i.e., a round trip), will result in a different color from the original. CMYK adds an additional wrinkle, since it has four color components, C,M,Y and K, instead of three. Many CMYK colors can be defined in a multitude of ways. Like I said, color is complicated. 

All the swatch palettes I've seen for Affinity (and I think most other software) are defined as hex, RGB, HSL, Grayscale, CMYK or LAB. None of them that I have seen are based on a profile. So, when you apply a swatch defined as 200R 50G 75B to a document, the 'precise' color will be determined by the numbers AND the color space. The only definitions that are not colorspace dependent are LAB defined swatches (which almost universally are based on D50 in most graphics software). So, LAB swatches should look the same, whether you load the swatch into an sRGB, Adobe RGB, DCI-P3, ROMM RGB, or US Web Coated SWOP document. That, of course, always assumes the document color space is large enough to contain that color. 

RGB, HSL, HEX and CMYK color numbers ALWAYS require a profile to nail down the color. LAB does not. That is why LAB (or a LAB variant) is used as a profile connection space (or master translator). That LAB PCS (profile connection space) AND the Color Management Module that handles all this color stuff are the basis of display and conversion between profiles. LAB has 3 components, as do hex, HSL and RGB, so conversions are usually quite good. CMYK has four components, so converting from CMYK back to a color space that has only three, can be more inaccurate. 

Anyway, if you have a LAB value in Affinity, you can convert it to RGB, HEX, HSL or CMYK, and the color conversion will be pretty darn accurate, but those color numbers will ONLY be accurate for that document color space. Remember, all color spaces except LAB or LAB Variants (i.e., device independent color spaces) MUST have a profile to make sense of the numbers. 

Individual colors will always be converted using Colorimetric Intent. If the LAB color you are converting to RGB is out of gamut for the target colorspace, it will simply be clipped to fit into the closest possible reproducible color. (That is determined by the profiles and the algorithms in the Color Management Module...and different CMM modules can yield slightly different results...ain't it fun?). 

Rendering intents are usually used when exporting or printing. The CMM module will look at the source and destination profiles, and also the colors in your file. If any colors in your source file will not fit into the destination color space, the rendering intent will determine HOW those colors are remapped to fit. Colorimetric simply lops off any "out of gamut" colors and brings them into gamut. This can result in lost detail and colors getting squashed together (think of a bright red rose, where those brightest colors lose differentiation and end up being a bright red color blob without detail. The "in gamut colors" will retain their look and saturation, but the 'out of gamut' colors will be a bit problematic.

Perceptual Intent is a different approach and scales ALL COLORS to fit into the destination color space. This retains differentiation between colors and tones, but you will typically see a shift in color, brightness, saturation and contrast. It generally 'looks good perceptually', but shifts are inevitable. That red rose won't be a blob of detail-less color anymore, but the rest of the image will have some color shift and loss.

Which rendering intent looks best is very image dependent. That's where soft-proofing comes into play. You can try both Relative and Perceptual Intents and see which looks best with your current image. Once you settle on the best rendering intent, you can then "tweak" the image to look it's best (while the soft proof is active). When exporting or printing, you need to turn that soft proof OFF...it's just for estimating what the image will look like in the destination color space (i.e., export, or printer) . It's all a matter of compromises. Printed media is always limited in dynamic range and color gamut, so it needs to be done one way or another. We just try to get the best we can from the printer/paper/ink combination available to us. Color is complicated...we haven't even touched the surface!

Back to your original statement...if you mostly work in ProPhoto RGB, then stick with it. Your color swatch definitions will always come in the same if you always use the same color space. The only problem with ProPhoto is that no monitor on earth can display a lot of colors that ProPhoto can define and contain. That's why Adobe RGB and P3 are popular working spaces...they're moderately large, and most good, modern monitors cover 99% of these color spaces. If you use ProPhoto, you can always CONVERT to a smaller color space, and as long as your colors fit into that smaller color space, they will remain accurate. Damn, that was long-winded. Hope I didn't totally confuse you. 😵‍💫

[NotMyFault]

What many users not realize is color channel bit depth often spoils the game when using wide gamut color profiles. I recommend to not use ROMMRGB unless at least 16 bit color channel depth. 
 

If you have a gradient over lightness and a almost constant hue, you earn noticeably banding. The more pronounced the wider the gamut. 
 

Affinity covers this in gradient tool by forced dithering - which I don’t like either as it kicks in even in 16 and 32 bit. 
It will be bad natural gradients in photographs like blue sky, solid color areas with minor graduation over lightness