Inconsistent calibration results (Dell XPS 13 & Spyder 5)

[nico]

Hey there,

I’m currently trying to calibrate my XPS 13 (UHD touch screen version) using a Spyder 5 Express (mainly for screen design and photo editing). I’ve actually done this before, right after I bought the laptop and the calibration device back in late 2017. Unfortunately, I’ve lost my profile and settings from back then. But as far as I remember, I achieved decent results with pretty standard settings. Now I’m having a much harder time getting to a satisfying setup. I don’t know too much about display calibration but I’ll try my best to explain what’s happening.

I’ve performed multiple calibrations. The results were visibly poor every single time and produced high average and maximum deltas in the measurement report. Just from looking at it, one of the more apparent problems seem to be the grey tones. For example, the contrast seems to be off somehow so that different shades of grey are hardly distinguishable. Darker greys are mushed together at the lower end of the spectrum so that I’m losing lots of detail in darker parts of a photo.

Even when running the same calibration with the same settings twice, it seems to me like the colors don’t turn out quite the same. Not 100% sure that’s not just my eyes, but maybe it still helps narrowing down the problem …

I’ve attached the last set of settings that I’ve tried. I’ve set the whitepoint to 6500 K and played around with the Gamma value (2.0) and the Black point correction (3.00). Not sure if that makes any sense tbh 😐 I also tried “Maximize lighness difference” in the Patch-sequence setting. But I’ve also tried all sorts of other combinations (including  the standard “Laptop” and “Photo” settings)  – without any luck.

As I’m not particularly experienced with display calibration, I’d appreciate if you could give me a hint for what to try next. I guess the problem lies somewhere within the list below, I just can’t tell which one it is …

• Does the age of the laptop (merely two years) explain why it is harder to get good results than it was 2 years ago?
• Does the accuracy of a Spyder 5 deteriorate within 2 years? I kinda don’t think that’s it because I recently calibrated another desktop screen without any problems.
• Did I mess up the calibration settings?
• Did I mess up the verification settings?
• Is it just my eyes?

I’m sorry if this description is vague, but maybe it rings a bell for someone?

Thanks a lot, I appreciate your support!
Nicolas

• This topic was modified 4 years, 9 months ago by nico.

Attachments:

You must be logged in to view attached files.

[Vincent]

First of all check if your laptop has some kind of autodimming ON and disable it. You may need to go deep into some vendor GPU configurations (intel iGPUs), please search online since it may vary with driver UI and IDNK all configurations. It may cause gamma shift across grayscale that we see in report,

Also in your report you are validating how that profiled screen will behave under color management simulating sRGB. Start with verifiying just if calibrated display and its profile match. Let’s find if there are errors there, then you can move to other tests.

Inconsistiencies across grey ramp (gray balance color tint, a*b* variations in grey) may be caused by (a not accurate) colorimeter, some autodimming messing up, user misconfiguration (too fast calibration speed configuration for a not so good screen) or graphics card limitations for calibration (graphics card LUT, common in laptops). You may solve the first 3 but not the 4th (if you suffer it).

PS: For me Spyders have never been an accurate device, so… you know.

• This reply was modified 4 years, 9 months ago by Vincent.

[nico]

Hey Vincent,

thanks for your help!

First of all check if your laptop has some kind of autodimming ON and disable it. You may need to go deep into some vendor GPU configurations (intel iGPUs), please search online since it may vary with driver UI and IDNK all configurations. It may cause gamma shift across grayscale that we see in report,

As far as I can tell auto-dimming is disabled. I’ve also turned off everything else in the Intel Graphics UHD Control Panel that looks remotely like it might mess with the colors (see attached screenshots). Windows “Night Light” is disabled as well. Possible that I have missed something but at least I can’t see color or brightness changes over time.

Also in your report you are validating how that profiled screen will behave under color management simulating sRGB. Start with verifiying just if calibrated display and its profile match. Let’s find if there are errors there, then you can move to other tests.

I’m not quite sure if my understanding of the “Verification” tab is correct. How do I check the display against its profile? Like this?

• Testchart or reference: Extended verification testchart
• Simulate whitepoint: enabled [?]
• Relative to display profile whitepoint: enabled [?]
• Simulation profile: disabled [?]

too fast calibration speed configuration for a not so good screen

I’ve read different things about calibration speed. Longer is not necessarily better if the screen is 100% stable, right? Any idea what’s appropriate for my laptop? I would’ve expected a 2000 € XPS 13 (9360) to have a decent display, but what do I know …? 😀

For me Spyders have never been an accurate device, so… you know.

That doesn’t sound promising. But as I’ve successfully used it with other screens (or at least I think so) I kinda think the main problem can’t be the colorimeter.

Attachments:

You must be logged in to view attached files.

[nico]

Here’s a report with the verification settings as listed in my previous post. Some grey and non-grey values seem to be off according to it.

Attachments:

You must be logged in to view attached files.

[Vincent]

(EDIT: I wrote my answer before your last post, saw tooth gamma shifts were more detailed in previous report becaus it had more measurements)

Autodimming control in old intel HD*000 was placed in battery settings. Sorry I do not remember exact configuration but it was obscure. Try to find online autodimming control for yours.
Also take a look of gamma plot  (vs input) in your report, those periodic huge gamma shifts in brightness but not in color. Looks like adutodimming to me.

Calibration speed if it has not changed is asociated with the number of iterative grey ramp (+ R,G,B neighbors) measurements. If something is wrong in calibration (after if was done), try to increase this number. Medium is up 48 (256/48 = 5 unit jump), slow is up to 96 (about 2 unit jump). it is effective removing green magenta cast in calibration *if* your GPU supports it properly, without calibration banding (and most laptops won’t).

Spyder inaccuracies & error error will be related to white point and dark colors. If you see white 255 as “white” (even if it is not actually white, but user believes it) you can skip my complains about spyder. Same for very dark grey patches.

The report you showed us has two main issues:
-some weird gamma shift with saw tooth (which a priori I would relate to autodim)
-slight grey blanace innacuracies (usually they are related to a lack of mesaurements = calibration speed, or graphics card that is truncating LUT contents which is not correctable).
You can take my approach do solving these 2 or seke additional sources of this errors to happen… but these issues exists because we see them in your report (otherwise it would be colorimeter malfunction, not innacuracies, malfunction… and it loksk that this is not happening)

• This reply was modified 4 years, 9 months ago by Vincent.
• This reply was modified 4 years, 9 months ago by Vincent.

[nico]

Ha, I think you might be onto something. I’ve looked around again and it turned out that Dell has a thing called Dynamic Backlight Control (DBC) that changes contrast and brightness depending on what is visible on the screen (I always thought we’re talking about battery levels or the environment brightness as triggers). It was very, very subtle but I think I convinced my eyes to observe some slight brightness changes when quickly replacing bigger parts of dark areas on the screen with white. But yeah, super subtle so I’m not 100% sure. Anyway, Dell has released a utility program to disable this feature somewhere deep down in the firmware (as explained here).

I’ve done so and ran another calibration with the “Photo” preset (changed to 6500K). The first attached report is another self-check (as the last one above). Everything’s finally green in there. 🙂 The second report tests against sRGB. It mostly looks good except for “RGB gray balance (>= 1% luminance) combined Δa*00 and Δb*00 range” which is at 2.54. Is that because I’ve selected “Gamma 2.2” as a Calibration tone curve but then tested against sRGB?

Thanks for your ideas! Seems like I’m finally getting somewhere. 🙂

Attachments:

You must be logged in to view attached files.

[Vincent]

a*b* range aims to detect issues in “color” of grey.

There are two ways to evaluate it:
-against profile, if you choose a “detalied profile” with 3 different TRC per channel
-against “true neutral grey”, so relative to whitepoint each grey shuld be close to a*=0 (green magenta) and b*=0 (blue yellow axis)

Lets say that against one of these refererences each grey has low error, let’s say 0.5dE.
But one grey could be 0.5dE towards magenta and another grey could be 0.5dE towards green.
Each individual grey have low error against reference, but if you see a black to white gradient it will have visible tint because the hufe distance between a “pink grey” and a “green grey”.

“Range” or “grey range” (pard.de) or “gray balance” or “combined delta a b…” is a metric to discover such issues.
Try to see grey ramp in a L*a*b* colorspace, “move” the mental camera to the top, facing white. You are seeing now a*b* plane without L* component (brightness of each grey). “Range” is a way to find how far away in a*b* plane are the worst cases of your greys. As an example a -0.8 a* slightly green grey and a +0.5 a* slightkly pink grey. You have an “a*” range of 1.3 easy to spot with your own eyes in a B&W gradient.

Look into self-verify report (against display profile).
Since you made a XYZLUT profile, you store 3 different TRC (among other things) in ICM profile. Those curves for YOUR calibration shows that grey obtained after calibray that is not neutral, and profile stores it.
Why is it not neutral? Explanied in my previous messages, there a several causes and one is not correctable in a laptop.

So you have a table/xyzlut profile with 3xTRC.
You choose a self-valifation. Your calibrated  display with these non neutral grey are close to the ones stored in ICM profile, so all goes OK/green.

If you choose to validate against true neutral grey (a=b*=0) errors arise.

As I said in my previous messages, to increase number of calibration patches (decrease calibration speed) helps with this issue sinec you have smaller jumps between each calibrated grey… unless it is caused by lack of precission of graphics card LUT (the table where grey ramp calibration is loaded).
It is common that gpu laptops have limited precision (8bit, usualy intel GPUs, at least older ones)… so although it can be improved, it may not be solved at 100%.

[nico]

Hey  @vincent, sorry I didn’t reply earlier. Thanks a lot for the in-depth explanation! I found the time again to do some more experiments. Using the “Photo” preset, decreasing the “Calibration Speed” setting to “Low”, and increasing the “Amount of patches” in the “Profiling” tab did help improving the results. I can’t quite reach an a*b* range below 2.0, but I got very close: My previous value was 2.54 – now I’m down to 2.06 (report attached). That seems to be all that I can get out of this screen. Increasing the amount of patches any further didn’t affect the result (I even ran a 7818-patches, 12-hour calibration last night).

Anyway, I think I’m quite happy with the result now. The test chart looks alright to me, and  I can’t spot any immediate visual problems that’d keep me from editing photos.

So, thanks a lot! I appreciate your support, that was extremely helpful! 🙂

Attachments:

You must be logged in to view attached files.

[Author]

Posts