rvst

Thanks @lacerto and @thomaso. You're both right about the ICC v2 vs v4 profiles. I'd come across this years ago and typically have always used v2 profiles. Color Navigator does default to v4 profiles, so I'll test with v2 profiles and see if this yields a better result. Perhaps the v4 profiles are not loading properly (the ones I generated with Displaycal were v2 profiles, which is maybe why they worked better). I'll probably still profile the Colour Navigator generated calibrations with Displaycal though, for the reasons below... My other reasons for dissing Colour Navigator: its lack of custom correction matrix support for colorimeters and the rather low number of readings it takes when it does a calibration: I find I have to make multiple calibrations to let it converge on a better solution. Displaycal just does an all round better job, although of course it can't do the hardware calibration, so can only be used to profile an existing Colour Navigator calibration. On the colorimeter support, I'm fortunate to own two calibration devices, one a i1p2 spectrophotometer and the other a i1d3 colorimeter. Typically, my use case has been to use the i1p2 to create a correction matrix for the i1d3 for the specific screen. You can't do this with Colour Navigator - it uses the device's builtin RG-Phospor spectral correction matrix, which gives a distinct cast and isn't very accurate. When I verify a calibration made with the i1d3 by using the i1p2, it's significantly off (dE > 3) - others have complained about this as well, I'm not the only one to note it. So I'm forced to use the i1p2 to actually do the calibration with Colour Navigator. But even then, it doesn't get anywhere close to as good a result as it should. For example, calibrating to D65 consistently yields something around 6650k. And so I have to zero in the target manually, which I can do fairly easily and get a dE of 0 or 0.1, which in itself is huge kudos to the monitor hardware, but it shouldn't be necessary - the monitor can get this level of accuracy, but the software can't. The software should just do more optimisations, with something like a time to accuracy slider to allow the user to control the number of iterations it does. Having to use the spectrophotometer to calibrate is non-optimal because it's not as good on the blacks as the colorimeter, it reads much slower and using it to calibrate just kills the lifetime of the light, which I'm reluctant to do since it's a really expensive device. In general, Colour Navigator just feels like a dumbed down piece of software. But, I can understand why this is - it probably best meets the needs of the majority of non-technical users and is good enough, but it's just a bit too dumbed down for me. No different to any of the other commercial calibration software: i1Profiler is worse in my opinion. I'm probably just used to the extremely high level of control that Displaycal gives me and I've been using it for a decade, so the switch to a less capable piece of software bugs me a bit.

Found the cause. There's something wrong with the ICC profiles generated by EIZO Colour Navigator. They're garbage. They weren't particularly accurate anyway: calibrating to D65 gave a white point after calibration consistently of around 6700k, so I had to make manual adjustments to get a more accurate calibration. After manual adjustment I got a perfect D65 whitepoint with delta-E of zero and a very good grey balance and gamma across the board, saved the profile to the hardware and then used Displaycal to profile the calibrated monitor and generate a new ICC profile. I'm now looking at the left hand monitor set to the native gamut profile with the same sRGB image up in Affinity Photo and a second view of that same image on the second monitor, this one set on a sRGB profile. There's zero visual difference between the two images, light years from what I was seeing previously. So, great monitor. Rubbish calibration software. I've yet to come across any commercial software that has even a tenth of the accuracy and capability of Displaycal.

Yes, correct. A colour managed sRGB file looks totally different on a calibrated wide gamut profile to the calibrated sRGB profile. The effect is as if I'm using a non-colour managed app to view an sRGB file on a wide-gamut monitor: more saturated colours than they should be. The monitor is hardware calibrated and there is an associated ICC profile loader that integrates with Color Navigator, the EIZO calibration software. When switching the monitor profile, this profile loader is responsible for loading the associated ICC profile. It looks to me like it's not working properly even though it seems to be associating the correct profile name. This is what I asserted to the EIZO tech too, who didn't agree. And yes, the problem stays after boot. This does happen with Windows, you're right. Windows colour management profile loading is a bit broken. That's why DisplayCal has their dispcalgui profile loader - I previously used DisplayCal with their profile loader on my old monitors.

This isn't an affinity related question per-se, but there are a lot of knowledgeable people on this forum and I'll probably get a more coherent answer here than elsewhere. I took delivery of two EIZO CS2740s yesterday. I calibrated two of the monitor custom settings to a 100cdm2 native gamut with a 2.2 gamma on one and to 100cdm2 sRGB profile with gamut clamping enabled on the other. These are the same settings as two of the factory calibrated and built-in profiles and the calibration result is visually indistinguishable from the factory calibrated profiles, so I know the calibrations are good. All the following comments apply both to my created profiles and to the in-built factory calibrated profiles. I have Colornavigator 7 installed and it appears to be working correctly. That is to say, when I change profiles on the monitor between Native, AdobeRGB and sRGB, the ICC profiles used by Windows for the display profile also change to the correct ICC profile that is associated with that monitor profile. This is done by the Colornavigator tray app. I use an NVidia RTX 3070. I've set it in Nvidia control panel to send 32 bit, 10 bits per pixel, full range RGB to the monitor. The monitor confirms on the OSD that this is the signal it's getting. There are no colour adjustments taking place in the Nvidia control panel of course. Color accuracy mode is set to "accurate", so it's not set to bypass the windows display colour transform. Now, I load up a file into affinity photo. The file is an RGBA/16 sRGB file. I've set the working space to sRGB, so all the colours in this file fit within the more limited sRGB colour space and it's not being converted into a wider gamut working space. I would reasonably expect that this file would look the same on my monitor, whether the monitor profile be set to native gamut, AdobeRGB or to sRGB gamut, assuming Windows colour management is working properly. I mean, this is the whole point behind a colour managed workflow, right? However, it doesn't. If I flip back and forth between the native gamut and sRGB gamut profiles on the monitor, there is a visually obvious difference where the native gamut profile on the monitor shows colours of the sRGB file in the sRGB working space as significantly more saturated than the sRGB profile on the monitor. The is the type of behaviour one would expect from an app that is not colour managed, where it stretches an sRGB gamut to fit the wider display gamut. I've even checked with other colour managed apps, not just Affinity Photo, and the behaviour is the same. The EIZO support person seems to think this is normal. Am I fundamentally misunderstanding something about colour management workflows here, or is this indeed unexpected behaviour? The EIZO tech's insistence is making me doubt myself now...

If your photos are too dark when you print them out, it usually means that the brightness on your screen is too high. This results in you getting something that looks "right" on the screen but too dark on the printed photo. General advice is to calibrate the monitor for 120cmd2 of brightness. I tend to calibrate mine at 100cdm2 as I find even 120cmd2 can result in prints that are a little too dark.

No. I'm looking to manually edit the mask in non-contiguous areas. One can unmask areas by painting with the paintbrush but not the reverse.

You might still be having trouble with the Windows profile loader and some application that is unloading the calibration on the fly. I have a hardware calibratable monitor. What I usually do is to use the vendor's tool to calibrate the monitor and write the calibration to its hardware LUT, then I then use Displaycal to profile the already calibrated monitor (discarding the profile generated by the vendor software). I use Displaycal's profile loader to load the display profile, so if it ever gets unloaded then Displaycal will automatically reload it. Suggest trying this. It would be a shame to get rid of the EIZO.

Oh, I installed the MSI long ago, when the test 2.03. installer was made available. You're replying to something from the beginning of November, but thanks for the heads up anyway. I was aware when unsandboxing it that it wasn't supported.

Use the MSI versions of the installers. These MSIX versions are broken. Several people have had the same error. They're also poor at integrating with 3rd party programs. The MSI installers will install Affinity as a "normal" Windows program and you won't have these errors.

You're using the wrong ICC profile for your Dell monitor. You can't use the sRGB IEC61966-2.1 profile, since it's not a display profile. Set the monitor hardware settings to sRGB, then use Displaycal to calibrate and profile your Dell monitor. The EIZO looks to be a custom calibration and profiling, since you noted that you used ColorNavigator and the filename seems to indicate a properly calibrated and profiled monitor.

It sounds like your calibration might have been reset by some other app and then when you activated the ICC profile after Affinity started, it reloaded the calibration as it should and you then see the correct colours. You might be running into problems with limitations of the Windows profile loader, which according to the developer of Displaycal, scales incorrectly and has poor 8-bit quantization. It's also possible to lose the calibration if some other process resets it as the Windows profile loader won't reload it. https://hub.displaycal.net/forums/topic/q-regarding-dc-profile-loader/#post-14013 This is the reason that Displaycal comes with its own profile loader, which you need to check when installing the display profile after calibrating and profiling your monitor. This solves the problem and will reapply the calibration as necessary. I've never seen any colour difference between Affinity Photo and any of my other colour managed apps (the images look identical when viewed side-by-side). I use the Displaycal profile loader. I find Displaycal does a better job than any of the commercial software I've used. Try switching to Displaycal and using their profile loader and see if the problem persists.

Cool, thanks - missed that one. I was on vacation so hadn't read that thread. Sounds like I'm not the only one who thinks this should be done

Many vendors offer a bug-tracking web page for adding bug reports and tracking bug resolution status. There are lots of open source packages that do this. I'd like to suggest that Affinity use a tool like this and make it available to the user base. I'd also like to suggest much more detailed release notes when new versions are released, listing exactly which bugs have been repaired in any given release. Obviously, one needs such a bug tracking system to enable such detailed release notes, since each bug needs a reference number and description. Release notes are currently VERY thin on detail.

@Patrick Connordo we need to uninstall the test MSI v2.0.3 variant before installing the v2.0.4 MSI or will it install over the test version cleanly?

There's a completely reworked and much cleaner variant of this code on my github, although to be fair, I'd suggest anyone just use the test 2.0.3 MSI installer instead. No reason to use the MSIX anymore.