- This topic has 35 replies, 3 voices, and was last updated 2 years, 1 month ago by
.
-
Posts
-
Hi,
after a long session I managed to calibrate my two monitors with DisplayCal. I do have a few questions left though.
My monitors:
1) a Samsung OLED Panel (ATNA56WR08) in a Lenovo P15 laptop with Nvidia card and
2) an LC-Power LC-M27-4K-UHD-144 (AU optronics 144Hz panel with around 90% P3 and Adobe coverage).I have two instruments:
a) a GretagMacbeth (x-rite) i1 pro Rev B (quite old already but seems good still)
b) an x-rite i1 display proFirst a comment: I lost a complete night hunting for a calibration bug where the instruments measured hugely exaggerated reds and reduced blue. I finally found out that I had Windows 10 Night Mode enabled, so I got the wrong readings only during the night! The ugly thing is that this is not visible in the GPU LUT you can read e.g. with CalibrationTester.exe.
Now for my questions:
1) When creating a colorimeter correction with the i1 pro, the resulting .ccss-file always has
“DISPLAY_TYPE_REFRESH” set to “YES”. I always have to manually correct this to “NO” in the file to be able to set the instrument mode to LCD later on. Is this a bug or am I doing something wrong? I have measured the correction in the LCD (Hires) mode, of course.2) I’m pretty sure of that one, but the R,G,B-settings of the monitor when creating the correction are irrelevant, right? My impression is that the spectral curves will be normalized anyway, so it doesn’t matter whether I have everything set to factory 50/50/50, or already a correction after a first calibration pass, right?
3) The backlight is quite certainly of the PFS Phosphor WLED type. However, as pointed out in other threads, the PFS Phosphor Family correction file has 4 different measurements with 4 different sets of primaries. Will an average of those be taken or is there some way for DisplayCal to find out which of those is the closest to my device?
Since I wasn’t sure, I plotted all 4 sets (as well as the Panasonic VVX recommended in another thread) in Excel against a measurement taken with the i1pro and chose the one that looked closest after rescaling. I’m still not sure what gives me greater error: choosing one of the measurements that don’t correspond exactly to my panel but have 1nm resolution, or my own measurement which corresponds exactly to my panel but is barely able to capture the spikes of the PFS phosphor at 3.3nm? I have an example here of the curve that I think matches best (see first attached file).4) I compared using the two colorimeter corrections, and both found the D65 whitepoint of my screen (after tweaking rgb-controls) at almost exactly the same location with the colorimeter (delta 0.8 (0.3139, 0.3306) with the i1pro correction, delta 0.9 (0.3137, 0.3309) with the selected 1nm correction). However, when I remeasure the same white with the i1pro, I get a greater error (delta 3.4 (0.3154, 0.3352)). Does that mean that the colorimeter corrections baked into the colorimeter are actually inaccurate due to the PFS phosphors and that the i1pro measurement is really fine, or is the i1pro so inaccurate that it cannot even measure the whitepoint correctly?
It’s rather similar for the OLED screen, which measures delta 3.0 (0.3126, 0.3327) with the colorimeter with the i1pro-generated correction, but delta 7.9 (0.3120 0.3400) with the i1pro itself.5) I set the tone curve to gamma 2.2 in order to avoid the necessary LUT corrections in the dark part of the LUT. This worked fine and the calibration curves are almost linear now (no banding). However, when looking at the tone response curve of the profile, they now have this correction built in, which seems to lead to more banding in color managed apps. Why could that be? See attached files for the calibration and tone curves…
I hope my questions make sense!
Thanks!
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Regarding 4), I now also created matrix corrections, and as expected, they lead to matching results between spectro and colorimeter. So assuming the spectro is correct, using matrix corrections seems in general preferable if you have access to both the spectro and the colorimeter! The output will be a 3×3 matrix anyway (rgb->XYZ).
- It seem so. It does not matter really, I think it may modify a little low light but I checked it a long time ago so I may be wrong
- CCSS are not normalized but whatever WP you have in CCSS, all WP can be produced by applying 3 Ks to that CCSS: all in gamut colors are a linear combination of those primaries (assuming good additivity)
- That sample in image is wrong, red primary is VERY different from yours, it’s desaturated (1nm sample). Depending on how good is your i1d3 (vs std observer) it may produce visual error or not.
You can make an hybrid by mixing G & B from that 1nm sample and getting a good R match from another one, then compute W as R+G+B
Or you can use your 3nm CCSS - IDNK what you are trying to explain. i1d3 + CCMX made by you (3nm) vs 1id3 CCSS (3nm), is it that? You’ll need a true reference to compare.
1st one shares accuracy with i1pro (by definition a CCMX is made to measure the same WRGB primaries) and its limited resolution. It will have some error vs a true reference
2nd one has an error that comes from actual i1d3 sensivity curves vs firmware curves and another one from 3nm CCSS error itselft (vs a true reference).
Its hard to predict without a reference, get the one that gest a better visual white.
CCMX are XYZ to XYZ. CCSS + colorimeter firmware curves are raw RGB -> XYZ. - Banding in color managed apps are produced by lack of accuracy of that color managed software (lack of dithering when rendering, ACR, LR or C1 should show less). Use single curve + matrix if display is well behaved to minimize banding (to minimize color managed app precision errors).
Thanks for the quick answer! For clarification:
2) regardless of normalization: so is it true that I can create a CCSS or CCMX at OSD settings r=50,g=50,b=50 for example, and I can still use the same CCSS/CCMX if I have to change the OSD settings later to r=40,g=50,b=40, for example?
3) What do you mean by desaturated? The peak of the 1nm red primary (the green curve on my image) is a bit higher than the one measured with the i1pro. Do you mean the “bulge” between 570nm and 600nm? That is present in all of the 1nm curves. They are straight from the file “PFS_Phosphor_Family_31Jan17.ccss” downloaded from the x-rite webpage via DisplayCAL. Where they are really different is that the i1pro doesn’t manage to capture the peak at around 650nm (there’s only a step there). Maybe the colors are a bit misleading in my image.
4) Yes that’s I think what I was trying to explain. In my original post, I compared i1pro against i1pro CCSS+i1d3 and there was a significant distance. In my reply, I compared the i1pro to the the i1pro+i1d3 CCMX and this matches perfectly (as it should by definition). I wonder whether this can tell me that the firmware curves are off (and should be recalibrated), or that the i1pro is not accurate enough for the task. On the other hand, if I use the downloaded CCSS+i1d3, this gives me almost exactly the same readings as the i1pro CCS+i1d3 (and both are significantly different from the i1pro readings), so my suspicion is that the i1pro is fine, whereas the i1d3 firmware curves are off…
5) My question was why the tone response curves show this bulge in the dark tones?
Thanks!
2 Yes
3. It’s desaturated. X coord is SPD * x-bar evaluated across visible wavelengths. DisplayCAL CCSS plot should do nit for you. The hump in shorter red wavelengths desaturated that primary.
PFS_Phosphor_Family_31Jan17.ccss has at least 1 example with native P3 primary (not desaturated), and panasonic VVX LED PFS too.4 “I wonder whether this can tell me that the firmware curves are off (and should be recalibrated), or that the i1pro is not accurate enough for the task.”
you cant know without a true reference. Use visual white test.5 you are plotting it against L*. For a instant gamma vs input plot use a measurement report or HCFR.
Also that recorded TRC in ICC profile is the actual TRC, with actual finite contrast.3) What hump exactly do you mean? I’ve attached plots of the red primaries for both the PFS_Phosphor_Family_31Jan17.ccss (with 4 curves) and panasonic VVX LED PFS (with 3 curves). Do you mean the humps <550nm? They are so tiny, not sure whether they could influence the result… They are only absent from the first curve in PFS_Phosphor_Family…
They DO because SPD is not the only thing there. The huge spike has less weight in X coord than you think. The hump has influence in Y and X
Do the maths.
X coord is SPD * x-bar evaluated across visible wavelengths. DisplayCAL CCSS plot should do nit for you.
Well, if the spike has no big influence, then taking the i1pro measurements isn’t so bad then, as they don’t have these “desaturations”, right?
Does it make sense to compare the corresponding whitepoints when using the different curves, or do I need to look at the coordinates of the primaries?
Btw, what do you mean with “DisplayCal CCSS plot should do nit for you”? It shows the SPD curves of the primaries and white, normalized to the maximum value, and the xy chromaticities of primaries and whitepoints. And without the colorimeter attached, I can only look at this plot by going through the “upload” dialogue…
Well, if the spike has no big influence, then taking the i1pro measurements isn’t so bad then, as they don’t have these “desaturations”, right?
Totally wrong, I’ve never said that. Do the maths. You evaluate SPD multiplied by std observer.
3nm sampling broads the spike and lowers its high, same fro 10nm (but worse). Std observer have its onw curves and they are lowering as you move to longer wavelegths, hence your visual guess just seeing CCSS shape fails since you are not taking Std sobervers into the evaluation.
Btw, what do you mean with “DisplayCal CCSS plot should do nit for you”? It shows the SPD curves of the primaries and white, normalized to the maximum value, and the xy chromaticities of primaries and whitepoints. And without the colorimeter attached, I can only look at this plot by going through the “upload” dialogue…
Click on spectra power distribution titke (on CCSS plot window) and it’ll swicth to CIE xy coordinates, but you can do the maths yourself: Since its 1nm data, just download CIE 2 degree 1931 observer , multiply same nanometer by same nanomether, then sum. You’ll have CIE XYZ. To get CIE xy normalize to x+y+z=1.
That hump is a “textbook sample” about how SPD incluences the position of RGB primaries. Why? because std observer height at those wavelengths.
If you do the maths yourself on an spreadsheet you may be able to play with it: delete or lower the height of some spike, make it broad and see what happens on CIE XYZ and whitepoint.I can do some Math when I have more time. But still, the whitepoints using the i1pro measured data and the curve with the “humps” were practically identical.
Do you know which CMFs are used in Argyll/DisplayCal? The original 1931 2deg ones, or the later ones that take into account inaccuricies <450nm? (see here: http://cvrl.ioo.ucl.ac.uk/cmfs.htm )
Again you are missing the whole point… and the only way to understand your misinterpretations is understand the underlying maths. There is no other way fro you to comprehend teh answers to your questions.
i1Pro errors are across visible wavelength (resolution, resolution missplacement, sensor error at certain wavelegth) and then those erros weighted against std osberver (some will rise, some will lower).
An “ideal” i1d3 using CCSS with hump measuring a WLED PFS without hump will have an error (only caused by wrong CCSS) due to the difference between firmw curves and std observer, and this error, no matter how big it is is device dependent (2x ideal i1d3 colorimeters with firmw curves matching device behaviour will have diferent errors even they have this idealized behaviour “firmw=actual sensivity”) but not caused at all by i1d3 device itself. As an example an i1d3 whose firmware and actual sensivity curves match exactly std obs on those wavelegths on hump…won’t care at all about using that wrong CCSS (hump) on a WLED PFS without hump. It has nothing to correct there.TL;DR
you need an accurate CCSS to avoid the errors you cannot control, hence you (plural, all readers) cannot use the CCSS with hump for a WLED you know it has no hump. Forge/make a synthetic one @1nm as instructed (to use a proper red channel SPD) or use your custom 3nm CCSS.Regarding ArgyllCMS CIE 1931 2 degree by default, with other observers as optional parameter. Read Argyll doc. CCSS corrections may become less effective wen you choose observers further away from colorimeter sensivity curves, since you may add a futher push to errors in CCSS vs display SPD
Not sure what point I was missing in my last point, but since it will take me a while to do the math, one more question. I don’t understand: “won’t care at all about using that wrong CCSS (hump) on a WLED PFS without hump. It has nothing to correct there”. I read this as “if the i1d3 sensitivity functions match the CIE CMFs, it doesn’t matter if you use a CCSS with an incorrect hump”. This seems to contradict what you wrote before and after…
Wrong. There are sources of error in an i1d3 as explained previously. One is missmatch between firmware curves and actual curves. Second missmatch between CCSS and actual display SPD.
1st will happen even with a perfect CCCS for that display, device dependent inherent inaccuracy.
2nd will rise errors depending on the difference of each device firmware curves vs std observer… this 2nd one is device dependent but it is not a fault of the device itself (which can be “ideal”, with 0 error in 1st scenario)… it user/owner error. This is the one I was talking about.
