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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

[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]

Obsolete.

[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, 2023 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]

Obsolete.

[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]

Obsolete.

[lacerto]

Obsolete.

[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.