What is the source of truth for a color's RGB values?

[PitterPen]

Would you expect to see the same R, G, and B numbers, for the same color, in the Color window and the Info window?  The image below might better clarify.

What I did was create a green rectangle using a swatch with color 2B675A.  Then, in the Info window, I used the cross hairs to lock onto a pixel in the green rectangle.  The R, G, and B values are:

R: 41

G: 103

B: 89

If I then click on the green rectangle and look in Color RGB, the numbers are DIFFERENT for R and B:

R: 43

G: 103

B: 90

Am I misunderstanding something or doing something wrong?  I'm trying to match colors, and thus far I'm confused as to what is the source of truth for a color's RGB values.

Thanks

 

[Pšenda]

ICC profile for monitor in OS is OK?
Color picker says what value?

[David in Яuislip]

I can't reproduce this in V1
Two location samples, two cursor samples and the colour chooser, everything agrees

[walt.farrell]

43 minutes ago, David in Яuislip said:

I can't reproduce this in V1

I can't reproduce it in V2, either.

@PitterPen: Can you share the document with us?

 

[PitterPen]

On 3/23/2023 at 2:17 PM, walt.farrell said:

I can't reproduce it in V2, either.

@PitterPen: Can you share the document with us?

 

Sure, I've attached a png export and the .afphoto file.  This site said .afphoto attachments are not supported, but it looks like it attached it to the post anyway.  Let me know if it didn't attach. 

 

In the file, I deleted everything but the green rectangle and I still see the discrepancy:

 

 

 

Source of RGB truth.afphoto

[R C-R]

21 minutes ago, PitterPen said:

In the file, I deleted everything but the green rectangle and I still see the discrepancy:

I see it too, but if I change any of the 3 values in the Color panel & then change it back to the original value, then the Info panel updates to show values matching those of the Color panel.

Also, if I draw a new rectangle using the values from the Color panel, the Info panel values agree with those of the Color panel.

I'm not sure what to make of that but it seems like there is something a bit weird about the original rectangle's color.

[lepr]

13 hours ago, PitterPen said:

Sure, I've attached a png export and the .afphoto file.

Your RGB document has profile sRGB 2.1 and latent CMYK profile SWOP v2.

The vector rectangle in the RGB Affinity document has colour specification CMYK(211, 102, 167, 62).

When the Colour panel is set to RGB, it reports a conversion from the CMYK to RGB(43, 103, 90).

The CMYK colour is rendered as RGB(41, 103, 89), and that is the colour reported in Info panel and in the PNG export.

Affinity appears to do different colour conversions for Colour panel (and other colour choosers in the apps) versus rendering. These discrepancies exist for conversions between various colour models, not just CMYK to RGB.

If you ensure objects are specified with RGB values when working in an RGB document, you won't suffer these discrepancies.

 

[walt.farrell]

1 hour ago, ,,, said:

and latent CMYK profile SWOP v2.

What is a "latent CMYK profile"?

[lepr]

12 minutes ago, walt.farrell said:

What is a "latent CMYK profile"?

An Affinity document has a profile for each of the app's colour models. These profiles are used for conversions of colours from one model to another.

There is the manifest profile for the document's colour model, such as sRGB 2.1 for an RGB document.

There are the latent profiles for the other colour models of the app, and they are initialised with the defaults specified in the app's colour preferences when the document is first created.

 

[lacerto]

On 3/23/2023 at 7:18 PM, PitterPen said:

Am I misunderstanding something or doing something wrong?  I'm trying to match colors, and thus far I'm confused as to what is the source of truth for a color's RGB values.

Not really, it is just genuinely pretty complex. Affinity apps seem to use a different method when converting CMYK values to RGB in context of color pickers and rendered colors, and when converting color values in the Color panel and Color Chooser window. Exporting to raster image formats like PNG and TIFF appear also to be using the former method, while exporting to PDF (in RGB mode) uses the latter. After you have actually performed the color conversion to RGB, you will get the same RGB values disregarding the export format.

There is additionally a question of accuracy in display of color values, as Affinity apps do not show decimals in color values even if they internally keep at least five decimals. So the actual CMYK values that you have in the green rectangle are C0.82750, M0.40000, Y0.65490, K0.24310. After the actual conversion, you will get R0.16850, G0.40380, B0.35120, which converted to 8-bit values would be R42.9675, G102.969, B89.556, or rounded to nearest integer, R43 G103 B90. That the Affinity apps internally keep the decimals can easily be seen if you type in the CMYK values C82.6, M39.6, Y64.6, K23.6 (ending up in identical rounded integer values as initially displayed), the RGB conversion within this document would be R43 G104 B91 (instead of R43 G103 B90).

Converting from CMYK to RGB and back to CMYK continuously (=keeping the lock in the Color panel turned off), will change the color values gradually each time, and after a twenty conversions or so you would already have quite different color from the starting point. Depending on the document color mode and underlying profiles, and color models used in Color panel, an abrupt visual change could happen within just a few conversions, so keeping the lock habitually turned on (the state it is in also by default) is a good idea. 

[PitterPen]

5 hours ago, lacerto said:

Not really, it is just genuinely pretty complex. Affinity apps seem to use a different method when converting CMYK values to RGB in context of color pickers and rendered colors, and when converting color values in the Color panel and Color Chooser window. Exporting to raster image formats like PNG and TIFF appear also to be using the former method, while exporting to PDF (in RGB mode) uses the latter. After you have actually performed the color conversion to RGB, you will get the same RGB values disregarding the export format.

There is additionally a question of accuracy in display of color values, as Affinity apps do not display decimals in color values even if they internally keep at least five decimals. So the actual CMYK values that you have in the green rectangle are C0.82750, M0.40000, Y0.65490, K0.24310. After the actual conversion, you will get R0.16850, G0.40380, B0.35120, which converted to 8-bit values would be R42.9675, G102.969, B89.556, or rounded to nearest integer, R43 G103 B90. That the Affinity apps internally keep the decimals can easily be seen if you type in the CMYK values C82.6, M39.6, Y64.6, K23.6 (ending up in identical rounded integer values as initially displayed), the RGB conversion within this document would be R43 G104 B91. (instead of R43 G103 B90)

Converting from CMYK to RGB and back to CMYK continuously (=keeping the lock in the Color panel turned off), will change the color values gradually each time, and after a twenty conversions or so you would already have quite different color from the starting point. Depending on the document color mode and underlying profiles, and color models used in Color panel, an abrupt visual change could happen within just a few conversions, so keeping the lock habitually turned on (the state it is in also by default) is a good idea. 

 

Wow, thanks for all the information.  That's good to know about the color pad lock and to have it highlighted (i.e. selected/on) to prevent color switch shifting.

On a small note if the admins read this, a UI idea for V3 would be to make the padlock icon more clearly show when the color is locked vs. unlocked.  E.g. the icon could show the top of the padlock visibly lifted up/open in an unlocked state, and the top of the padlock down when the color is locked.  At a glance, I couldn't tell if clicking on it the padlock made it locked or unlocked.  

[NotMyFault]

V2.0 has a unfixed bug when using CMYK colors in RGB documents and vice versa, affecting vector objects (not pixel tools/layers).

Vector objects get simply wrong colors, which differ from settings in color panel.

 

[lacerto]

9 hours ago, NotMyFault said:

V2.0 has a unfixed bug when using CMYK colors in RGB documents and vice versa, affecting vector objects (not pixel tools/layers).

I am not sure if it is directly related to the topic of this thread, but nevertheless I could not reproduce the behavior, and the .mov resource in the original post did not seem to be available anymore. Could you elaborate a bit and give more specific steps and description of the issue (perhaps in the connection of the original post you made)?

[NotMyFault]

2 hours ago, lacerto said:

I am not sure if it is directly related to the topic of this thread, but nevertheless I could not reproduce the behavior, and the .mov resource in the original post did not seem to be available anymore. Could you elaborate a bit and give more specific steps and description of the issue (perhaps in the connection of the original post you made)?

Hi lacerto,

The video plays at least for me, it seems the random issue with forum software where some videos don‘t play occasionally. Just try again later or on a different device.

A gave a detailed step-by-step instruction in the same post, so unsure what i could add without repeating?

1. create a RGB document
2. add pixel layer
3. add vector shape on top (must be above pixel layer to stay visible)
4. group both
5. have hand tool active, and group selected.
6. use color panel to set colors, using CMYK in color panel. Drive slowly through values. Both vector and pixel layers get the same color assigned, but they look totally different. 
    

the relation to this thread:

• whenever you are using colors in color panel where the color format (RGB, CMYK, GREY) is not matching the document color format, the resulting colors are off
• pixel layers (brushes, fill tool) are severely off 
• vector layer colors seem off only a little bit by rounding errors when compared to Apple Color tools and between info panel / color panel. I use a Display P3 display, so all the 3 listed color formats get converted for display which may cause these small issues.

 

[lacerto]

The .mov resource stays unavailable to me (tried multiple machines), but I could now see the issue with the Pixel layer.

Pixel layers cannot typically be filled [by using a fill attribute], but having a mixed selection seems to have an effect of making the Pixel layer behave like an Image layer, which can be filled, so in RGB mode if the underlying pixels have RGB 128,128,128 you get identical fill with the vector objects. While I think that this is not intended behavior, this could be used in certain situations meaningfully.

The behavior when applying CMYK colors is not color managed but IMO this is trivial because if properly color managed results are wanted, they can be achieved using different methods (e.g., using K-Only mode and then colorizing with CMYK values, in which case vector and image fills behave identically). Being able to colorize image objects directly with fills is a nice feature and I can see good use of it with RGB images (and RGB fills).

As for vector objects, I cannot see any general issues in color management so what is described in this thread pretty much covers "anomalies" that I have found. I do not actually consider behavior described here "buggy"; different conversions from CMYK to RGB when rasterizing or exporting to vectors are something that can be experienced in other apps, as well, e.g. Illustrator. These are just things that one should know.

[lepr]

4 hours ago, lacerto said:

I am not sure if it is directly related to the topic of this thread, but nevertheless I could not reproduce the behavior, and the .mov resource in the original post did not seem to be available anymore. Could you elaborate a bit and give more specific steps and description of the issue (perhaps in the connection of the original post you made)?

Firstly, there is no direct relationship to the OP problem.

Recipe: simultaneously select a vector object and Pixel object in an RGB document. Adjust fill/primary or stroke/secondary colour with Colour panel in CMYK mode instead of RGB mode.

Expected result: the vector object and Pixel object should have matching colour in the document view. That is because:

• the vector object should have the CMYK colour definition (which will be displayed following colour managed transforms from the document's latent CMYK profile to the document's manifest RGB profile and then to the system's display profile)
• the Pixel object should be filled with a colour managed transform of the specified CMYK colour from the document's latent CMYK profile to the document's manifest RGB profile (and will be displayed after a further colour managed transform to the system's display profile)

Actual result: the vector object and Pixel object have different colours in the document view. That is because:

•  the vector object does get the CMYK colour definition
• the Pixel object gets filled with a naive non-colour managed conversion from the Colour panel colour model to the document colour model.

In my opinion, the lack of colour management in the filling of the Pixel object is a bug.

[lacerto]

Thanks, cross posting, I already commented this above. As said, I think that the issue is trivial because there are better methods to produce the desired effect so basically coloring RGB raster images with CMYK fills or vice versa and expecting accuracy is kind of silly.

[lepr]

33 minutes ago, lacerto said:

Thanks, cross posting, I already commented this above. As said, I think that the issue is trivial because there are better methods to produce the desired effect so basically coloring RGB with CMYK fills or vice versa and expecting accuracy is kind of silly.

I think it is a bug. I expect colour management to be applied consistently and not have illogical exceptions.

If we use the Fill command to fill a Pixel object with a CMYK colour in an RGB document, there is a colour managed transform from CMYK to the RGB that is actually put in the pixels. Similarly, If we use a brush to paint a CMYK colour in an RGB document, there is a colour managed transform from CMYK to the RGB that is actually used to modify the pixels.

Logically, there should be the same colour management in the "simultaneously selected" situation described earlier.

I agree that we should be specifying RGB colours in an RGB document to get accuracy, but I do not agree that an excuse should be contrived for the developer neglecting to apply colour management in the "simultaneously selected" case.

Edited March 26 by ,,,
provided logical argument

[NotMyFault]

17 minutes ago, lacerto said:

As said, I think that the issue is trivial because there are better methods to produce the desired effect so basically coloring RGB raster images with CMYK fills or vice versa and expecting accuracy is kind of silly.

Strong words. Then I would like to ask why Affinity allows such non-color-formt-matching color input in the first place?
 

For me the issue is that Affinity does too much of auto-conversions without any change for a user to influence the process, and too many bugs are open where the automation gets simply wrong.

It would be better to limit color panel to matching color format input only, and provide a limit „color format conversion“ panel which gives you the required control over parameters like gamma, color profile, percent / integer / hex / HSL / tint conversions.

It starts with the UI illusion that every RGB color can be converted into CMYK and back. It continuous with dealing paper influence on CMYK docs, and chick CMYK profile is used for color/info panel, etc.

 

[lacerto]

Maybe it is a bug, who knows. But I have some thoughts...

1. Are pixel layers intended to be fillable with an aid of a vector object selected with a pixel layer, in the first place? 
2. When coloring e.g. an RGB neutral gray 128, 128, 128 image layer, I can get kinds of tints and shades of the fill color used for coloring (and this happens both when using RGB and CMYK fills), so the pixel values are naturally supposed to mix with the fill color. They would be identical with a vector object filled with the same color only marginally. If I apply e.g. M100, the image layer would not look identical with a vector object filled with the same color, in either color mode. Personally I would not expect that since to behave this way the app should be able to automatically convert the underlying neutral gray to K100.
3. To call this a bug, we should assume that there is intended behavior [that fails]. I am not sure there is. IMO these are "interesting side effects of sloppily thought out feature", but marginally nevertheless useful.
4. I do not have expectations on how this feature should work since I have not seen similar feature implemented in apps that I regularly use. So when I want to have this kind of a colorizing effect I would typically cover an image with a vector object with the desired fill color and use something like Color blend mode.

Anyway, I do not expect this feature to be changed in any near future.

[lepr]

1 hour ago, lacerto said:

Are pixel layers intended to be fillable with an aid of a vector object selected with a pixel layer, in the first place? 

I queried that years ago. I was astounded when a Serif representative said, yes, the filling of Pixel objects in that scenario is deliberate. It also happens when you apply colour to a Group that contains a Pixel object, even when the Group contains only the Pixel object.

 

1 hour ago, lacerto said:

To call this a bug, we should assume that there is intended behavior [that fails]. I am not sure there is. IMO these are "interesting side effects of sloppily thought out feature", but marginally nevertheless useful.

I find the feature useless - the entire Pixel object is filled as if the user wanted a raster equivalent of a Fill Layer, and it can actually be an inconvenience to undo the destruction of a Pixel object's previous content. However, as I said, I distinctly remember Serif saying that it is deliberate. I remember the occasion so well because I had been so sure it would be confirmed as a bug, and was shocked by it being deliberate. Of course, now we'll probably be told it's a bug.

 

1 hour ago, lacerto said:

I do not have expectations on how this feature should work since I have not seen similar feature implemented in apps that I regularly use. So when I want to have this kind of a colorizing effect I would typically cover an image with a vector object with the desired fill color and use something like Color blend mode.

I would do the same with a vector Rectangle or a Fill Layer. I've never noticed any mention of the 'feature' being intended to provide a colourising effect. It is a complete filling of the Pixel object with a solid colour and that's what was said to be deliberate.

[lacerto]

3 hours ago, ,,, said:

I queried that years ago. I was astounded when a Serif representative said, yes, the filling of Pixel objects in that scenario is deliberate. It also happens when you apply colour to a Group that contains a Pixel object, even when the Group contains only the Pixel object.

Ok, if pixel layer is intended to be fillable this way, similarly as it were filled in Photo with the Flood Fill tool, then the behavior should of course be identical, and applying the color should be color managed in this context, as well. But to me it appears presently that the effect of applying CMYK color via vector object causes a blend effect (e.g. something like a Hard Light) with underlying pixels (empty layer being interpreted as white pixels), so it did not appear have anything to do with color management, failed color matching, or "naive color conversion", as you put it, so I thought that if at all intentional, it was meant to behave as if applying a colorizing effect on an image layer (but that gone wrong, as well). But I can see now that it behaves as a Flood Fill tool [EDIT: and at 100% tolerance!] with an RGB color fill. So yes, a bug [EDIT: and yes, a pretty useless feature].

[lacerto]

Here is yet one take to the discussion of applying direct mix color mode CMYK fills on Pixel and Image Layers.

I wanted to create this to stress my initial point (which was first based on misunderstanding on how the vector-shape assisted flood fill was supposed to be working). Now that I understand the purpose of this functionality, I think, too, that the feature should be color managed similarly as when applying M100 fill in an RGB document using the Flood fill tool.

[It is another matter, but it is questionable whether this kind of a feature is reasonable at all. IMO it is not since it basically applies a tool based operation using an attribute  assignment, which is counter-intuitive and also surprising, considering that applying a fill attribute directly on pixel layer does not have any effect at all. In addition, when the feature is applied, a limited size pixel layer on which the attribute is applied, will auto-resize to canvas size rectangle when applied (similarly as in e.g. Designer, where Pixel layer initially cannot be dimensioned but gets the canvas size), and when re-applied in alternate color mode (and is already converted in context of color mode switch), will apparently freeze the app when the color is applied but actually causes a hugely large rectangle saving of which results in a 33MB large file (as it is a pixel layer, even if solid color, that is saved), after which the document continues to be highly unresponsive (but not frozen), until the layer is rasterized. It does not seem that the feature was ever really planned, and it certainly has not been debugged. The test was performed on Windows version 2.04 on Windows 11 Pro.]

Aside from this, and to the point of reasonability of using mixed color modes in context of vector-fill assisted flood fills and colorizing image layer based bitmaps, I created a bunch of PDF files comparing how applying colors are managed and matched in different scenarios, when applied in RGB and CMYK document color modes and producing to different kinds of PDFs. [The color profiles used here are sRGB for RGB and US Web Coated for CMYK, so Affinity defaults.]

The conclusion is that this kind of mixing of color modes never works accurately. In an RGB document one can get very close when applying a CMYK color fill on a mid-gray RGB bitmap on an Image layer when exporting a Device-CMYK PDF, and when doing a similar CMYK based flood fill in an RGB document, but completely accurate results can only be achieved when using a CMYK mode document with RGB black (0, 0, 0) document in K-100 mode (= equivalent of using a grayscale document in Adobe print environment). That is, when applying a CMYK fill on a "grayscale black" in a CMYK document, and exporting to device-CMYK. This is an old-school approach that Affinity apps can produce using the K-Only method, but trying anything fancier is basically waste of time when aiming at color accuracy. The mere effort of trying to do so is a bit silly when accurate methods are readily available. Mixing color modes and assuming a perfect match by virtue of color management just cannot work, and additionally ruins possibilities to produce consistently behaving colors for dual color spaces. One should rather create in consistent color space and let the color management do its job when producing, instead of working confusingly in mixed color modes, applying arbitrary blends and effects, and assuming consistent matching of colors and expecting things to get automatically sorted at export time, or by using the PDF/X-4 magic wand (not resolving anything but trusting that all goes well when finally rasterizing). 

This does not mean that one should not use mixed mode color definitions and assume that color management works as expected: it is just a question of assumed accuracy, and trying to match mixed mode definitions overlapping or existing side-by-side. Affinity apps handle just fine color conversions and the complexity of dual color-mode production -- despite some limitations -- so e.g. the Color panel works just as expected in context of color conversions. The "vector-fill-assisted-flood-fill-in-mixed-mode" issue aside, color-wise (not going to complexity of PDF production) the quirks and small discrepancies in behavior of color controls have mostly been covered in this thread.  

mixed_colors_rgbdoc_rgb.pdf

mixed_colors_rgbdoc_cmyk.pdf

mixed_colors_rgbdoc_mixed.pdf

mixed_colors_cmykdoc_rgb.pdf

mixed_colors_cmykdoc_cmyk.pdf

mixed_colors_cmykdoc_mixed.pdf

 

[thomaso]

While the occurrence and value shift caused by multiple conversion toggling and possible decimals is known and got logged for V1 a few times (2018 – 2020) as afd-3210, I wonder whether a similar but apparently more confusing issue still occurs in V2, too.

The CMYK sliders when editing a non-CMYK swatch in the Swatches Panel show quite different values for its equivalent in the various colour panels. (logged 2019 / not tagged). Any idea what is causing this difference? Are the swatches panel values some way 'unprofiled' converted?

BTW, for custom named swatches the unlocked Color panel seems to be the only way to detect the colour mode of a swatch, while having it locked in a "wrong" mode may mislead when editing a swatch.

 

 

[lepr]

3 hours ago, thomaso said:

While the occurrence and value shift caused by multiple conversion toggling and possible decimals is known and got logged for V1 a few times (2018 – 2020) as afd-3210, I wonder whether a similar but apparently more confusing issue still occurs in V2, too.

The CMYK sliders when editing a non-CMYK swatch in the Swatches Panel show quite different values for its equivalent in the various colour panels. (logged 2019 / not tagged). Any idea what is causing this difference? Are the swatches panel values some way 'unprofiled' converted?

 

 

Yes, there can be an initial naive colour conversion instead of colour managed conversion in the little colour editors throughout the apps. The linked thread below involves that problem. Essentially, the user must be careful to ensure a little editor already has its sliders in the actual mode of an existing colour's definition before opening the editor, otherwise the editor will start with a naive non-colour managed conversion to the editor's mode.