- This topic has 25 replies, 3 voices, and was last updated 4 years, 2 months ago by
.
-
Posts
-
Hey @vincent, this is a follow-up to thread about Dell UP2718Q.
I reported factory Adobe RGB tracking results for a UP2516D that meet Dell’s claims but were on edge of tolerance by DisplayCal standards.
To refresh I’ve been using a Monaco Optix XR DTP94 with i1 Pro ccmx this UP2516D display.
It’s been a nagging question as to whether I can trust this DTP94 because of its age and changing display tech. It makes alignments that look good, and track specs of the devices I’ve been measuring. But… When examining the finer points I need to be able to triangulate.
I’ve acquired a new i1 Display Pro Plus (XRite “EODIS3PL”) hoping to increase my confidence in measurement reports for Dell factory modes, and see how it differs from results of this 10 y.o. DTP94.
This also lets me explore the no-cost Dell | XRite DUCCS capability to load display’s internal LUTs (“Cal1/2” modes)——Btw DUCCS appears to be rebranded i1 Profiler! The version on Dell’s website is old and has an expired Mac application certificate, but once installed, it downloads a newer version from XRite which seems up to date.
But ok, sideline DUCCS for now.
I’m starting with DisplayCal, and here the mystery deepens. There are 5–10 different correction files for this device combo in database, all listed as ColorMunki / i1 Display Pro, with different Dell color mode assumptions (native, Adobe RGB, sRGB, etc). And depending on which one I choose I get different whites, different red primary chromaticity, and very different and very wrong gray tracking reports for factory mode Adobe RGB, like laughably bad 7–8 dE*00 hump in mid gray response. And the different corrections don’t really agree with each other any better than just eyeballing the alignment.
The results are very repeatable, and all over the place. IOW this new puck is not increasing my confidence, its reducing it! 🙂
The most normal response comes from using no correction at all, and this way the i1 Plus and DTP94 w/ correction agree pretty well, and displays are reported within Dell’s tolerance, except for red chromaticity which is 3.5 dE*00 off mark.
What do you suggest to make sense of situation. I unnerved by a calibration system where I struggle to get results to converge… and simple steps to improve quality, like getting a new instrument appear to make quality more uncertain, though I can accept this as a basic property of the cosmos 🙂 An efficient world would get rid of me!
TIA for any insights
P.S. There is a “Vincent Tech” on YT talking about how horrible the Pro XDR is 😉
Calibrite Display Plus HL on Amazon Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.UP2516D and UP2617D uses a variant of WLED PFS with “floor” in spectral power distribution raised if you compare it to “current” WLED PFS. Hence it needs readings @3nm or higher resolution from a spectrophotometer.
Also CCSS need to be from native gamut measurements. All colors in an emulated gamit mode are a combination of native primaries. Some users did not follow that statement becasue they did not know… or they did not care.
Once you have CCSS downloaded you can use “(i)” button next to CCSS combo button to plot spectral power distribution. This way you can know if it’s from native gamut = red or green do not seem to be a linear combination of 2+ channels (including ifself)
You can plot them with specplot too (ArgyllCMS command line)Once you choose proper CCSS just measure.
DUCCS does not have the proper/exact spectral correction (EDR, binary file) to these 2 UP models. It should be using RG:phosphor (GB-LED like U2413 mixed with other older backlights) or P3 95% (just P3, not AdobeRGB) WLED PFS backlight used in multimedia and gamming P3 displays.
PS, that guy is not me, but I’ve seen his video.
PS 2: If you have access to an xrite spectro, remember to use it at 3nm if you wish to create a CCMX matrix, or a CCSS correction. CCSS may be shared with community. Also remember to use Standard or Custom color mode to make it = native gamut
Ah k, I am piecing the puzzle together, so ccmx is matrix comp and ccss is spectral compensation. This lets me throw out several matrix DB items in favor of spectral options
Then I see some are named for what mode the display was in during measurement, which suggests the contributor might not understand the relationship between settings and this measurement, so I cast these out.
This leaves two.
You write:
This way you can know if it’s from native gamut = red or green do not seem to be a linear combination of 2+ channels (including ifself)
Attached are SPD screenshot for
ccms “Dell UP2516D (i1 Pro 2)” (***)
ccms “Dell UP2516D (i1 Pro )”The first plot shows pure primaries, the other has red built from red+green, so I cast this one out, leaving one useful ccss ***
I am on right track?
Thanks Vincent
Green is the one built from green + red + a littel of blue =”huge” desaturation
Red has a little mix from green
=> likely to be a sRGB/Rec709 emulation.OK that really helped, thank you!
Attached are quick reports for UP2516D factory Adobe RGB using 10 year old DTP94 vs brand new i1 Display Pro plus.
DTP94 says Dell is off their claim of 2 dE by about 0.5 in gray tracking.
i1d3pl says Dell is on target with their claim across board +/– 0.1.
This convergence builds confidence.
?And suggests using a well cared-for DTP-94 with the matrix correction is not a waste of time on newer displays?
/wire
DTP94 correction could still be good if matrx correction was mede from measurements at 3nm, otherwise those 3 peaks you saw in red (“foggy”, ypu’ll need 1nm the see them as they are) wont’t be there and SPD would be like lonely high hill in red wavelengths. AFAIK that colorimeter has not se same “fast fading” filters as i1d2 or older spyders… just lacks of spectral correction support so you need a spectro to be usable with modern displays. IDNK if it is too slow compared to a new i1d3pro.
Grey range is pretty bad measured with i1d3… I would calibrate it. Barely usable at its curret state, range about 2.4, almost no grey calibration at all
So I ran into a snafu where using the ccss I mentioned before I make a custom profile I can’t get it to verify without a huge defect in grays—see first attach
So I tried going back to correction None, which was working OK last nite except for a glitch in red for factory Adobe RGB verify. I double checked all settings, re-profiled and re-verify. Same problem. Multiple tries checking settings to be sure. Custom profile verify keeps coming up bad…
So disconnected colorimeter, removed all downloaded ccss, restarted DIsplayCal, ensured correction None. Ran a quick profile, and quick verify. Now report comes up perfect!—second attachment.
Re-ran factory Adobe RGB verify using no correction and it’s as expected except for glitch in red.
Also 6500 VDT whitepoint with i1 Pro2 3nm looks too green. Using no correction white is almost exactly native white (RGB gains = 100)
So it seems an i1 Display Pro ccss does not work properly with i1 Plus?
Not needed* * *
Also minor DCal glitch: the timestamp in verification filename doesn’t agree with the timestamp in the verification report, which makes keeping track of these a bit tricky.
/w
Correction : NONE = innacurate, so all your work is wasted because of that configuration.
This means: meter reports wrong value… so calibration is wrong. So profile data is wrong, and ongoing validations using the same uncorrected probe are wrong.
This means also that your 1st (of 3, last post) report is wrong for the same reason: no correction in verification. If you make a calibration + profile with a CCSS correction but you verify with none… verification is wrong and it’s an user fault.
There is no issue with i1d3 plus and CCSS, there is an issue if user does not use DisplayCAL as intened.Ya I didn’t make that mistake, something else is going on
Profile with ccss, verify w ccss, result is bad
Profile with None, verify w None, result good
No mixing and matching
Simple as that
Cross checked DCal-no-ccss with DUCCS: excellent visual agreement.
All signs show probe is working properly.
Next I’ll try a DUCCS built-in LUT cal for my chosen alignment then simulation verify it against DCal-no-ccss vs ccss for same alignment, will see how they agree
To be clear, by BAD I mean I run a measurement then verify using same settings, and get wildly bad gray tracking using ccss.
I’m not saying ccss profile is inaccurate, but I can’t get a proper verification using ccss.
What is the logic behind correction Auto, how does it chose?
Ya I didn’t make that mistake, something else is going on
Profile with ccss, verify w ccss, result is bad
Profile with None, verify w None, result good
No mixing and matching
Simple as that
Cross checked DCal-no-ccss with DUCCS: excellent visual agreement.
All signs show probe is working properly.
Next I’ll try a DUCCS built-in LUT cal for my chosen alignment then simulation verify it against DCal-no-ccss vs ccss for same alignment, will see how they agree
[..]
To be clear, by BAD I mean I run a measurement then verify using same settings, and get wildly bad gray tracking using ccss.
I would say no, given the provided data and the lack of provided data.
Also if in doubt.. just use one of the CCSS used by DUCCS/i1Profiler (GB-LED / WLED PFS P3 95%) that are bundled by default on DisplayCAL for i1d3 as I wrote some measages ago.
There are 5–10 different correction files for this device combo in database
Note that those are all user supplied files and there is no vetting whatsoever, so big caveat emptor. Use the bundled corrections, these have been created with high precision lab-grade instruments (with the exception of the QLED one which doesn’t apply to your situation).
Thanks
When I ask DIsplayCal to choose (Auto), it chooses none.
When I look in the list, I see a number of options, none of which is obvious choice…
- This is a GB-r panel, so should I use old Dell U2413 GB-r?
- Vincent suggested PFS WLED xx% P3 but there are three specific vendor’s options for HW and gamuts which are not quite what I am using.
Also, I notice that choosing a “spectral” correction forces Mode: Refresh. Choosing generic LCD forces Correction :None. Looking inside a ccss, I see this is a tag within that data.
When I tried to regroup be deleting all my 3rd party ccss, I returned to DisplayCal, and loading storage for previous measurements based on a 3rd party correction resulted in Correction switching to the first device-specific option in the list (CRT Hitachi), maybe because Mode:Refresh stored for prev
Yes, I am pretty sure I am screwing up. But not because I don’t comprehend what’s needed, but because of UI / option combinatorials. This thing is vastly comple
- * * (*)
There is an aspect of the measurement storage mechanism which (prolly because I am experienced and not diligent enough) is tripping me up: I think of storage as a baseline for experiments where I change options to see what happens and return to last-used. Each run produces a new storage unit named with a time coordinate (arcane series of letters and numbers) and as these storage units proliferate, it becomes hard to keep track. Yes I see they are snapshots, but the way I want to think in the midst of uncertainty is in terms of baselines.
Add to mix ual display, display numbering is backwards, e.g., OS display ID 1 and 2 are opposite of “Primary” (where the Apple Menu lives) and “(blank)” (not Primary), and measurements are named #1 and #2 for where the Apple Menu lives, not the OS IDs. It doesn’t really matter, but keeping track of this stuff is maddening!
So there is a UI vortex for me where the step-by-step I’m going farther out into the weeds with less and less chance of getting back, confidence decreasing with each step because of large numbers of combos and sometimes surprising interactions between stored settings. Then the doubt sets in and attitude goes to Hell and Vincent is saying “User Error, User Error…” Absurd, LOL! Well you see what I mean. Add in OS profile selection oddities like MacOS just resets the default to EDID for some reason and it’s a nightmare. The simple matter of converging a display alignment on a usable standard has become a voyage of discovery to a new world where Sun sets in East.
(*) It’s like when I want to type three stars in a row on a new line and the web visual edit widget thinks the star is markdown and makes the line into a bulleted list and I DON’T WANT a bulleted list I want a star, so you have to type something else then a star, then backspace over what you typed to keep the AI from intruding omg please weaponize this technology and put it in nuclear power stations, aircraft and life-critical medical gear!
This is a GB-r panel, so should I use old Dell U2413 GB-r?
That would be the closest one. An exact match to the display model is not necessary, only the correct SPD.
Vincent suggested PFS WLED xx% P3
This display has a GB-r backlight, not PFS.
This is a GB-r panel, so should I use old Dell U2413 GB-r?
That would be the closest one. An exact match to the display model is not necessary, only the correct SPD.
Vincent suggested PFS WLED xx% P3
This display has a GB-r backlight, not PFS.
It does no look like a GB-led. User data shows typical phosphor spectral peaks in red.
Grame Gill has a UP2716D with the same backlight and he provided a 10nm sample when trying to correct i1pro “bug” (mismatch between xrite and argyllcms readings). His SPD plot is a “foggy” version with phosphor peaks partially erased by lack os spectral resolution.So it looks like a WLED PFS but with a higher “floor” on red than typical WLED PFS:
https://www.avsforum.com/forum/139-display-calibration/3114216-i1-profiler-vs-displaycal-colorimeter-display-calibration-software-2.html#post59090870
It’s like a less detailed SPD than user provided 3.3nm we see here:
At 1nm peaks will be easier to notice, almost in the same wavelegths as PFS.
A GB-LED like U2413 has a red phosphor with a broad hill with small slope that keeps high past red.
