TRC gap using 3xCurves with i1d3 and different calibration for XYZLUT

Home Forums Help and Support TRC gap using 3xCurves with i1d3 and different calibration for XYZLUT

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #28200

    Алексей Коробов
    Participant
    • Offline

    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.

    Attachments:
    You must be logged in to view attached files.

    i1Display Pro on Amazon  
    Disclosure: As an Amazon Associate I earn from qualifying purchases.

    #28239

    Vincent
    Participant
    • Offline

    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)

    • This reply was modified 1 month, 1 week ago by Vincent.
    • This reply was modified 1 month, 1 week ago by Vincent.
    #28243

    Алексей Коробов
    Participant
    • Offline

    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.

    #28244

    Vincent
    Participant
    • Offline

    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.

    • This reply was modified 1 month, 1 week ago by Vincent.
    #28246

    Алексей Коробов
    Participant
    • Offline

    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.

    #28247

    Алексей Коробов
    Participant
    • Offline

    Hm, I usually change default 20 ms pixel change time to 43-44ms (like irregular step for old LCD). Probably, here’s the cause. I guess Munki and i1d3 have some different perception of panel.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS