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

[Hangman]

18 hours ago, thomaso said:

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?

This is again owing to the non colour managed conversion from CMYK > RGB > CMYK, you won't see this in the Colour Panel if the Colourspace is locked, however there is a bug in V2 where converting from CMYK > RGB > CMYK using the Swatches Panel is actually physically changing the Swatch Colour requiring a manual reset...

[lacerto]

On 5/3/2023 at 4:17 AM, thomaso said:

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?

I don't know what this should be called, naive conversions or what. I am not sure if this specific issue has anything to do with conversions, it appears to be just sloppy macOS UI programming. I cannot reproduce this behavior on Windows versions (latest 1.x, 2.x or beta). It seems to be somehow related to refresh issues. In 1.x versions the swatch specific CMYK sliders are not updated at all (RGB based are; have not checked other models), in 2.04 they are updated once the color is assigned to the object and it gets repainted (on second assignment), in latest beta there is some issue with RGB color model getting updated (possibly just on model). I am not sure if it is getting closer --perhaps it is now close enough 🙂 

 

Btw, the behavior is not palette specific, it can be reproduced with any palette. 2.x versions introduced some new refresh issues related to color assignments while also fixed some other. I am not sure if the problem described by @Hangman is also related to screen refresh issues, but I could not reproduce it on Windows versions.

 

UPDAtE: No, it's worse than ever (on macOS): as Hangman described, the swatches now get inadvertently redefined in selected color model, hence the shift of RGB color definition shown in the video above when using the latest beta and CMYK sliders. Might a programmer palaver be worth an effort (the Windows guy at least understands the logic)? I do not think that the internal color values of library palette based swatches should ever be changed. Their CMYK/RGB definitions should stay within the original color scope and not fluctuate based on whatever color profiles are currently in effect.

UPDATE2: These are basically all consequences of bad initial design of color palette functionality. Editable swatches should be clearly separated from color definitions of saved palettes, and at least saving should be made an explicit operation.

[Pšenda]

5 hours ago, lacerto said:

It seems to be somehow related to refresh issues. In 1.x versions the swatch specific CMYK sliders are not updated at all (RGB based are; have not checked other models)

 

[thomaso]

6 hours ago, lacerto said:

Btw, the behavior is not palette specific, it can be reproduced with any palette.

I assume you don't mean literally "palette" but rather the colour space of its swatches, right?

Interestingly I don't get the issue of differing CMYK values when editing CMYK swatches in the Swatches panel but only for RGB / HSL swatches. This seems to be different to your video (where the RAL palette has CMYK swatches while the RAL swatches in my palette are RGB defined). – I doubt my v1.10.5 matters here vs your v1.10.6 (which was released as not relevant to mac), but I also doubt the macOS version matters here. But what?

This leads me to the converting behaviour of the Picker Tools. Whereas "Paste Style" maintains the colour space of a copied object using the colour pickers always convert a picked colour to the document colour space. This may be wanted in a certain workflow but also can cause unexpected print results, e.g. if a clients corporate colour resource got picked + assigned. (Also possibly misleading are the differing colour spaces that get reported below the Colours Panel Picker for colours picked in the UI from swatches + picked colours.)

[lepr]

12 hours ago, lacerto said:

I don't know what this should be called, naive conversions or what.

Naive colour conversion was my term for a non-colour managed conversion from one colour model to another. That was happening in the little colour editor (used for editing a palette swatch or a gradient stop or an FX colour) in the Affinity 1 apps on macOS in a particular circumstance. The circumstance being the editor opening in a different colour mode than a colour's actual definition (because the editor opens in whatever mode it was in when last closed). The colour's actual definition correctly wasn't being changed to the editor's displayed mode and values (unless a control was deliberately touched), but the displayed values were being naively calculated in that particular circumstance.

The little editor of the current 2.1 beta apps on macOS no longer does a naive colour conversion in the aforementioned circumstance, which is good. However, as you've discovered, there is a new dangerous bug of a palette swatch's colour definition being changed and saved without the user touching the controls in the editor.

[lacerto]

12 hours ago, ,,, said:

The little editor of the current 2.1 beta apps on macOS no longer does a naive colour conversion in the aforementioned circumstance, which is good. However, as you've discovered, there is a new dangerous bug of a palette swatch's colour definition being changed and saved without the user touching the controls in the editor.

Thanks for the additional information. Yes, I think this happens (or at least used to happen) also on Windows. It may be that something similar also happens in 1.x and 2.04 versions on macOS when the swatch editor is opened in CMYK mode (to edit an RGB based swatch): the CMYK values are oddly off (not converted according to color profile environment). in 1.x versions the underlying swatch values however are not changed unless the user touches the slide controls or types in values in color boxes. In versions 2.04 and still in the latest beta, the color definition is saved to the swatch simply by opening the color editor (double clicking the swatch), or switching the color model, the difference being that in latest beta the color is now initially correctly converted, according to the active color profile environment. It is odd that this behavior is not experienced on Windows since typically the underlying code seems to be logically identical. Perhaps there is something OS control specific, since it does not seem reasonable that there are residues of some simplistic formula based abstract color conversions left in macOS versions of the apps (at least up to 2.04 release version), but not in Windows versions.

Though it is basically fine to allow editing of document and application palettes, the apps would benefit greatly if they made a distinction between "working palette" (the kind of document palette used e.g. in InDesign or Illustrator) that gets automatically or manually updated based on colors used in the document, and which keeps the (global) assignments. This palette could then be freely edited (with improvements, like with ability to assign to another color in context of deleting a color), while editing of secondary document and application palettes -- even if not file-based -- would by default be disabled. Editing could be allowed but the resulting color definition would be automatically added to the working palette (a bit similarly as when adding a swatch from read-only PANTONE palettes).

The apps could perhaps allow editing of secondary document and application palettes, too, but that would be an explicit act, and changes would need confirmation. This way it would be safe for users to import "library" kinds of industrial palettes like RAL, additional PANTONE guides, NCS, DIC, Toyo, TRUMATCH, HKS etc., and also miscellaneous shareable user-defined palettes. Typically color values of all these kinds of palettes are not wanted to be touched in context of usage, but it would nevertheless be fine if Affinity apps could be used as palette editors on demand, and edits would be confirmed. Since changes are saved only within Affinity apps, the original import files would never be affected. Sharing is currently limited to .afpalettes. but should ideally be improved to cover at least the .ASE file format export. 

UPDATE: It just occurred to me that e.g. Windows API (native 32-bit) requires color management applied manually to UI controls, and not all control types can be covered unless using custom ("owner-drawn") paint routines. This would mean that part of the UI controls would be guaranteed to behave differently than a complex color-profile based color management used in graphic design apps, or possibly left totally unmanaged (the kinds of things we have seen e.g. in context of applying color to pixel layers selected with vector shapes, or at some point, saving "CMYK" PNGs (technically impossible but if "done", the "management"=raw conversion would be left to the OS) . Perhaps something like this has happened on macOS (and still may happen with mini-editors within controls on both platforms). Windows has always been poorly color managed at OS level (e.g. in context of File Explorer) but might provide robust color management in context of modern frameworks.

[Hangman]

On 5/4/2023 at 1:25 PM, thomaso said:

Interestingly I don't get the issue of differing CMYK values when editing CMYK swatches in the Swatches panel but only for RGB / HSL swatches. This seems to be different to your video (where the RAL palette has CMYK swatches while the RAL swatches in my palette are RGB defined).

There are a number of considerations here...

The colour, swatches and colour chooser palettes display differently in different versions of the apps on macOS.

V 1.10.6 - Colour Set to 8 Bit

• The swatches panel displays the non colour managed 8 Bit CMYK swatch values
• The colour chooser displays colour managed percentage CMYK converted values

V 1.10.6 - Colour Set to Percentage

• The swatch panel displays the non colour managed percentage CMYK swatch values
• The colour chooser displays colour managed percentage CMYK converted values

V 2.0.4 - Colour Set to 8 Bit

• The swatches panel displays the non colour managed 8 Bit CMYK swatch values
• The colour chooser displays colour managed percentage CMYK converted values

 

V 2.0.4 - Colour Set to Percentage (Swatch Panel First Double Click)

• The swatch panel displays the non colour managed percentage CMYK swatch values
• The colour chooser displays colour managed percentage CMYK converted values

V 2.0.4 - Colour Set to Percentage (Swatch Panel Second Double Click)

• The swatch panel displays the non colour managed percentage CMYK swatch values
• The colour chooser displays the non colour managed percentage CMYK swatch values

V 2.1.0 (1790) - Colour Set to 8 Bit

• The swatches panel displays colour managed 8 Bit CMYK converted swatch values
• The colour chooser displays colour managed percentage CMYK converted values

V 2.1.0 (1790) - Colour Set to Percentage

• The swatches panel displays colour managed percentage CMYK swatch values
• The colour chooser displays colour managed percentage CMYK converted values

 

However, the bug in v2 apps also means that the swatch itself is being modified to both new colour values and colour models based on the slider settings in the swatches panel and means for example that an RGB swatch is converted to a CMYK swatch when the swatch is double clicked in the swatches panel with the CMYK sliders shown.

[Hangman]

On 5/4/2023 at 1:25 PM, thomaso said:

This seems to be different to your video (where the RAL palette has CMYK swatches while the RAL swatches in my palette are RGB defined).

This isn't the case, it's simply that @lacerto has the lock colourspace option selected so you are seeing CMYK values rather than the swatches actual RGB values in the colour panel.

 

[thomaso]

1 hour ago, Hangman said:

On 5/4/2023 at 2:25 PM, thomaso said:

This seems to be different to your video (where the RAL palette has CMYK swatches while the RAL swatches in my palette are RGB defined).

This isn't the case, it's simply that @lacerto has the lock colourspace option selected so you are seeing CMYK values rather than the swatches actual RGB values in the colour panel.

In @lacerto's video the lock is active for V1 …

… but un-locked for V2 while both show the same palette. Thus the lock for V1 does not matter here = not indicate another than the CMYK swatch definitions.

Different to the RAL palette in my test which shows RGB in un-locked state:

[lepr]

37 minutes ago, thomaso said:

… but un-locked for V2 while both show the same palette. Thus the lock for V1 does not matter here = not indicate another than the CMYK swatch definitions.

 

That image of v2 shows the lock enabled inside the green ring. The lock is significant in all versions of Affinity.

[thomaso]

29 minutes ago, ,,, said:

That image of v2 shows the lock enabled inside the green ring.

Oh, sorry. Does it mean in V2 the lock state is not indicated any more by its background colour? … but a different lock colour?

[lepr]

3 minutes ago, thomaso said:

Does it mean in V2 the lock state is not indicated any more by its background colour? … but a different lock colour?

In v2, there is no change to the lock's background. Instead, the lock has greater contrast when enabled versus disabled, and the icon actually changes between an open padlock and a closed padlock. 

 

  

[lacerto]

II might have misunderstood something, but I have not been able to reproduce a situation where 8-bit vs. percentage values have any significance in managed/unmanaged color conversions, or inadvertent redefinition of swatch definitions (they just further complicate the way color values are displayed). Lock does not have any effect on this behavior, either, in any other control than the Color panel, where it prevents color definition from changing if the color model is changed (if the lock is turned off, simply just switching the color model will redefine the selected object's color into the color model switched to).

In context of Swatches panel color editor (drop-down control), color values displayed are unmanaged in 1.x and 2.04 versions, and managed in beta, no matter whether 8-bit or percentage values are shown, and in versions 2.04 and beta the swatch definition will inadvertently change to whatever color model is used in the swatch editor drop-down, whether the lock is on or off. It happens immediately when the editor is opened, whether color model is changed or not. In 1.x versions this does not happen so there the user must type in color values, or touch the sliders, to cause redinitions. Switching the model in the Swatch editor does not change the definition, either.

None of this (non-managed conversions, or inadvertent redefinition of colors) happens in any of the mentioned versions on Windows.

But in all versions and all platforms, the user can re-define swatch color definitions by using the Swatch editor by typing in values or using the sliders. IMO this should be made more difficult (since even without the glitch in 2.x versions on macOS, it is too easy to make "inadvertent" changes), either by offering a mode where editing is allowed, and then requiring a separate operation where the made changes are saved to the palette (e.g., in context of switching the palette, closing a document and having edited any of the document palettes, or closing the app and having changed any of the application palettes), or perhaps by requiring the confirmation as per swatch (similarly as deletion is confirmed), which would of course make massive editing a bit tedious. Or, by doing the same as when a color is picked from a PANTONE palette: copying the swatch definition into a document palette rather than allowing editing the original definitions in the palette from which the color was picked.

UPDATE: This error has not been fixed in the 2.1.0 release version of the apps.