VolkerMB

@Callum Hi there! One more thing: I've installed Affinity 2.1.0 on another PC with an AMD card (RX 5700xt) and set the display scaling to 115%, too. Result: no issues. So, with my devices the crashes happen only on the nVidia machine. Best, Volker

Hi @Callum, thanks for looking into that. Some infos about my system: Windows 10 22H2 (built 19045), Intel i7-7500U, 16 GB RAM, nVidia Geforce 940MX with driver version 531.79, Windows custom scaling set to 115%. The same laptop worked fine with Affinity 2.0.4 and still does with 1.10.6, but crashes with 2.1.0 without warning or crash report as described initially. Best, Volker

Hi there! While 1.10.x and 2.0.4 do work fine at my end with setting custom dpi to anything but 100/125/150/175%, the new 2.1.0 doesn't. That is a step backward. The Affinity apps do start despite having set Windows 10 to a custom dpi value, but the moment I want to call the colour dialogue in Affinity the apps crash without any warning or any crash report. The are also reports here in the forum that it does happen with the gradient tool, too. Would be highly appreciated if this regression could be fixed with the next version/update. Best, Volker

Okay, I am back in business! How so? After I had done the test drive with my friend's Benq display I encountered some wiered situations with my original display configuration: During a session with Affinity Photo both my display went black. Only a restart brought the displays back. The same happend two more times the next day. The reason: Windows switched back to its basic display drivers and discarded AMD's drivers. In total I had to reinstall them three times. Fortunately I got hold of a used Nvidia RTX 2070 and installed it. What can I say? Colors are rendered correctly on both screens and Windows sticks to Nvidia's drivers. Apparently something was wrong with either my RX 5700xt or AMD's drivers. Who knows... So, thanks for all the input and suggestions. They've deepend my understanding of color management a lot.

Just want to report the results of a test drive: Thanks to a friend I was able to connect a Benq display to my computer. To no avail. With my friend's computer the Benq rendered decent colors (also in combination with a LG-sRGB-display next to it), but with my computer it is a different story (yes, I used a fresh icc profile I created with my X-Rite colorimeter). Therefore, I took the Eizo to my friend's place to test it with his computer. The result: decent colors. So, my conlusion is: Something is broken or misconfigured under the hood of my pc. But without a degree in computer science I might not be able to get to the core of the issue. On the surface everything looks configured correctly, but somehow it is not. At least I can roule out that the display hardware is broken. On a sidenode: If I switch off icc settings with my second display (Dell) and let Windows decide how to address colors, both monitors look very similar in terms of tonality (temperature). Still, the Eizo is way oversaturated and overly bright, but the Dell shows warmer colors now. If I go back to icc profiles for the Dell, it renders colors much cooler, darker and dull, again. Next, I will try to get hold of a different graphics adapter...

@rvst At least Windows flags the sRGB IEC61966-2.1 profile as a display profile... But I am not an expert. Therefore, I did install a dedicaded profile for the Dell U2417H from TFTCentral as suggested by @v_kyr. However, my eyes don't spot a difference to the sRGB IEC61966-2.1 profile. After having looked at several test images for at least 10min I'm under the impression that there is a tiny, tiny, tiny difference in how green is rendered. But apart from that... Unfortunately the Dell display is not the troublemaker here. It is the Eizo display. So, I called some friends and get hold of a Benq wide gamut monitor which I will install later today for test purposes. I'll report back later.

I made a simple test without using any photo. I just created a new document in sRGB color space in APhoto 2 and draw some rectangles on it. One in orange, one in green and one in purple. It renders completely different on both displays. Then I switched the Eizo internally to sRGB (and changed the Windows color management for the Eizo to sRGB as well) and compared both displays. Now, they are in line (almost). Which, again, leaves me to believe that something is broken here.

@debraspicher Sorry for the somewhat snarky comment at night time. Apparently I didn't explain the situation well enough. So, here is my second attempt: My computer runs Windows 10 (22H2) and features a AMD Radeon RX5700XT graphics adapter. Windows own color management is configured to use a bespoke AdobeRGB color profile for my first display (EIZO) and a standard sRGB profile for my second dsiplay (DELL). The profile has been created by me using Eizo's ColorNavigator7 and the X-Rite i1 Display pro colorimeter. The color space target was AdobeRGB. The Eizo display itself is set to AdobeRGB while there is no such setting for the Dell display (it is not capable of displaying anything beyond sRGB). I am aware the the Windows UI and plenty of apps are not color managed at all. But: Lightroom, DXO Photolab and the Affinity apps are color managed. Let us focus on them - and how colors are actually rendered in these apps on my systems. One example: Affinity Photo 2 is set to AdobeRGB as the standard color space. So any new document using the standard color space will show quite powerful colors on the Eizo display and "muted" colors on the Dell display. That is expected. However: If I create a new document within the sRGB color space in Affinity, I only expect a mild difference in rendering the image on both displays. As sRGB is the much smaller color space, the color managed Eizo should be able to reproduce the colors propperly. But that is not the case. They remain unnaturally bright and powerful as if they were still in AdobeRGB. I took a laptop of mine with a sRGB display and hold it next to the Dell display. The result: very minor differences in color rendering. So, I guess the Dell renders the sRGB colors decently. With the Eizo it is a different story - no matter what I set as the color space in Affinity. Always bright and oversaturated (skin tones are a joke). The same behaviour is visible with Lightroom and Photolab. It looks as if there is no color management at all. So, I'm lost.

Well, I doubt that the CS240(28990025)03AdobeRGB.icc is a standard profile shiped with the display instead of a bespoke one. And the last time I checked I was able to tell the difference between a tiny button on my monitor from an iStudio colorimeter. However, thanks for looking into the issue.

I couldn't agree more. But my displays are hardware calibrated on a regular base and use that specific profile. However, the contrast in colour between the two displays is so strong, that I have a hard time to believe that everything works according to plan. @v_kyr Thanks for that link. Looks like a long read...

Hi there! I've an issue with colour management on Windows 10 (22H2) that is not limited to Affinity. But in the Affinity Apps the issue is clearly visible - and drives me nuts! That is my setup: Windows 10 (22H2), AMD Radeon RX 5700 XT 1. display: EIZO CS240, runs in AdobeRGB mode 2. display: Dell U2417H, runs in sRGB mode Windows Color Management: Display 1 set to individual ICC profile (AdobeRGB, created by ColorNavigator7) Windows Color Management: Display 2 set to sRGB IEC61966-2.1 (see screenshots) One would expect that all colors that are within the sRGB range are displayed in the same way on both monitors (at least in color managed applications). But that is not the case. On the EIZO everything is saturated and bright, on the DELL all colors are dull and dimmed. As if Windows doesn't respect the ICC profiles. If I add a sRGB softproof layer in Affinity (1.10.6) in a AdobeRGB document the EIZO shows also no difference in color - which surprises me. Any ideas what I am doing wrong? Thanks, Volker

I did run some tests to verify what I claimed to have discovered... Well, it is complicated... Test A Started Firefox and XnViewMP, but not Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenshot in it. Result: Everyting is displayed correctly. Started Affinity and pasted screenshot via "new from clipboard" Result: The screenshot ist broken (by 3 pixels on the left that belong to the right side) Test B Started Firefox, XnViewMP and Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenshot in it. Result: Everything is displayed correctly. Pasted the same screenshot in Affinity via "new from clipboard". Result: The screenshot is broken. Test C As 1 - 6 in Test B. Created an empty document of 1920 x 1080 px and pasted the screenshot in it. Result: still broken. Test D Started Firefox, XnViewMP and Affinity. Grabbed a screenshot of the browser. Created an empty image in XnViewMP and pasted the screenhot in it. Copied within XnViewMP the pasted screenshot to the clipboard. Pasted the image in Affinity via "new from clipboard". Result: Image looks fine. So, somehow Affinity treats screenshots made by Windows differently from image data transfered via clipboard from other apps.

It is not just Affinity that is affected by the issue. I've just tried to paste a screenshot in a new image using XnViewMP with the same outcome: The three right-most pixel are placed on the left side of the pasted image. However, if I do a second screenshot it gets pasted correctly once in a while. Again, if I copy the incorrectly pasted image from XnViewMP and paste it in Affinity, the offset is gone... Unfortunately I can't reproduce this behaviour every single time. To me it looks very random. So it might be a issue with Windows? (in my case: Win10 22H2)

I am on 22H2 already... 😞

It seems that all the apps have lost steam... at least on my computer (Ryzen 7 3700, 32GB RAM, 1TB SSD, RX5700XT (8GB)). I've encountered a similar problem to @4dimage with the glyph browser, too. Without having measured it precisely, I'd say all V2.0 apps run half as fast as V1.x, sometimes even slower. Currently I prefer to use the older iterations of the Affinity apps if none of the newer features are required for the job. Let's hope, V2.0.1 will fix some of the issues.