- This topic has 63 replies, 5 voices, and was last updated 9 months, 3 weeks ago by
.
-
Posts
-
BTW if your LCD contrast ratio is unrealisitcally large, it’s possible that there is dynamic contrast used, which is bad news for color critical work and the profiling process. If DR can’t be defeated, you will at best be able to use a minimal testchart and gamma+matrix color type.
That’s odd to me because its straight from DisplayCAL, I didnt do anything to that profile. If i could figure out what command line parameters DisplayCAL used with colprof, it would solve the mystery.
I measured 11107 points because I was going to run it overnight anyways and so i just chose the highest quality.BTW if your LCD contrast ratio is unrealisitcally large, it’s possible that there is dynamic contrast used, which is bad news for color critical work and the profiling process. If DR can’t be defeated, you will at best be able to use a minimal testchart and gamma+matrix color type.
There is no dynamic contrast, dynamic dimming, or any other adaptive backlight technologies in use. It’s a very plain, albeit high quality IPS LCD panel.
https://www.panelook.com/LP156WFE-SPD4_LG_Display_15.6_LCM_overview_59026.htmlHere’s a Matrix + VCGT profile computed from your 11000 points.
The VCGT brightens the image to gamma 2.2 and removes the… green cast. I known you mentioned the screen has a red/orange cast, but your colorimeter sees it green. Not uncommon if not using the right spectral correction.
I was finally able to manually replicate the profile generated by colprof that KDE doesn’t like, here is the command line I used for it:
./Argyll_V3.4.0/bin/colprof -qh -aX -S ../../.local/share/icc/sRGB-elle-V2-labl.icc Monitor_1_\#1_2025-08-01_07-32_L_S_XYZLUT+MTXThe culprit turned out to be gamut mapping, which is odd because I didn’t enable any kind of gamut mapping in DisplayCAL.
Here’s a Matrix + VCGT profile computed from your 11000 points.
The VCGT brightens the image to gamma 2.2 and removes the… green cast. I known you mentioned the screen has a red/orange cast, but your colorimeter sees it green. Not uncommon if not using the right spectral correction.
I think it’s green relative to my display’s very warm white point. I keep calling it orange, but since i had DisplayCAL set to “as measured” for the whitepoint, I think it’s just snapping it to the closest point on the daylight locus which happens to be less green.
I’ve been comparing my final ICC profile generated with the one you sent me, and whatever software you used resulted in a profile with some small but interesting differences that i’m too inexperienced to put into words. I’m going to look into different programs using the LCMS system. Out of curiosity, what software did you use to make that ICC profile?
KDE really tries to use XYZ LUT profiles but the less uniform they are, the stranger the results. I’m just going to use a 3xCurve with a matrix in the XYZ connection space for now
ColourSpace specializes in making 1D/3D LUTs, but it doesn’t deal with ICC profiles directly.
Looking at your latest profile, I notice it corrects slightly less for the green tint (hard to say which one is more accurate without post measuring). It is also very noisy, see attached 3D view. When using an image to view the effect, notice the artifacts in the dark blues.
This is caused by noise in the measurements, which is clearly visible in the darker tones when plotting the RGB balance.
Yes, the noise is absolutely a result of my colorimiter’s inaccuracy, which I noticed in my manual testing. Strangely, I can’t get the artifacting to show up in both color managed and non-color managed apps on my display with the ICC profile applied. Is there a way I can test whether KDE supports cLUT profiles? I already tried using the test profiles on DisplayCAL’s website, and they all look wrong, but the clut profiles all look wring in the same way, as do the non-clut profiles, despite what the profile names would suggest.
Your test looks conclusive enough.
I also don’t expect KDE is willing to pay the cost of interpolating the whole desktop at 60 Hz using a 3D LUT as it’s quite resource intensive (best done in GPU or specialized hardware).
Even more reason to use VCGT to remove the green cast as it’s much cheaper.
Does your display have some issue that you insist on using XYZLUT? There won’t be a strong advantage over Matrix normally. XYZLUT mostly shines when a display has some non-linear behavior, such as TVs or some aged panels. A measurement report will tell if this applies to you.
VCGT may still be broken/buggy in Wayland, or so the recommendations in this guide suggest: https://zamundaaa.github.io/wayland/2024/07/16/how-to-profile.html A matrix profile may be the only viable option.
