- This topic has 6 replies, 3 voices, and was last updated 2 years ago by
.
-
Posts
-
Since I’ve bought i1Display Pro (v. 3) I get broken TRC in most cases building 3xCurves+mtx profile type. It has a gap near white and profile test shows more than dE 1.0 (sometimes more than 4.0) color temperature bias. If I use ColorMunki I get this rarely (Munki is slow and noisy in blacks). I note, that ICC specifies curves only type for displays, so some software still don’t support LUT-based display profiles (most browsers in Win10 added LUT support in the past months, this could be influenced by Win10 upgrade release). Then I swith to XYZLUT+mtx. And I see gamut deformation and… different calibration curves! But, calibration sholud be named linerization, this is gamut-independant procedure, this only normalizes channels contrast to gamma function. Am I right? What’s wrong and why do I get the gap? Look at attached graphs. Yes, I use fixed color temperature and, usually, brightness, I use black autocorrection and I always set BPC, I use rel.colorimetric intent as default for XYZLUT.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Can this be caused by some overshoot/undershoot in your displays? If different patch charts are used by different settings maybe on smaller one you go from a color to another that has poor/bad color transition (overshoot/undershoot) while in bigger patch set jump from one patch to another is small enough.
You can try using same patch chart for both settings. For example set manually 175 patch chart (“default LUT” or “extended LUT” or someting like that) for 1TRC+matrix, 3TRC+matrix and XYZLUT, even make them share VCGT calibration (1st profile creates it, then for the 2 remaining profiles set all calibration tab as measured, when asked use current calibration curves).
This way differences in resulting 3xTRC stored for the last two profile types will be caused only by DisplayCAL/ArgyllCMS calculations and not by a possible TRC/overshoot issue in your displays.
If doing this test your issue is still preset you can provide full logs to ArgyllCMS mailist and report a bug. Otherwise is not possible to blame the true source of your issues (your HW or ArgyllCMS)Thank you, Vincent! I’ll try to do it. I used typical settings for 3xCurves and XYZLUT, so profiling patch sets were different, of course. I set display brightness between 120 and 190 cdm (rarely 210 cdm, once it was 230 cdm), so there’re should not be overexposure for light patches. Though, I will set low and high target brightness for tests.
Overshoot/undeshoot issues may happen at 50 or 120cd/m2 too. It’s a panel (pixel color transition) issue, not a backlight issue, you know:
Manufacturer tries to achieve lesser ms transition (to advertise it) beyond what panel can actaully provide without issues and those overshot undershoot errors appear.
IDNK if your displays have several “overdrive” configurations, somtimes they are fixed and cannot be solved, if you suffer them try “slow” setting on OSD.DisplayCAL’s colorimeter delay in readings may help too, but IDNK how it performs, I never used it.
Oh, if you mean undershoot is too small patch set – this doesn’t matter. For some displays DisplayCAL builds very good 3xCurves profiles, tests show a little difference to XYZLUT with 600 patches. In most cases though I see dE>2…5 for some dense colors (others are <= 1), so XYZLUT is used all in all.
