various color management issues

[blitzgneisserin]

Hi,

this is just a rough sketch of a bug report, I will add pictures eventually, probably after LGM.

I don't know if you @hanatos remember that I reported a strange behavior with regard of color management years ago. I think I reported it on pixls.us. Basically all my photos that were produced with vkdt had a very slight green cast, the color cast was more visible in photos with lots of white-ish colors like winter landscapes, or lots of sky with clouds. Well and you could not reproduce the bug. Inside vkdt the photos looked ok, but the exported JPGs had a green cast.

I now found out the reason for this behavior: It was the way I calibrated my screen. I calibrated it like this: I have a Benq Photo screen with a rather large gamut, larger than AdobeRGB. I first calibrated it with the Benq hardware calibration tool on Windows, then I booted into Linux and only profiled it and used that second profile created with Displaycal for editing. With the Benq tool, I usually calibrated to 6500K and 120cd. The largest native color space of the screen can only be enabled during hardware calibration. However, during the profiling with Displaycal, the software showed that the screen had a green cast (the green bar was significantly longer than red and blue). The reason was visible after profiling: The largest native color space is larger than AdobeRGB especially in the green area.

A few weeks ago I was kind of too lazy to boot into Windows for the Benq tool and skipped hardware calibration, and only calibrated with Displaycal. This way I only have a color space that is like 98% AdobeRGB, and it is almost exactly overlapping with AdobeRGB. I adjusted the RGB-values of the screen with the OSD to 6500K and set brightness to 120cd, and then just profiled. And the result is: there is no more green cast in the JPGs produced by vkdt.

Note: RawTherapee and darktable did not have a problem with my "old" "hybrid" way of calibrating my screen.

I don't know the technical explanation for this behavior but probably you do.

I mean the actual problem is that the Benq tool does not really calibrate to 6500K, even if I set it to 6500K, I know that since a long time. Displaycal measures a different, more greenish white point after hardware calibration.

The second issue is that apparently vkdt cannot display JPGs with an embedded ICC-profile properly:

Most of the pics that are visible in the screen shot were produced with RawTherapee, and they carry the RT sRGB profile. The magenta thumb was produced by vkdt, however.

[hanatos]

heya, not sure i follow the colour management issues. there have been some changes wrt. colour handling, in particular with jpg and exr. could you try to load that jpg again? if it still doesn't work i'd be interested in a sample.

[blitzgneisserin]

Well the magenta cast in the JPEGs produced by vkdt is gone, but the photo is still too bright. The JPEGs produced with RawTherapee are still yellowish, although not quite as yellowish as before.

I think I explained that other issue well, you just have to believe that there is a green cast when I calibrate to the screen's native color space. Unfortunately it is complicated to make the necessary screenshots to prove it. I'd have to re-hardware-calibrate and profile the screen etc. Right now I don't have the time for that.

Here are two screenshots to prove the yellow cast and the brightness with JPEGs.

And here is a RawTherapee sample JPEG:

And this is the native color space of my screen:

I think I hardware-calibrated to 6000K that time though, not 6500, that's why the color space is slightly shifted to the right (red).

I think the green cast that Displaycal measures is the white point that is closer to green.

It's indeed a mysterious issue... at least for someone who doesn't know very much about the technology and color science. Kinda sounds like you are not interested but I think it's interesting and I would like to know the actual explanation and possible fix.

In theory one could make further tests. One could intentionally create a white point that is far from 6500K and then just profile and see what happens in vkdt. But none of us has the time for that right now I guess.

_4271090.tar.gz

[blitzgneisserin]

Just one pic that vkdt produced when I used the native color space of the screen. Unfortunately I cannot provide the screenshot of the photo (edited raw) opened in vkdt which looked ok.

This is an extreme example. Usually the green cast is hardly noticeable.

[hanatos]

just so i understand correctly:

"there is no more green cast in the JPGs produced by vkdt."

you are exporting these images and viewing them with something else? because the display profile plays absolutely no role in the code path during export. so you edit to taste with the display profile, then export and view with something else and then it looks different? maybe some other viewing software uses hardware vcgt as maybe loaded by dispwin? i could imagine that direct vulkan rendering bypasses that.

[blitzgneisserin]

just so i understand correctly:

you are exporting these images and viewing them with something else?

Yes, if I use the native color space of the screen, in every other color managed software the exported photos look different than in vkdt (Gwenview, geeqie, Firefox etc).

No, I didn't invent this just to annoy you.

[blitzgneisserin]

I could reproduce this on my laptop:

This is the color space of the built in laptop screen which has a significant blue cast:

Here the profile is compared with P3 D65, because I installed Displaycal as a Nix package and there is no other D65 profile installed to compare.

This is how the edit looks in vkdt:

And this is how it looks in Firefox:

And this is how the (raw) photo looks in vkdt, if I delete the screen profile file from the vkdt config directory:

[blitzgneisserin]

Everything is ok if I create a profile which includes calibration curves and the screen's white point is moved to D65.

[hanatos]

okay let's talk after LGM. good luck with your presentation!

[blitzgneisserin]

okay let's talk after LGM. good luck with your presentation!

thanks

[blitzgneisserin]

btw: https://shop.computec.de/de_AT/einzelhefte/einzelausgaben/linuxuser-epaper-06-2024/2154832.html

[hanatos]

okay i'm still not sure what i am looking for here. fwiw i tried to reproduce by using displaycal to produce two different profiles, one for D65 and one for D50 and then installed the icc for geeqie and vkdt to see any differences. in both cases i adjusted the monitor settings according to the initial white balance calibration step in displaycal.

this is the D50 profile with a display white point way off D65.

and this is how the images look, left is geeqie, right vkdt

this is not a great monitor, so the gamut isn't very different from sRGB, and if anything it's smaller in the blues. vkdt's render has more acuity probably because of how resampling is done and also geeqie works from an sRGB jpeg export so i would expect the slight bit of saturation clipping in the greens. it certainly doesn't show the gross white point shifts as your images do.

so i wonder how exactly did you setup your laptop monitor and how exactly did you create the profiles? if you could provide a step-by-step guide for a complete idiot i might have a chance to do the same?

[blitzgneisserin]

_2260400.tar.gz

I did nothing special with the laptop, the screen has a native blue cast. I just did a profiling without calibration, and set brightness to 120cd or so.

I think the important thing is that the screen's white point is far from D65, so either it's native white point is different, or you change the white point with the help of the buttons on the screen (OSD). Maybe if the screen has a built in "cool" white point setting/profile or so, choose that (in the OSD). I mean I think it's rather easy to see it if the screen has a color cast.

I also attached my raw, hoping that it's easier to reproduce the issue.

Also, I think it's important that you ignore the interactive adjustment thing (except for setting the brightness), after you started calibration. So you might as well switch off that step.

But I am going to try what you did right now. I suppose you set the white point to d50 with the help of Displaycal.

[hanatos]

did you run all of this on wayland/xwayland by any chance? it sounds an awful lot like missing calibration curves/VCGT which would be kinda by design on wayland. i still need to reproduce such a profile (provoking heavily non-identity calibration curves).

[blitzgneisserin]

I did test this on both Wayland and X11 and Xwayland, although I still need to test the new Wayland native appimages in this respect. But I did notice this bug years ago, and back then I did not play around with Wayland. I never really did use profiles with included calibration curves. So it is definitely not the missing curves. Of course it is a workaround to shift the color space with the help of calibration curves so that the white point is 6500 Kelvin.