Processing a photo for PlayRaw I encountered an issue which I am not sure how to handle.
The photo on the left is how I intended it to be, the one on the right is how it came out:
I processed the image using the color profile of my monitor and generated the output with the standard sRGB profile. As a result, being certain colors out of gamut, the yellows slightly shifted towards an orange tone.
How can one guarantee that the colors are displayed properly ?
Should the color profile of the monitor be embedded in the final image or rather the colors out of gamut be corrected ?
Speaking of pictures for the web ⊠would you correct the colors before the final export or you simply suggest to apply the profile and let it âwork its magicâ ?
If you working profile is a wider gamut than the output profile, e.g. you are working in ProPhoto or similar, Iâd suggest you use the softproof feature with sRGB select to see how it looks.
No matter where in the processing pipeline, the following needs to hold true: The embedded/assigned profile needs to accurately describe the gamut represented in the image.
At output, if you really are âassigningâ a different profile to an image that was previously converted to a working profile, for internal use by RT, the output file wonât be correctly described with respect to its gamut. It needs to be converted to conform to that output profile prior to saving. RT is converting to the display profile for displaying; Iâd bet the saved image is being viewed with the wrong profile, assigned at output.
@Elle schooled me here, in the difference between âassignâ and âconvertâ.
I work in ProPhoto. I donât see any difference with sofproofing on / off on my monitor (with the monitor profile). I observe the color shift though if I set the profile to sRGB or None (bottom bar):
I defined the color profile of the monitor in the preferences and all the image viewers I use are colored managed. I work in ProPhoto and do notice the problem during export assigning the sRBG profile:
Do you actually see any color difference in my first post ?
The pictures are obtained with the output profile set to that one of the monitor and RTv2_sRGB.
See the previous post: did I assign or convert ? Considering the profile is applied at the output it should be a conversion. Otherwise I misunderstood the purpose of that option âŠ
It should be left as RTv2_sRGB, as the image will then be displaying in the sRGB colorspace (i.e. what your monitor is set to). Your monitor profile is used to correct the colors that it displays.
Your output colorspace shouldnât matter so long as the device/software being used to view it has color management. The colorspace you define for the output will be picked up by the device/software, and then be transformed to sRGB.
The Photos app is not colour-managed (it doesnât consider the monitor profile you set in your Windows colour management, and it assumes your monitor covers sRGB exactly 100%, which is a dangerous assumption). Windows Photo Viewer, OTOH, is colour-managed (but it doesnât like LUT-type monitor profiles) â itâs not available on Windows 10 by default, though .
I am on W10, but I never used those MS photos stuff as I am not at all confident in them. Furthermore, it is a real pain for me to use that.
What I can say is:
Itâs pretty easy to test the colour management of a program by using an image with a manipulated ICC profile embedded in it (this checks one aspect of colour management) and by using a monitor profile which differs considerably from your own monitor (ArgyllCMS and DisplayCal allow the creation of such profiles).
@sankos the photo app in windows 10 is color managed as said by @gaaned92, I cross-checked with XnViewMP: same behaviour.
XnView settings:
@sankos thanks, I visit later the link, perhaps it helps the troubleshooting âŠ
EDIT: PDI target test PASSED.
Let me summarize the evidence once more.
I created in RT two versions of the same file, the first with RTv2_sRGB as output color profile, and the second with sRGB Color Space profile as output color profile (which happens to be IEC61966-2.1).
Everything else being equal (color management, monitor profile and rendering intent included) I should not see a significant difference in color rendition, but I do see it (whatever is the software).
EDIT: I just realized I never showed how bad is the out of gamut indication:
Soft proofing is off, so the indication refers to the monitor itself, not the output profile.
Are you saying that RTv2_sRGB has out-of-gamut issues while sRGB Color Space doesnât? What I know about sRGB profiles is that there are many of them and that all of them are different interpretations of the sRGB ICC spec. Different yet similar. RT also has a RTv4_sRGB profile; give that a go as well. However, I donât know why they would be as different as you have indicated. Could you export one of each so that I could take a look? Thanks.
I just tested all the sRGB profiles my RT 5.5 has access to, and my colour-managed viewers donât show any apparent differences in the output (thatâs on a wide gamut, profiled monitor).
OK, so what youâve confirmed is that both Photos and XnViewMP can read the embedded profile. The other part of the colour management test is with the monitor profile. If you used e.g. a wide gamut monitor profile as your system profile while your actual monitor is close to sRGB (like your Dell appears to be), then youâd see a difference between XnViewMP and the Photos app because the former respects the selected monitor profile, and the latter doesnât.
Anyway, this doesnât help much with your OP issue â I just wanted to point out the importance of using a properly colour-managed and set-up photo viewer when troubleshooting issues of this kind.
No @afre, Iâm only saying they look different and sRGB produces color equal to those I see in RT right before exporting.
RVTv2_sRGB (version 4 = same result)
sRGB Color Space Profile
We likely have different monitors, so I canât tell how they handle colors out of gamut with respect to one another. To me the two images above are quite different.
I assume (correct me if I am wrong) that if the difference resides in the color rendering of the monitor, than one should be able to pick a yellow-tone from the same spot of the two pictures and read equal RGB values ⊠otherwise the difference is real and baked in the files rather than appearent, and one can or canât see a relevant difference depending on the monitor gamutâs coverage.
The comparsion here below shows the difference in terms of RGB values for the same pixel using the two profiles above (in the same order):
Considering the profile is applied at the output it should be a conversion. Otherwise I misunderstood the purpose of that option âŠ
