owenr

RGB colour management anomalies

14 posts in this topic

The following regards working with RGB documents in the Affinity apps (including Photo 1.6 beta 1) on macOS, and you’ll need to use docs with profiles other than sRGB to see what I mean. Also, the effect will be subtle unless you view on a wide gamut display.

 

Something is odd about colour management: the Colour Chooser window, the Colour panel, the foreground and background wells of the Swatches panel, and the Navigator panel, appear to be displaying colours not as they are displayed in the document, but instead as if soft-proofed with sRGB profile. Ironically, soft-proofing an actual document with sRGB is broken and makes no change to the displayed image (verifiable by setting the soft proof adjustment layer’s blending mode to Difference and getting a black result). And to top it off, these panels display further adjusted colours when undocked from the side of the window.

 

I will post screenshots if required.

 

 

Share this post


Link to post
Share on other sites
On 22/07/2017 at 6:04 PM, owenr said:

The following regards working with RGB documents in the Affinity apps (including Photo 1.6 beta 1) on macOS, and you’ll need to use docs with profiles other than sRGB to see what I mean. Also, the effect will be subtle unless you view on a wide gamut display.

 

Something is odd about colour management: the Colour Chooser window, the Colour panel, the foreground and background wells of the Swatches panel, and the Navigator panel, appear to be displaying colours not as they are displayed in the document, but instead as if soft-proofed with sRGB profile. Ironically, soft-proofing an actual document with sRGB is broken and makes no change to the displayed image (verifiable by setting the soft proof adjustment layer’s blending mode to Difference and getting a black result). And to top it off, these panels display further adjusted colours when undocked from the side of the window.

 

I will post screenshots if required.

 

 

 

Hi Owen, apologies that your post has gone unanswered - please could I ask for a bit more information from you? Are you able to provide document details such as the colour space you're editing in, and also colour format? (8/16/32-bit) Additionally, have you profiled your monitor or are you using the default iMac calibration profile?

 

The only way I can reproduce what you're experiencing is if I'm working in 32-bit - in this case, the navigator preview will always be managed by the display profile transform, and so accounts for the difference if you're previewing your actual document in linear light or through OpenColorIO.

 

With regards the soft proofing, if you enable gamut check, do you get clear out of gamut warning areas on your document?

 

Look forward to your reply and hope we can solve this - if you're able to provide screenshots that would be a great help too. Thanks!

Chris B likes this

More than 200 Affinity Photo Video Tutorials - New set of Affinity Photo for iPad Tutorials

@JamesR_Affinity for tutorial sneak peeks and more

Shooting Series for practical photography techniques - 500px for photography edited in Affinity Photo

Share this post


Link to post
Share on other sites

IMPORTANT: Please discard the zip that was attached. It contained at least one incorrect file. I will provide a new zip soon. Sorry for inconvenience

 

 

Hi James, thanks for the reply.

 

The attached zip contains a contrived example using 16 bpc RGB and various document profiles. The problems I described earlier happen with the 2017 iMac 5K default display profile (close to P3) or a calibrated profile, so I’ve used the default profile for this. The documents and other files such as screenshots (with embedded display profile) are in the attached zip, but first an explanation:

 

“1 sRGB.afdesign” is an initial doc with sRGB profile. The six rectangles are filled with 100% red, blue, green, yellow, cyan and magenta in the doc colour space.

“2 Adobe.afdesign” is the first doc converted to Adobe RGB space (the initial set of rectangles is displayed no differently, as expected when converting to a wider gamut), and it has an additional set of rectangles containing 100% R, B, G, Y, C And M in the doc colour space. There is also a sRGB soft proof adjustment layer at the top of the stack to toggle on/off.

“3 iMac.afdesign” is the second doc converted to iMac space, and it has an additional set of rectangles containing R, B, G, Y, C And M in the doc colour space. I realise that one doesn’t normally produce documents with the display profile, but it is to provide further evidence of the sRGB proofing problems.

 

The document view in Affinity shows clear differences between the colours created in each colour space, as it should, but the Navigator panel, Layers panel thumbnails and Colour panel display the colours almost identically and very close to being a conversion from document space to sRGB to display space.

 

The TIFF files are for testing soft proofing in Preview or other colour-managed apps, and they are flat exports of the afdesign docs without the soft proofing layer enabled.

 

The screenshots of Affinity Designer show the Studio panels displaying colours as if soft-proofed with sRGB profile, and that an sRGB soft proof adjustment layer fails to adjust the displayed colours. The out-of-gamut option does work when enabled, presenting out of gamut pixels as grey.

 

The screenshots of Preview displaying the TIFFs, with and without sRGB soft proofing, demonstrate the expected change to the displayed image when soft proofing is enabled: i.e. the displayed image contains no colours outside the proofing profile’s gamut.

 

Edited by owenr
Incorrect file was in zip. Please discard the zip if you downloaded. I will provide corrected zip

Share this post


Link to post
Share on other sites

Hello owenr,

Hello James Ritson,

 

this seems an issue, that I also experienced in pro-3D apps using OCIO on Mac.

It is only visible on Wide-Gamut Displays that are capable to display color spaces larger than sRGB.

And it most likely has to do with the different color managements on the OS level.

On Windows, an untagged image i.e. will automatically be treated as sRGB image, whereas on macOS an untagged image will be translated into the display's gamut.

In example, maximum red in an untagged image on Windows will be translated into sRGB 255,0,0 and displayed as such (even on Wide Gamut displays).

On a Mac with Wide Gamut display, this red will be translated into 255,0,0 of the monitor's gamut, resulting in an extremely saturated red.

Actually, this seems a more correct solution, as color values only make sense in correlation with a definition of an appropriate color space.

 

Attached is an untagged (unprofiled) png file, which can be used to verify this issue when examined on a Wide Gamut display, such as a professional color station display or a hardware calibrated proof monitor and with AF set to a larger than sRGB color space (i.e. Adobe RGB, ProPhoto RGB, eci-RGB or the actual Monitor profile).

On opening, AF will automatically assign the RGB working space set in Preferences (which is not so good btw).

The colors will be transferred into this gamut which will result in Affinity Photo to display colors with a more or less huge color shift (esp. in the red, green and cyan fields) between the actual document's display and i.e. the display within the Navigator panel. The larger the Working RGB the larger the difference will be.

The document's display area obviously transfers this file into the Working RGB. Navigator seems to display as sRGB file.

 

Unfortunately, a screenshot will not display the different appearances in Affinity Photo, as OSX screenshot app does apply sRGB which equalizes any differences.

(This insufficient color management within AF let me actually revert to PS).

 

colortest.png

Share this post


Link to post
Share on other sites
12 hours ago, Roger Simon said:

Unfortunately, a screenshot will not display the different appearances in Affinity Photo, as OSX screenshot app does apply sRGB which equalizes any differences.

Hi Roger. Thanks for joining the thread. Sorry to contradict you, but a Mac screenshot taken with Shift-Cmd-3 or Shift-Cmd-4 does not apply sRGB; it has the pixel values in the display space and has the display profile embedded. (Screenshots taken by Grab utility incorrectly have sRGB profile embedded regardless of the display profile.) Download my zip and you'll see that my screenshots have embedded iMac profile and they do demonstrate the problematic colour management of Affinity apps.

 

12 hours ago, Roger Simon said:

On Windows, an untagged image i.e. will automatically be treated as sRGB image, whereas on macOS an untagged image will be translated into the display's gamut.

 

On a Mac, the presentation of an untagged image is determined by the app. Some apps, such as Safari, will assume sRGB and present the image after converting from sRGB to the display space. Some apps may present the untagged image with no conversion, as if the image had the display's profile. Some apps may present the untagged image as having some  default colour space other than sRGB.

 

 

 

Share this post


Link to post
Share on other sites

Hello owenr,

 

thank you for clearing up this issue with the screen grabs.

Indeed, I used the grab tool for a screen grab to show off the differences between the file representation within the image area and the Navigator panel, which unfortunately resulted in equal Color in the screen grab.

(Would instantly repeat this process with your solution, but out of the blue my Mac came up with a System error this morning and I'm actually trying to get the system up and running for hours now without success so far and the iPad doesn't help much in that regard).

 

Anyway, Affinity Photo -imo- does 2 things wrong:

- it automatically assigns the Working- RGB to an untagged Image file during opening and

- it shows off 2 different representations of this file: with Working-RGB in the file Display area and obviosly converted to sRGB in the Navigator panel

A color aware app shouldn't automatically assign profiles to files, it should at least warn the User and prompt for an appropriate action.

Of course it should also show the file consistently and reliably within the app.

 

(Excuse me when I withdraw from this thread now, writing on an iPad is just too time consuming (esp. on non-US eng devices) and I need to continue trying to fix my Mac :-|

Hopefully I can re-join later)

Share this post


Link to post
Share on other sites

(15 hrs later, system is up and running…)

 

Hello owenr,

 

can verify your issue, had downloaded your files.

Though the differences on your system are pretty small, they are certainly disturbing.

My monitor shows 100% of sRGB and nearly 99% of AdobeRGB, therefore the differences are much more evident here.

Nevertheless, screen grabs don't show that, neither when taken via Screen Grap App nor by keyboard shortcuts.

Both variations result in visually pretty close colors, no matter if sRGB or the Monitor Profile is added.

OSX Digital Color Meter gives me onscreen the following native values (only for the 1st row, left=image display, right=Navigator panel), when I choose my Monitor's profile as Working RGB to maximise this issue:

255    0    0    >>>    215    61    35    

0    255    0    >>>    150    244    65    

0    0    255    >>>    42    66    247    

255    255    255    >>>    255    255    255

 

On the image display area, 255-0-0 i.e. is pushed to the maximum red value of my monitor's Gamut, what is to expect. Navigator panel on the other side shows just a somewhat maximum sRGB red instead.

Share this post


Link to post
Share on other sites

The differences in blue are small on my system, but differences in green and especially red are far from small. These differences are captured by my screenshots and, on my system, they look exactly like the  display that has been captured. I'm puzzled by you saying that screenshots don't show the differences, when my experience is to the contrary. I suspect you must be viewing screenshots in an app that is converting images to a narrow gamut such as sRGB before displaying them.

 

 

Share this post


Link to post
Share on other sites

Hello owenr,

 

again, you're right: as I could verify a similar issue that I have within a 3D DCC app by simply opening the screenshots via QuickLook or Preview.app, I just used those while checking this issue here with Affinity Photo.

Now, in PS the differences are there.

I'm attaching a screen grab which contains my Monitor's Profile and therefore the maximum discrepancy between Image Display Area and Navigator panel, that I experience here.

As one can see, all colors are way off, only the greyscale patterns are close to each other.

 

 

 

Screenshot-AF.jpg

owenr likes this

Share this post


Link to post
Share on other sites
7 minutes ago, Roger Simon said:

As one can see, all colors are way off, only the greyscale patterns are close to each other.

 

Thanks  :)

 

I've posted a separate bug report about the Affinity QuickLook extension having the same problem as the Studio panels, i.e. rendering an sRGB conversion.

Share this post


Link to post
Share on other sites

Hello guys,

although in the meantime I read way more about color management and my knowledge is now higher, I still want to take a deeper look at this topic as now Im in a rush, but you guys think that I might be seeing the same problem? (I also use a wide gamut monitor)

 

Thanks in advance,

-JA

Share this post


Link to post
Share on other sites

Hi Jose,

 

I saw your thread concerning Lightroom and Affinity rendering a file differently on Windows. Colour management is quite straightforward with macOS, and the main document view of Affinity apps seems to be correct on my Mac with a wide gamut display - certainly presenting the same colours from a file as other colour managed apps. I vaguely remember a thread where a Serif employee stated that Affinity apps do something differently to some other apps on Windows when a wide gamut display is involved.

 

 

 

Jose A likes this

Share this post


Link to post
Share on other sites
On 15/08/2017 at 2:11 PM, James Ritson said:

Look forward to your reply and hope we can solve this - if you're able to provide screenshots that would be a great help too. Thanks!

 

Hi @James Ritson, it's 4 weeks since I replied to you (see posts above). Hoping to hear from you soon.

 

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