- This topic has 63 replies, 5 voices, and was last updated 9 months, 3 weeks ago by
.
-
Posts
-
I am using a 2024 Datacolor Spyder on my laptop’s IPS LCD display, and my laptop is running the KDE Wayland session
I have the tone curve in calibration set to L*
My display when uncalibrated has a gamma of about 2.8 (very dark) and a strong red/orange tint
After calibrating, the red channel (and the green channel, to a lesser extent) falls off in the highlights giving them a strong cyan tint, and then from 254 to 255 they suddenly jump back up to full brightness
I ran the calibration at the maximum patch size two times and it had the exact same result
I ran the calibration with the same settings on a different laptop running Windows 10 and it did not have issue, it worked perfectly
It almost appears as if displaycal is overcorrecting for my display’s warm color temperature, but only in the highlights
I have the white point and white level set to “as measured”
Are there any obvious issues or settings I should change before running another 6 hour calibration?You should set the tone curve to gamma 2.2 or 2.4 , rather than L*, unless you have a specific reason for choosing the L* curve.
Your instrument is very inaccurate. You should get a colorimeter from from the i1 Display Pro family:
- X-Rite i1 Display Pro/Pro Plus
- Calibrite ColorChecker Display Pro/Plus
- Calibrite Display Pro HL/Plus HL
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.I have little reason to believe that the accuracy of my colorimiter is causing the issue. I just ran another calibration overnight with 0% black output offset and it had the same issue. The fact that the colorimiter works perfectly on other platforms, and yet consistently fails in the same way on my main laptop leads me to believe that the cause of the issue is either KDE or DisplayCAL. I made this post in hopes that someone more knowledgeable would be able to help me identify some setting in DisplayCAL that could mitigate the issue. I chose the L* curve because it more accurately represents how humans perceive lightness than the gamma function.
I’m going to try replicating the issue with a lower patch size so that I can more quickly test solutions, my next steps will be to stop adjusting the tone curve by setting it to “As Measured” or setting a specific white point, unless someone else has a better idea.
If I come across a solution on my own. I’ll document it here so that I can hopefully help anyone in the future that comes across this issue.
1- those screenshots (lagoom) should be taken NON color managed. Otherwise the color management module can cause weird rounding errors.
INDK if there is a MS Paint equivalent in linux, non color managed, or if your default KDE image viewer will color manage.2- beware of GPU driver “autodim” like in some iGPU laptops. You should disable it. IDNK how to do it in Linux, for Winodws there are several samples depending on intel GPU driver version.
This may cause that on a black or dark screen or background or some app dark theme, as soon as ArgyllCMS square patch falls under certain RGB Values, GPU starts to autodim.chose the L* curve because it more accurately represents how humans perceive lightness than the gamma function.
3- Absolutelly useless without HW calibration. If you want to work in L*, for example eciRGBv2, open in Krita or GIMP a new docuent, choose eciRGBv2 (or whatever colrospace you want with L*, there is a “ProStarRGB)”, L* equivalent to ProPhotoRGB) as document profile and thats all.
Choosing L* for VCGT will cause a HUGE correction from native gamam to L*, then another mild correction from L* to sRGB (opening SRGB images), 2.2… etc.
ABSOLUTELLY USELESS in 99.9% of situations, even more on a laptop.Sumary.
-try to figure if there is an autodim on GPU, bc it seems compatible with your symtoms. Then disable it of there is littel you can do with that OS+driver otherwise.
-use “medium” calibration speed, matrix-sngle curve + BPC profile type for testing. choose gamma 2.2 as starting point. On an i1d3 it should run in less than 20min. This will allow you to do more testing and maybe avoid some screensaver kicking in after X hours.
-evaluate grey calibration NON color managed. evaluate profile color managed.1- Only one screenshot was taken from lagom, the rest were test images i made in Gimp, and they all are only there to illustrate the real world effect of the issue
2- I am certain there is no automatic display dimming on my laptop, and I made sure that my room was completely dark, my automatic night light was disabled, and that displaycal was correctly inhibiting power management.
3- Yes, L* is not the standard target for display response curves, but modern software had a lot of lot of computationally generated color palettes computed in RGB, and so I’d like my tone curve to be as perceptually even as possible. I understand the worry about the conversions, but KWin does a fantastic job with color management and I have not noticed any perceptible posterization or banding no matter what color profile I use. My display’s native tone curve is far too dark and is the reason I ordered a colorimiter in the first place, so if I’m going to be fitting it to another curve I’d rather use L*.
I’ll try making a quick Gamma 2.2 profile to see if it fixes my issue. I will make it an XYZ LUT + matrix profile like before because I don’t want to change too many variables at once so that I can pinpoint the issue.
I did a bit of testing, and I can’t get DisplayCAL to make an ICC profile with fewer patches. I’ve tried 79 patches, 115 patches, and the default DisplayCAL settings for “Laptop”. Anytime profile my display with DisplayCAL, it always throws a dbus error at the end, but I didn’t really think much of it at first because the error occurs after the calibration and profiling has completely finished and it usually gives me the ICC profile in my output directory anyways, but with fewer patches it looks like it fails to put the ICC profile on my desktop for some reason.
It seems to fail at the part where it wants to show the window where it asks you to set the profile. The only difference i can find in the logs is that with fewer patches, the log ends after the dispread exit code whereas the 11k patches one does something in /tmp/DisplayCAL-* before exiting.I’m going to try the DisplayCAL default settings from a Windows vm to see if its an issue with KDE or Linux.
1- Only one screenshot was taken from lagom, the rest were test images i made in Gimp, and they all are only there to illustrate the real world effect of the issue
Then all your screnshots are wrong and are no valid test
2- I am certain there is no automatic display dimming on my laptop, and I made sure that my room was completely dark, my automatic night light was disabled, and that displaycal was correctly inhibiting power management.
Using spot read on non color managed “paint” with grey 100 on right side and showing 50% screen size with whie patch and blac patch would be a better test.
GPU autodimming is not like OLED autodim, can be tricky3- Yes, L* is not the standard target for display response curves, but modern software had a lot of lot of computationally generated color palettes computed in RGB, and so I’d like my tone curve to be as perceptually even as possible.
Non color managed maybe, but you rely on the WRONG asumption that a non color managed app showing that palette expects you to be L*, which is not rue on 99% scenarios. Color managed, your statemant & purpose for using L* is completely useless
I understand the worry about the conversions, but KWin does a fantastic job with color management and I have not noticed any perceptible posterization or banding no matter what color profile I use.
It is not, as your Linux color managed test showd us.
My display’s native tone curve is far too dark and is the reason I ordered a colorimiter in the first place, so if I’m going to be fitting it to another curve I’d rather use L*.
Your Linux OS , or your laptop , or your GPU or combination or two or more elements is bad behaved when dealing with VCGT, hence you should start to corner the culprit.
Using a weird TRC like L* won’t help you on this quest.I’ll try making a quick Gamma 2.2 profile to see if it fixes my issue.
As a second task if this does not work if doing it commandline. ARgyllCMS only. To discard new DisplayCAL 3.9 (py3) issues with your OS or wayland.
If command line still does not work as expected for a simple gamma correction and grey (REMEMBER, NON COLOR MANAGED TEST, otherwise your test will be pointless), try to mail to ARgyllCMS mail list since it seems an OS related issue.
Remember to do commandline “spotread” I explained above to discard GPU autodimming.I will make it an XYZ LUT + matrix profile like before because I don’t want to change too many variables at once so that I can pinpoint the issue.
That is an error that will cost you time to find who is messing with VCGT.
I’m not sure how my screenshots could be wrong if they match what my eyes see. Unless your display is improperly color managed, (which would be ironic), you can see the cyan tint in the highlights as well as the jump in lightness at the very top of the red channel.
Non color-managed apps expect your display to be the same as the developer’s which is almost never the case, therefore I would prefer to be using a tone curve that is correct according to my tastes. I will be using Gamma 2.2 for the rest of my testing for the sake of simplicity but I would rather not debate my choice of tone curve with you in favor of fixing my actual issue.
I couldn’t get the DisplayCAL to work in the Windows vm with the VirtIO GPU, so i tried running ArgyllCMS from the command line with DisplayCAL’s default options and it still failed to create the icc profile, and the log didn’t look any different. The dbus error was also nowhere to be seen so I can confirm that was a red herring. I then tried to do a simple gray curve and then a simple gamma correction, and they both failed in the same way, with nothing new in the logs. dispread simply omits the ICC profile from the output directory without any obvious indication as to why, and they’ve only ever done this when I don’t use 11k patches.
I’m reading through the ArgyllCMS docs and the DisplayCAL logs and I’m not entirely sure at what point the ICC profile actually gets made.
I’m not sure how my screenshots could be wrong if they match what my eyes see.
If you own a calibrator and intend to use it, wouldn’t it be logical for others to assume you aim to independently verify the color accuracy of your setup? While you aim to minimize variables, relying on browser output introduces one. Similarly, in troubleshooting scenarios, it’s best to start with the simplest, most widely supported profile. You can evaluate XYZLUT and 11k patches later if you want to.
Visual evaluation is mainly used for adjusting the white point in specific scenarios.
1. The spectral data is incomplete
2. Metameric error between two or more displaysYou situation matches #1 as the spectral properties of your laptop IPS panel are unknown. DisplayCal/ArgyllCMS can only assume that the Spyders best guess is correct, and this seems to cause a perceived cyan bias. A visual white point adjustment will be a necessary intervention.
If this is unacceptable you may want to base your setup around a different display, with a known spectrum. And a different colorimeter that supports spectral corrections. Such setups most often achieve a highly accurate white point without perceived color shifts.
I think colprof is used to make the color profile, it just doesnt ever get included in the logs.
After running it manually, it successfully makes an ICC profile. My guess is that the dbus error I mentioned earlier causes DisplayCAL to exit early in some scenarios and then it never runs colprof. I would have caught it earlier if colprof wasn’t omitted from the log for some reason.
With that issue out of the way, I applied the simple gamma curve ICC profile I made earlier and KDE informed me that it only supports ICC profiles with an XYZ connection space, which is confusing to me as before my colorimiter arrived, I had modified an sRGB profile with custom gamma correction to make my monitor more usable and it worked just fine.
I then made the ICC profile of one of my previous 79 patch calibrations i had made for gamma 2.2 (an XYZ LUT+matrix), and I had to override the colprof algorithm type because it kept using lab as the connection space (-a X) and… it made everything SUPER orange and somehow the highlights are still cyan-ish. At least the jump from 254-255 is gone. its like it did the opposite of correct my monitor.
I’m going to continue testing, but this is getting stranger and strangerI just tried using making XYZ LUT + matrix profiles out of the 1x curve + matrix and 1x gamma + matrix calibrations I made earlier as a test, and they made garbage data profiles that made my screen completely pink which was fun.
The fact that I can only use XYZ LUT profiles with KDE may make this a bit more difficult to figure out.
All the signs so far point to it being a KDE issue. Noting that, I went searching for information about KDE and color management on the internet and I found a recent blog from a KDE developer where it says “Here it’s important to set the tone curve to ‘as measured’, and untick interactive display adjustment, as those don’t work correctly right now and will mess up the profile.” They don’t go into detail about why setting a tone curve isnt supported.
https://zamundaaa.github.io/wayland/2024/07/16/how-to-profile.htmlThis is confusing but possibly a step in the right direction, however my synthetic sRGB profile and my first three 11k patch L* profiles appeared to change my tone curve just fine. I’m going to test some different formats of ICC profile while running ArgyllCMS manually.
If you are concerned that the software is misbehaving, have you considered matching your Linux system to one that’s well tested with ArgyllCMS? We don’t know who made your ArgyllCMS package, sometimes dependencies aren’t caried over correctly, or there’s some compiler settings that aren’t fully carried over and it creates issues which the developer has no control over. Another thing causing issues that the dev can’t control is Wayland, its literally newer than ArgyllCMS is still under heavy development, so you might want to use something more mature than Wayland while profiling.
Not surprising that a simpler profile partially solved issues. The remaining issue, assuming no software issues, suggest a non-linear display behavior and an atypical panel spectrum/gamut. Very common for laptop displays, and the Spyder hardware is not very capable at handling atypical panels. You may profile a desktop display and see if you get the same kind of unstable midtone-whitepoint tone.
I’m using the binaries from the ArgyllCMS website since Arch Linux has 3.3.0 and the colorimiter I have is only supported in 3.4.0.
If I can’t fix my issue by messing with colprof I’ll try correcting the colors of some of the monitors around my house form my laptop, to verify that KDE is the cause of the issue.
