Affinity Designer 2.1.0 seems to have dropped correct colour handling of sRGB via ICC profiles (Windows 11)

[quantos]

I have just this moment updated Affinity Designer to v 2.1. I probably need to re-install the previous version to fix the following glitch, which is that upon installing 2.1 colours are washing out in the editor and Affinity seems to have changed it's look-up values (sorry I can't explain that more technically) but here's what I've just found..

In a colour test document I created several days ago (to test my new Dell Alienware AW3432DW (QD-OLED) monitor) I created a flat rectangle in Affinity 2.0 with a flat rgb hex colour #61CE70 (a bright limish green) from my target website and pasted in a grab from the homepage target website that uses this colour. In Affinity Designer 2.0 with the workspace set to use the default sRGB IEC61966-2.1 colour profile pasted-in flat colour (#61CE70) perfectly matched the flat rectangle. But after updating to Designer 2.1 the colours don't match and rather oddly I can see, using the colour inspector, the previously input hex reference has been changed from #61CE70 to #00D363 whereas the colour being displayed (to the naked eye) is the correct (brighter) colour that match the browser (Chrome and Edge). See grab #61CE70-mismatch-pic-1.png attached.

IE Designer 2.1 seems to have taken upon itself the job of updating colour objects set in 2.0 to 2.1.

My new OLED monitor supports a very wide gamut spectrum well beyond sRGB but is presently set within Windows 11 Color Management to use the ICC sRGB IEC61966-2.1 colour profile - from my test colour matching file was first set-up (in Designer 2.0).

My colour preferences within Designer 2.0 were not changed before running the update.

I suspect that Designer is perhaps ignoring the preference setting to use sRGB IEC61966-2.1 colour profile set (in Designer 2.0) - but don't have any tools/ability to test that further - and suspect it is attempting to update the colour values within the document to match this monitor's default colour profile (in Windows) which is roughly 95% of "Display P3" colour specification. One of the reasons for suspecting this is I do re-input my test flat rectangle to use #61CE70 again (as specified in Designer 2.0) the test colour then re-matches (more or less) the washed-out lime green in the grab. This is shown in the second attached image #00D363-mismatch-pic-2.png.

If you compare the two images attached here you should be able to clearly see (and hopefully test/debug) what's going wrong here.

Do let me know if supply any more information - but meantime I'll have to re-install Design 2.0 to work around this problem.

Thanks.

C.

[quantos]

In case not clear, the image grab behind the rectangle also shows the wrong flat green being imported into Designer 2.0/2.1 (from a previous test). The actual site the grab is taken from is https://www.flexej.co.uk/ - in case you want to check/test actual hex colours set there.

NB In my test file I was trying get the new AW3423DW Alienware colours to work best in what it calls 'Standard' (or SDR) mode which for now also seems best suited to using sRGB colour mode. IE when that monitor is set to use the sRGB colour profile colours and properly bright and match existing Affinity Designer 2.0 artwork + actual colour in web browsers.

And so this is a very unwelcome set-back in Designer 2.1, hence need to re-install back to 2.0 - although I do need a proper primer again on colour management within Affinity Designer as well as on how to set-up both my monitor and Affinity Designer to use the higher colour spec "Display P3" which I can't get to run at all properly on the new monitor either. All colours drop all vibrancy/luminescence and overall screen brightness drops a good 40% or more - hence sticking with sRGB and standard colour mode until I can get all the colour spaces to work properly together at that specification.

As you guys must be working with this all the time it would be great to see if you have any updated guides you've put together that goes through colour set-up for Affinity and the latest generation of high-gamut monitors.

Many thanks.

C.

[quantos]

Oops. Ignore this for now. I've just spotted that my Affinity Designer file was set to use the wrong colour profile internally (and not the sRGB IEC61966-2.1 profile in my preferences). I'll re-test but there's a very good chance that everything posted above is completely wrong! 🙂 

I'll update again if it's not.

 

C.

[quantos]

Actually, there is something odd going on here... but I don't know how/where and it may be the same on Affinity Designer 2.0 and 2.1 and so my apologies for any confusion but now I've checked everything again do look at the freshly-attached new grab which I think explains itself but the explanation + query is this:

1. Hex colour #61CE70 shows 'correctly' in the browser. This is a long-term client secondary brand colour reference; but
2. Eye-dropping the specified (and correct-looking) colour from Affinity Designer (2.0 in this test) Designer thinks the colour is #00D363 - which when viewed in either Affinity Designer 2.0 or 2.1. IE it looks correct (perceptually correct/more luminescent).
3. If I paste in a Windows screen grab of the page (with the referenced #61CE70 green button) into Affinity Designer, the colour looks washed out (as mentioned in my earlier reports) and Affinity's eye-dropper also believes the washed-out colour is #61CE70!
4. So the question is why don't these colours all match correctly? And the concern is which colour reference system is right? IE Why does Affinity believe that the specified #61CE70 is actually #00D363 when viewed in the browser?

Re the various colour settings in play here (on my Windows 11 desktop PC):

• The document colour space (profile) within this test Affinity Designer file is set to sRGB IEC61966-2.1 colour format is RGB/8
• My Alienware AW3423DW OLED display is set within Windows > System > Display > Advanced to use the monitor's Standard (SDR) color space (8-bit depth/RGB)
• The display monitor is also set to use the sRGB IEC61966-2.1 ICC profile via the System > Display > Advanced > Color Management utility
• Brightness/contrast and gamut all set to use recommended/out of the box monitor parameters too.

And so my understanding is that everything should be displaying correctly/consistently under the sRGB IEC61966-2.1 specification - where the underlying problem is the concern that the colours I'm using within Affinity don't seem to match specified hex/rgb colours used elsewhere within Windows.

Perceptually, the colours specified in my sites/css and shown in the browser window/s seem correct so can you explain what is going on or have recommended guides/sources for checking what Affinity is doing in my/this case? 

[patricr]

I agree that something has changed in version 2.1 Designer. My display has washed out colors compared to the previous 2.0. I have experimented with the color settings- but have not found what might have changed.

Sorry, forgot to give more info: Mac M1 silicone, System 13.4. 

I just uninstalled v2.1 and reloaded v2.0 and the washed-out appearance went away with the older version.

Here is a comparison of how my styles panel looks in each version, other than the gray background of one- the v2.1 woods are washed-out.:

 

Edited May 21, 2023 by patricr
More information added

[lepr]

7 hours ago, patricr said:

Here is a comparison of how my styles panel looks in each version, other than the gray background of one- the v2.1 woods are washed-out.

Your screenshot shows Aspen, Beech, Lacewood and Oak thumbnails looking exactly the same in 2.1 app versus 2.0.

The problem in 2.1 that you show is the Aspen thumbnail being used for 10 styles, and the Beech thumbnail being used for 6 styles.

Do the styles match their wrong thumbnails when applied to objects in 2.1?

 

[patricr]

Thanks for the rapid reply.

Good catch! I had not noticed that. Aspen is the wood grain in the others.

Perhaps there is some change/corruption that v2.1 has that does not honor the proper styles I created.

However- all the style swatches are not saturated as they are in V2.0. The color saturation in v2.0 is correct.

 

Have any idea why? Is this forum the proper place to submit a bug?

[lepr]

6 hours ago, patricr said:

However- all the style swatches are not saturated as they are in V2.0. The color saturation in v2.0 is correct.

Image below shows style swatches from your comparison, all on grey background. There is no difference in saturation. Maybe your perception was misled by the grey versus white backgrounds.

[patricr]

Good idea, but when I change the UI interface to dark and the background of the styles window goes very dark- the saturation is still low. There is also the problem of many of the style selections going to the Aspen instead of the display they should have!

The saturation problem carries over to the shapes in my document that I apply the styles to, they are washed out in the document also.

So what color setting(s) might be different?

[lepr]

3 hours ago, patricr said:

Good idea, but when I change the UI interface to dark and the background of the styles window goes very dark- the saturation is still low. There is also the problem of many of the style selections going to the Aspen instead of the display they should have!

The saturation problem carries over to the shapes in my document that I apply the styles to, they are washed out in the document also.

So what color setting(s) might be different?

Sorry, I'm unable to give further assistance with your desaturation problem.

This linked thread seems to be concerned with styles becoming incorrect after updating to 2.1.0: 

 

Edited May 22, 2023 by lepr

[quantos]

Hi guys. I presume I'm correct to assume that someone from Affinity will get back to us here on the issue mentioned in the subject as from my professional perspective there's a fatal error with the software right now (or something in my set-up) but to summarise again: Affinity Designer 2.1 doesn't seem to be rendering sRGB IEC61966-2.1 colour correctly (for all the reasons stated).. if someone could please confirm they will be looking into it. How long does a reply normally take at the moment? Many thanks meantime.

Q.

[Dan C]

Hi @quantos,

Thanks for your report and our apologies for the delayed response here!

From all of the information provided, I have tested this here between v2.0.4 and v2.1, please see my results below, with a copy of the .20.4 file which can be opened in either version -

#61CE70.afdesign

As can be seen, in both versions this HEX colour is correctly picked and represented from both an image of this specific HEX colour, and a screenshot from the website example you have provided above.

Can you please confirm for me, preferable with a screenshot, what are your settings within Affinity Designer under Edit > Settings > Colour? 

Can you also provide a screenshot of the Colour Management within Windows, as I have done above? I appreciate you have confirmed you have set sRGB here, simply I'd like to check I'm not missing something else - as this all seems to be working as expected on my end currently.

Many thanks in advance!

[quantos]

Thanks Dan...

Grabs below of my current settings.. where I have now used the Windows colour calibration tool to create a slightly modified sRGB profile. The oroginal tests were all done using the standard sRGB profile exactly as yours is set-up. Here's the grab of my current set-up:

As well as the Monitor settings:

Using the new calibrated profile (shown) I now also get a new colour reference variation using the eye-dropper tool but have noticed that it's only in the middle-green area of the HSL colour picker where the variations are coming from (although why they are different to the hex-referenced grabs is still beyond my understanding)..

 

NB that #00D363 eyedrop was the original pre-calibrated grab (which perceptually to me here looks to be 'right'). The new #63CF6F was taken just now using the new calibration which closely matches the screen grab and actual #61CE70 and so all a bit strange.

Document set-up colour here:

PS I have noticed that Affinity Designer 2.1 seems to be eyedropping other colours accurately and it is only these mid-scale greens that seem to have the problem - although I'm no expert and can't really guess how this is possible. HDR, by the way, is turned off for all this and I don't use it for graphics/colour work. NB eye-dropping those other two primary and secondary colours shown the html #325187 and #0066CC seems to work flawlessly. I could set-up a better two for you if you suspect the colour-drift is based on either Affinity Designer or the monitor not actually using the colour profiles specified (if that makes sense)? IE if the monitor is really using Display P3 instead of the specified sRGB?

Do let me know if you need anything else to investigate further- thanks.

Q.

[quantos]

Hi Dan C/Affinity..

I might yet have to go back to re-test everything to make sure I haven't made a mistake but I have just made another simple test today with a fresh screen grab of the flexej.co.uk reference site (see attached) which can be seen in the top left area and Affinity Designer reports via the eye-drop tool that this is the target #61CE70 colour. This is also the same if I screen grab Dan C's post, paste that into Affinity 2.1 and then eye-drop that grab within Affinity 2.1 BUT if I eye-drop either this test site directly or eye-drop Dan C's post directly from the forum then Affinity Designer reports that BOTH colours are #63CF6F! Obviously there's only a very small mathematical difference between #61CE70 and #63CF6F, just 2 points of Hue of 1 point of luminance but shouldn't they be identical?

HSL/hex colour dial grabs of these also included for quick reference.

Also now included: some reference grab/tests around the specified #0066CC which I can see shows only a very tiny difference between the specified hex colour and eye-drops from the pasted-in screen grab (which Affinity 2.1 thinks is #0066CB) whereas if eye-dropped direct from the site/browser (Chrome) is #0066CD. I can also see that in terms of HSL specification that Affinity is reporting that all three of these blue #0066CC variations are HSL 210.100.40 - and so the question is are these just all machine/tolerance variations (which are possibly OK) or should we expect these all to be the same?

Hope that helps.

Q.

[Dan C]

Many thanks for these quantos, it's certainly appreciated!

Affinity performs document-to-screen colour conversion, using the documents colour profile and your display screen profile to display the colours on screen - therefore the app may be 'picking' the correct HEX code, but the colour displayed is slightly different, based on the colour profile applied to your monitor.

You can find out more about this here - https://affinityspotlight.com/article/display-colour-management-in-the-affinity-apps/

I can see your document is using the sRGB profile, but I still need to confirm your application Colour settings. These can be found under Edit > Settings > Colour - can you please provide a screenshot of this for me?

When taking a screenshot and pasting into Affinity, this will by default be pasted as an 'Image' layer, which will include the colour profile applied to your document. Essentially this means the screenshot is being converted from screen profile embedded within the image, to the document profile (sRGB), then back to the screen profile to be displayed on the canvas - which may also cause colour inaccuracies.

After pasting your screenshot into Affinity, if you right-click this layer and select Rasterise, this will be converted to a Pixel layer, which will then use the document (sRGB) profile, rather than the embedded monitor profile.

5 hours ago, quantos said:

Also now included: some reference grab/tests around the specified #0066CC which I can see shows only a very tiny difference between the specified hex colour and eye-drops from the pasted-in screen grab (which Affinity 2.1 thinks is #0066CB) whereas if eye-dropped direct from the site/browser (Chrome) is #0066CD. I can also see that in terms of HSL specification that Affinity is reporting that all three of these blue #0066CC variations are HSL 210.100.40 - and so the question is are these just all machine/tolerance variations (which are possibly OK) or should we expect these all to be the same?

As far as I understand it, these should be consistent without tolerance - but as above this can change based on many factors, including the type of 'layer' the image is within Affinity.

Personally I would recommend using the standard sRGB colour profile for your display through Windows settings, as we tend to see fewer colour issues with this profile set - but technically there should be no issue with having your calibrated profile set here - as this does appear to be moving us in the correct direction in your latest testing

[quantos]

Thanks again Dan. Much appreciated and thanks for the link too - although colour preferences already set to sRGB..

I've also ordered a SpyderX Pro colourimter to properly test my monitor (even though by reputation these new QD-OLED monitors are supposed to have very good SDR colour values out of the box.. but the QD-OLED is a relatively new spec still and the pixel structures and the same as LED or LCD's which may be a factor for eye-dropper (?). Either way, your help/support has been great and it looks like every is fine (except those very minor tolerance differences via the eye-dropper, which is still curious unless explained by the shape of the QD-OLED pixels, or something else still).

Thanks again meantime.

 

Q.

[Dan C]

Thanks for providing that for me, your settings all seem to be correct.

Do you see any improvements if you Rasterised the pasted layers as suggested please?

It's certainly possible that performing a full calibration, creating an even more specified custom colour profile will improve your results, so please do let me know how you get on here and many thanks for your kind feedback