- This topic has 20 replies, 2 voices, and was last updated 2 years, 7 months ago by
.
-
Posts
-
- Offline
Ive been doing some calibration and verification on my display and something strange is happening. I want to make sure that I understand what the results “should” be.
The display is a Dell S3222DGM which is a VA Panel and as far as i can tell it has to be a PFS Phosphor display. The Gamut volume is 120% sRGB with gamut coverage at 78% aRGB, 85% P3, and 99.6% sRGB. The included SPD i found in the community database which even at only 10nm looks like a PFS to me when compared to a number of similar measurements of PFS displays.
When i profile using the bundled PFS Phosphor family correction on a Colormunki Display and verify against that profile everything looks great, BUT when i look to verify sRGB in color managed apps by
1.checking the simulation profile box and selecting sRGB as the simulation profile
2.leave the default apply block output offset 100%
3. Click measure and report
The results Show major problems in pure blue with a dE of 4.65 and a shift to purple and test patches # 4->7 dE as high as 6.94. This shouldnt be the case right? Might i simply be misunderstanding how verification + simulated profile interact? Might this also be caused by this not actually being a PFS display? Im really curious as to what exactly is happening here.
Calibrite Display SL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.
- Offline
Ok i think i solved this
I created a Single Curve + Matrix Profile and while blue deviates more than everything else when simulating sRGB with a dE of 1.5 all other measurements are dE < 1
2ns screenshot on 1st post looks like you chose “use simulation profile as display profile” due the high errors in a*b* grey. If you use simulation profile as display profile, it wipe out VCGT grey calibration from GPU.
Testing color managed is “simulation profile = sRGB” and DO NOT use simulation profile as display profile.
Testing a HW calibration or factory calibration against sRGB is “simulation profile = sRGB” and use simulation profile as display profile.Might this also be caused by this not actually being a PFS display?
No, choosing a wrong correction means that corrected measuremenst won’t / may be not accurate… but this applies to every measuremnet.
If you choose a wrong correction for calibration but you use the same wrong correction for validation it should show no error due to wrong correction. you are measuring with the same “deformed rule” when calibrating and when verifying. Errors may shpw up when making a comparison with a true reference device or a device properly corrected.
- Offline
2ns screenshot on 1st post looks like you chose “use simulation profile as display profile” due the high errors in a*b* grey. If you use simulation profile as display profile, it wipe out VCGT grey calibration from GPU.
Testing color managed is “simulation profile = sRGB” and DO NOT use simulation profile as display profile.
Testing a HW calibration or factory calibration against sRGB is “simulation profile = sRGB” and use simulation profile as display profile.I did not actually select use sim as display, but i found out the colors having errors are out of gamut for my display ever so slightly. When using a 1xcurve+matrix the issue seems to be lessened . Why might the XYZ+matrix be producing these errors but the 1xcurve+matrix doesnt?
- Offline
Might this also be caused by this not actually being a PFS display?
No, choosing a wrong correction means that corrected measuremenst won’t / may be not accurate… but this applies to every measuremnet.
If you choose a wrong correction for calibration but you use the same wrong correction for validation it should show no error due to wrong correction. you are measuring with the same “deformed rule” when calibrating and when verifying. Errors may shpw up when making a comparison with a true reference device or a device properly corrected.ok so it would just universally be wrong and not show this, as i dont have a true reference i cant be 1000% certain ive got it right but im fairly postive then as there are no color casts or anything like when ive gotten the backlight wrong on other displays.
- Offline
2ns screenshot on 1st post looks like you chose “use simulation profile as display profile” due the high errors in a*b* grey. If you use simulation profile as display profile, it wipe out VCGT grey calibration from GPU.
Testing color managed is “simulation profile = sRGB” and DO NOT use simulation profile as display profile.
Testing a HW calibration or factory calibration against sRGB is “simulation profile = sRGB” and use simulation profile as display profile.Ive redone the profiles and also the verification here for the XYZ+Matrix and it still shows this same oddity. This doesnt happen with the 1xcurve
Do you make 1curve+matrix configured to use fast calibration? If not, that seems the reason.
Are you reusing past calibration for making the XYZLUT? maybe the XYZLUT profile is storing a wrong VCGT because some user option.Also you should try to make a measurement report with no profile simulation for both XYZLUT and matrix 1 curve, just verifying if each calibration matches its profile, then choose “Evaluate gray balance through calibration only”. This will get you a hint of the quality of the grey calibration.
- Offline
Do you make 1curve+matrix configured to use fast calibration? If not, that seems the reason.
Are you reusing past calibration for making the XYZLUT? maybe the XYZLUT profile is storing a wrong VCGT because some user option.Also you should try to make a measurement report with no profile simulation for both XYZLUT and matrix 1 curve, just verifying if each calibration matches its profile, then choose “Evaluate gray balance through calibration only”. This will get you a hint of the quality of the grey calibration.
I used medium speed for both and 175 patch test chart for both (not needed for curve ik)
I redo the profile from scratch each time as im not sure how to reuse a past calibration in the settings and dont trust doing that. I made new profiles with both using medium with 778 patches on both profiles and they both show the same results as the 175 patches.
When measuring just against the profile itself XYZ+Matrix is basically perfect with everything sub 1dE (most sub .5dE) and the curve only a bit worse vs the XYZ. Its only in the sRGB output in displaycal verification specifically that it has the errors but Ive come to the conclusion that it might have something to do with the blue tones being out of gamut and clipping or something with sRGB.
Ive included the 3D gamut view of the blues with display gamut as wire and sRGB the solids. I dont think there is anything i can do about it but its just weird the XYZ shows it more.
The XYZ matrix verification results are in the OP (ive included them again just to keep things together) as they havent changed except for slight run to run variance and here are the curve results also
The curve has blue with 1.5dE just for identification
Do you make 1curve+matrix configured to use fast calibration? If not, that seems the reason.
Are you reusing past calibration for making the XYZLUT? maybe the XYZLUT profile is storing a wrong VCGT because some user option.Also you should try to make a measurement report with no profile simulation for both XYZLUT and matrix 1 curve, just verifying if each calibration matches its profile, then choose “Evaluate gray balance through calibration only”. This will get you a hint of the quality of the grey calibration.
I used medium speed for both and 175 patch test chart for both (not needed for curve ik)
This said fast:
I redo the profile from scratch each time as im not sure how to reuse a past calibration in the settings and dont trust doing that. I made new profiles with both using medium with 778 patches on both profiles and they both show the same results as the 175 patches.
When measuring just against the profile itself XYZ+Matrix is basically perfect with everything sub 1dE (most sub .5dE) and the curve only a bit worse vs the XYZ. Its only in the sRGB output in displaycal verification specifically that it has the errors but Ive come to the conclusion that it might have something to do with the blue tones being out of gamut and clipping or something with sRGB.
No, the main issue was grey.
This one does not look like a true XYZLUT profile although you named it “xyz.png”, attach HTML files.
Ive included the 3D gamut view of the blues with display gamut as wire and sRGB the solids. I dont think there is anything i can do about it but its just weird the XYZ shows it more.
The XYZ matrix verification results are in the OP (ive included them again just to keep things together) as they havent changed except for slight run to run variance and here are the curve results also
The curve has blue with 1.5dE just for identification
- Offline
This said fast:
yes im aware, but the original OP results nor my most recent ones are. I was doing quick test profiles with different patch amounts to see what happens and since the results arent any different i posted the ones i immediately had just done.
No, the main issue was grey.
This one does not look like a true XYZLUT profile although you named it “xyz.png”, attach HTML files.
It is, Ill redo the measurements again and post them here in a bit once my display has warmed up for both the XYZ and Curve and will include the 773 patch profiles I currently have in use along with it.
I should also not i havent touched the display settings at all for any of this, ive left the OSD as i have had it
- Offline
In the mean time here are both of the profiles while i wait for the display to warm up
- Offline
Here are the current results after measurement of the medium speed with “778” (i kept saying 773 before) patch profiles.
The XYZ still measures great, the curves less so but now with more patches red is apparently off using curves profile??
(it wasnt last night)(im just dumb the sRGB blue is still 1.5dE its the regular verify that red is 1.7 off)Regardless here both html with a screen for quick look
- Offline
The plot thickens, the XYZ+Matrix measures better with Argyll 2.3.1
Im going to test this some more
- Offline
Here is the same XYZ+Matrix from above sRGB measurements with argyll2.3.1 instead of argyll3.0.0 which is producing the results i would expect with the low blue coverage
I also noticed argyll3 doesnt display my device firmware date and has some other text replacing it regarding the i1d3 dtype? It doesnt occur with 2.3.1
