Jump to content
Jim Weigang

AP double-application of monitor calibration

Recommended Posts

While working on photographs of the recent lunar eclipse, I noticed that Affinity Photo (v1.6.5.135) was displaying sRGB images on my calibrated monitor lighter than other applications (including Canon Digital Photo Professional, Paint Shop Pro, FastStone Image Viewer, JPEGview and IrfanView--all of which display images identically).

I'm using Windows 7 Pro x64 (updated thru Dec 2018). The monitor is a Dell P2615Q, calibrated with a GretagMacbeth i1 Pro. (.icc file and Color Management snaps attached.) I work exclusively in sRGB space using image files that either have an sRGB ICC profile or no profile embedded.

I first noticed the problem visually but have been able to measure it using screen capture (Windows PrtSc). It's easiest to observe by looking at a black & white step tablet image:

Step10small.jpg.275c12bce9e184d26da629455d70f693.jpg

(Step10.tif attached.) The numbers indicate the R G & B pixel values of each square. When I open this file in Affinity Photo and point the mouse to the various tone squares, the expected pixel values appear in the Info display on the right: 10, 20, etc. But the darkest non-zero shades are obviously lighter on the screen than they should be, and when I do a screen capture, paste the image into any editing program (including AP) and look at the pixel values of the squares displayed by AP, I see this:

  Square   R   G   B
      10      14 15 16     (should be 10 10 10)
      20      26 26 26
      30      34 35 35
      40      43 44 44
      etc.

(screen capture APwrongTones.png attached)

If I turn OFF monitor calibration by selecting sRGB IEC61966-2.1 as the default profile in Windows Color Management, then close & restart AP and open the step wedge, the tones are now correct: the step tablet looks the same way in AP that it does in every other program, and a screen capture of AP shows the expected values of RGB 10 10 10 in the 10 square, etc.

What seems to be happening is that, when I use a Windows monitor profile other than sRGB, Affinity transforms pixel values using that profile before putting them on screen. The problem is, Windows ALREADY performs this transformation down below Affinity, and the corrections needed to bring my monitor into sRGB calibration wind up being performed TWICE.

I think this behavior would be correct & necessary if I had calibrated my monitor to, say, Adobe RGB and I was displaying an sRGB image. (The transformation needed is monitor profile minus document profile.) But when a monitor profile is used only to bring a monitor into alignment with sRGB, programs need to leave pixel values alone when displaying sRGB images: a #10 gray pixel should be written to the screen as RGB 10 10 10, regardless of what the monitor .icc says. Windows will handle transforming that 10 10 10 to the RGB values which display as #10 gray on the monitor.

I discovered that, with the monitor once again calibrated, I could work around this problem by assigning the monitor profile to the current document in AP--this makes displayed pixel values become correct immediately--and then, when exporting the image, turn off the Embed ICC Profile option. (Annoying, but as a former Windows programmer, I'm used to having to work around bugs & feechurs in APIs.)

However, when I went to rework the raw .NEF images, I discovered that raw mode doesn't allow you to set the document color profile; you're stuck with the raw image's profile. The only way to get AP to display things correctly in raw mode is by turning off monitor calibration. I worked around THIS by preparing a draft image that looked the way I wanted it to (with monitor calibration on), then turning off calibration and adjusting the raw image in AP to match the draft image. I did this out of desperation for the eclipse photos, but I will definitely NOT be making this a part of my normal work flow!

It seems to me that something is missing from Windows monitor calibration via ICC profiles: a statement of intent as to what ICC standard you are calibrating your monitor TO. Absent that, what Affinity needs is a Preferences parameter that specifies the same thing. I would set my Monitor Calibration Intent to sRGB IEC61966-2.1, and AP would realize that no changes were needed when displaying sRGB images to the screen. Alternatively, an option to simply disable color management when writing to the screen would solve the problem for me, limited as I am to sRGB images.

Searching the forum for solutions to this problem, I note that I am not the only person struggling with "incorrect colors" in AP. The problems are often solved by having users set their monitor profile to sRGB--but they lose monitor calibration throughout Windows by doing so. One user discovered the apply-monitor-profile-to-document workaround and was told that he shouldn't do that (really, you shouldn't export an image with a monitor profile embedded). A lot of these problems would not occur if Affinity simply assumed that Windows monitors were sRGB, regardless of the monitor profile in use.

In summary:

      If a monitor has been calibrated to sRGB standard, a program should not alter pixel RGB values when writing sRGB images to the screen.

Affinity Photo is failing to abide by this rule.

I hope someone can look into this. I am gradually learning to use more & more of Affinity Photo, am appreciating what I can do with it, and hope I don't have to abandon it because it's too much work to work around monitor calibration double-application issues.

                                        Jim


P.S. The eclipse picture can be seen here:  https://jw9c.blogspot.com

APwrongTones.png

Step10.tif

Dell4K@2K_RGB-83-85-88_BC-33-100_2018-08-26.icc

ColorMgmtDevices.png

ColorMgmtAdvanced.png

Share this post


Link to post
Share on other sites

Hi @Jim Weigang, I’ve gone away to gather my thoughts on this and carried out some experiments. I’ll try and address everything as concisely as I can, so apologies if it becomes a wall of text.

Just to qualify everything that follows, I too calibrate and profile my monitor (a Dell UP3216Q) with an i1 Display Pro and displayCal, and for this research I’ve profiled both to my usual D65 100cd/m2 setup and to the specific sRGB preset provided by displayCal.

Quote

While working on photographs of the recent lunar eclipse, I noticed that Affinity Photo (v1.6.5.135) was displaying sRGB images on my calibrated monitor lighter than other applications (including Canon Digital Photo Professional, Paint Shop Pro, FastStone Image Viewer, JPEGview and IrfanView--all of which display images identically).

I’m not sure if any of these applications are colour managed by default. I’m aware Paint Shop Pro has optional colour management but from reading the documentation it looks like it has to be specifically enabled. FastStone Image Viewer and Irfanview have a CMS plugin but it needs to be specifically enabled and only applies to JPEG and TIFF formats with embedded ICC profiles. From reading around on forums it seems to be dubious as to whether the colour management is being applied correctly (update: I did some testing and could not get it to work correctly at all).

Quote

I first noticed the problem visually but have been able to measure it using screen capture (Windows PrtSc). It's easiest to observe by looking at a black & white step tablet image:

(Step10.tif attached.) The numbers indicate the R G & B pixel values of each square. When I open this file in Affinity Photo and point the mouse to the various tone squares, the expected pixel values appear in the Info display on the right: 10, 20, etc. But the darkest non-zero shades are obviously lighter on the screen than they should be, and when I do a screen capture, paste the image into any editing program (including AP) and look at the pixel values of the squares displayed by AP, I see this:

Unfortunately, trying to measure any issues this way is flawed: I would actually expect a screen grab to have different values, since the document view undergoes a transform from document to display profile. This is compounded on Windows where it doesn’t embed the image data or resulting image file with the display profile—on macOS for example, the display profile is embedded into the resulting PNG, which allows colour managed applications to display the screen grab accurately. On Windows, when you load that screen grab image back into Photo (and indeed other software) it will assume an sRGB colour profile, which is wrong.

 

Quote

If I turn OFF monitor calibration by selecting sRGB IEC61966-2.1 as the default profile in Windows Color Management, then close & restart AP and open the step wedge, the tones are now correct: the step tablet looks the same way in AP that it does in every other program, and a screen capture of AP shows the expected values of RGB 10 10 10 in the 10 square, etc.

This would indeed suggest to me that other software is not colour managed.

We’ve compared Affinity Photo and Photoshop when it comes to taking a screen grab of your luminance steps image and both behave exactly the same way: the canvas or document “view” is colour managed (document profile to display profile), and so the screen grab reflects the change in values when it’s loaded back in (with an assumed sRGB colour profile) and examined with the colour picker. Just to clarify here: we produced screen grabs of the Step10.tif image you provided in both Affinity Photo and Photoshop then brought the resulting image files back in and colour picked them. If there is indeed an issue with how Affinity Photo is handling colour management, then Photoshop also appears to be doing the same thing. However, the key difference with both these apps compared to the others you’ve listed is that we know they colour manage the image/document view by default.

 

Quote

What seems to be happening is that, when I use a Windows display profile other than sRGB, Affinity transforms pixel values using that profile before putting them on screen.

That definitely should be happening! :) (Otherwise it would imply colour management is broken). However…

 

Quote

The problem is, Windows ALREADY performs this transformation down below Affinity, and the corrections needed to bring my monitor into sRGB calibration wind up being performed TWICE.

This should not be happening, and from testing I don’t believe it’s the case (again, cross-referenced with Photoshop, we see the same results). Unless something has changed, which of course is always a possibility (not ruling that out at all), the document view should be untouched by Windows’s colour management. I believe it may colour manage the UI (which is Direct2D) but not the document view.

 

Quote

I think this behavior would be correct & necessary if I had calibrated my monitor to, say, Adobe RGB and I was displaying an sRGB image. (The transformation needed is monitor profile minus document profile.) But when a monitor profile is used only to bring a monitor into alignment with sRGB, programs need to leave pixel values alone when displaying sRGB images: a #10 gray pixel should be written to the screen as RGB 10 10 10, regardless of what the monitor .icc says. Windows will handle transforming that 10 10 10 to the RGB values which display as #10 gray on the monitor.

Again, I don’t believe this is the correct approach because Windows should not be colour managing the document view: it’s up to the colour management within Affinity Photo to translate values from the document profile to the display profile so that they display correctly.

 

Quote

I discovered that, with the monitor once again calibrated, I could work around this problem by assigning the monitor profile to the current document in AP--this makes displayed pixel values become correct immediately--and then, when exporting the image, turn off the Embed ICC Profile option. (Annoying, but as a former Windows programmer, I'm used to having to work around bugs & feechurs in APIs.)

That’s how I would expect to correct a screen grab when it has been incorrectly assigned an sRGB profile. You would assign the display profile, then you can convert to sRGB—I wouldn’t leave the document in that display profile and disable embedding the ICC profile on export. Always convert it to a standard document profile.

 

Quote

However, when I went to rework the raw .NEF images, I discovered that raw mode doesn't allow you to set the document color profile; you're stuck with the raw image's profile. The only way to get AP to display things correctly in raw mode is by turning off monitor calibration. I worked around THIS by preparing a draft image that looked the way I wanted it to (with monitor calibration on), then turning off calibration and adjusting the raw image in AP to match the draft image. I did this out of desperation for the eclipse photos, but I will definitely NOT be making this a part of my normal work flow!

Interesting fact: the Develop Persona is bounded to a linear sRGB document profile in 1.6 (it’s displayed as RAW but is actually linear sRGB)—it’s a known limitation and in the 1.7 public beta (which you can download) the document profile will always change to reflect the output profile (e.g. Adobe RGB/ROMM RGB). However, you would never be stuck with the RAW image’s profile—by that, do you mean the camera’s colour space? RAW software should always convert from the camera’s colour space to a known colour space. However, the same process applies regarding colour management: your final document view goes from the document profile (in this case, sRGB) to the display profile so that the displayed result is accurate.

 

Quote

It seems to me that something is missing from Windows monitor calibration via ICC profiles: a statement of intent as to what ICC standard you are calibrating your monitor TO. Absent that, what Affinity needs is a Preferences parameter that specifies the same thing. I would set my Monitor Calibration Intent to sRGB IEC61966-2.1, and AP would realize that no changes were needed when displaying sRGB images to the screen. Alternatively, an option to simply disable color management when writing to the screen would solve the problem for me, limited as I am to sRGB images.

I don’t believe this is a viable idea: even if you profile a display to sRGB, you still need to colour manage between the document profile and the display profile because there will be corrections that need to be made. That’s the point of profiling your display as opposed to just calibrating it. If your physical calibration using the monitor’s brightness/contrast and colour settings is close enough to sRGB, and you do not want a colour managed workflow, then you may as well set your Windows display profile to sRGB. That way, when you work in sRGB documents, the numbers are going straight to the screen without any modification. As it stands, though, Affinity Photo is colour managing with your custom display profile to produce the most accurate result—which will of course look different to apps that are not colour managed.

 

Quote

Searching the forum for solutions to this problem, I note that I am not the only person struggling with "incorrect colors" in AP. The problems are often solved by having users set their monitor profile to sRGB--but they lose monitor calibration throughout Windows by doing so.

I believe this issue is more related to certain display profiles being corrupt and incompatible with the way colour management works on the Windows versions of the Affinity apps. I think it was certain Samsung and Dell profiles that would cause issues like whites rendering as an orange/cream tone, and short of having users purchase a colorimeter so they could produce accurate custom profiles, the solution was to temporarily switch to the sRGB device profile.

 

Quote

A lot of these problems would not occur if Affinity simply assumed that Windows monitors were sRGB, regardless of the monitor profile in use.

That sounds like a really questionable idea—a major feature of a professional image editing application should be to perform accurate colour management between the document profile (especially wide colour spaces) and the display profile. My day-to-day experience is with the macOS version but I also use it on Windows, and certainly from version 1.6 I haven’t had any issues with colour management when using custom display profiles and working on wide gamut displays.

 

Quote

If a monitor has been calibrated to sRGB standard, a program should not alter pixel RGB values when writing sRGB images to the screen.

I’ve noticed the phrase calibrated in a few of your paragraphs: what is your expectation of calibration versus profiling? Again, my view is contrary to the above if we’re talking about profiling: an application should transform pixel values between the source profile (e.g. the image or document) and the output profile (the display profile), even if the source profile is sRGB and the display is calibrated and profiled to sRGB chromaticity values. Physical calibration can get you so far, but profiling accounts for that last 10%—so for the most accurate on-screen result, those sRGB document values must still be transformed using the display profile.

 

It’s possible this issue comes down to perception about what is right and wrong: we cannot rely on a screen grab to illustrate the issue because the colour values are different—they should be, because the whole point of colour management is to translate the document profile’s values to the screen correctly. So the issue is that the darkest shades appear lighter than they should—but compared to what? If you have profiled your display and the results from the colorimeter are accurate, Affinity Photo should be successfully colour managing between the document profile and your custom monitor profile to produce an accurate representation on your display.

 

Have you tried opening Step10.tif in other apps that you know for sure are colour managed? (e.g. Photoshop)—having done so here on my Windows 10 installation, Step10.tif looks identical between both Photoshop and Affinity Photo. When I'm back in the office I can do some more research on other Windows apps that are colour managed to suggest some ideas.

 

There’s a really easy way to tell if applications are colour managed. Go to this website: http://www.gballard.net/photoshop/pdi_download/#downloads and download the PDI Target(WhackedRGB) ZIP file. You’ll find a JPEG in that ZIP called PDI_Target_WhackedRGB.jpg — open it in various applications. If the skin tones and colours look correct, that application is colour managing from the document profile (WhackedRGB.icc) to the display profile correctly. If the image has a heavy blue cast, the application is not colour managed. I tried this with Irfanview, and enabling its CMS made no difference—I simply couldn't get it to display correctly. FastStone viewer did display it correctly because the CMS was enabled by default—it’s worth checking the Preferences on your version to see if it’s enabled? I don’t have Paint Shop Pro or the Canon software to test with unfortunately and I’m burning through my mobile broadband at the moment by tethering! The image does of course display correctly on Affinity Photo.

Also, is there any way you could share your profiling workflow? I use displayCal rather than the i1 profiler software as I’ve found it to be more accurate and you have more control over how the ICC profile is generated (although nowadays software is much better at handling different profile types). I would be really interested to know what software and settings you use.

I hope to hear back from you so we can try and address this, and I’m always eager to hear any more thoughts you have about the whole process. I would urge you to experiment with other colour managed applications and see if you find the same results as Affinity Photo. Thank you for reading!


More than 200 Affinity Photo Video Tutorials - Affinity Photo for iPad Tutorials

Looking for a manual/documentation? Check affinity.help for online help!

@JamesR_Affinity for tutorial sneak peeks and more

Share this post


Link to post
Share on other sites

James--

Thanks for reading my posting and replying--and for the pointers to the Whacked test image and DisplayCAL. I am continuing to study Affinity and other applications' behavior and will post more when I have things straight(er) in mind.

One thing has become clear, though: I was wrong in thinking that AP is applying the display profile twice--that's definitely NOT what's happening. Because that mistake is embedded in the subject title, I'd like to retire this thread and start a new one with a more appropriate title. Affinity's display behavior matches current versions of Chrome and Firefox at their default settings (though not the way I configure them), and I suspect Photoshop's as well (don't have; can't test), so I'm not sure in which subforum the new thread belongs--question, feature request or bug report? (If a behavior makes a program unsuitable for image preparation but is endemic across part of the industry, does that mean the behavior isn't a bug?)

I'll make one more posting here linking to the new thread when I start it.

                                        Jim


P.S. Could you send me the DisplayCAL profile you use? I'd like to make sure I'm not just dealing with some flaw in my spectrometer. The profile I produced last night is attached.

P2715Q #1 2019-02-11 04-55 2.2 F-S XYZLUT+MTX.zip

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×