Quite possibly, because I have been using Gnome with zero issues since 2020. Only now, in the last few days since it updated to 44, ia when I started having troubles.
The same exact behaviour on KDE… I’m at a loss…
It might be wise to read up about what RT’s Working Profile is and does
— and what Output Profile is and does: Color Management - RawPedia
1 Like
Ok, fair enough. I understand that
HOWEVER, why then, does not RT, when specifically instructed to use the system’s main colour profile, show the same image GIMP (or Firefox, or gthumb, or Gwenview) does when instructed to use the system’s main colour profile?
The only way I am able to make it do this if I enable soft-proofing, which, if I understand correctly, simply simulates what the image looks like on a system that uses said colour profile, but I already chose that behaviour when I told it in the preferences to use the system’s main profile.
This is blowing my mind!
System profile is generally your monitors (hopefully calibrated) ICC profile. Your workinf profile is separate and different profile.
I get that, and yes, the .icc profile is generated by DisplayCAL, following calibration. But you’re not answering my question.
Why doesn’t RT show the same image GIMP does when they’re both using the same .icc profile?
I don’t think you’ve given us enough information to adequately answer that question, hence the lack of answers.
You’d need to detail all the ICC profiles in your workflow for each application. If they’re all 100% the same and you load the same tiff into both RT and GIMP, then they should display the same.
1 Like
There are no “all profiles”. I use a single .icc profile in my workflow. I install it as a system profile and just enable “use main system profile” in all apps.
But… In RT I load a raw and in GIMP I load the tiff RT exports… Shouldn’t they still display the same? They used to, for the longest time…
If your Working profile is your systems’ calibrated monitor profile, that is not optimal.
Generally there are several profiles at work: input, working, display, and output.
You misunderstood, likely due to bad wording on my side.
My working profile is ProPhoto, display is the calibrated system profile from DisplayCal, output is sRGB and input… I’m not sure and I’m not at the computer right now.
Most probably it’s your camera profile (or the profile your input is encoded in, when editing JPG/TIFF/PNG and so on).
Oh yeah, I think this is set to auto.
Not necessarily:
What you see in RT is input → working → display profile.
What you see in GIMP is (input → working → export) → display.
Depending on the gamut of the export profile (e.g. much smaller than display one) and the mapping done by the CMS (perceptual, relative, etc.), you can get different looking images.
Hence the soft-proofing.
As I already mentioned, screen profiles can contain several different data. What kind of profile type did you choose while profiling with displaycal?
I tried both an xyx lut + matrix and curve + matrix. As far as my issue goes, there is no difference between the two.
Are the two renditions slightly different or wildly different?
They’re not wildly different, but quite noticeably so.
The one in RT is more vivid and saturated than the one in GIMP.
I just realised something and I suspect that might be the issued, although I don’t really understand why.
Apparently, a lot of these yellows, perhaps all those that all apps but RT fail to display are out of gamut.
maybe try lut only (without matrix), I think that’s possible, or the simplest profile single gamma + matrix.
might also be a rendering intent issue
Again:
“Depending on the gamut of the export profile (e.g. much smaller than display one) and the mapping done by the CMS (perceptual, relative, etc.), you can get different looking images.”
As an experiment, try exporting to a larger gamut, e.g. Rec2020 w/ 16 bits. And then, as @paperdigits says, experiment w/ rendering intent (gamut mapping).
As soon as you export those out of gamut colors to e.g. sRGB, that data is irreversibly lost (either clipped or squeezed/compressed depending on rendering intent), and cannot be brought back even if your display can do better.
2 Likes