trouble calibrating Eizo CG247x, Decklink, i1DPro

Home Forums Help and Support trouble calibrating Eizo CG247x, Decklink, i1DPro

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #29518

    Xavi Julia
    Participant
    • Offline

    Hi! I’m pretty upset with my new monitor and its calibration…

    I got it a few weeks ago together with a Decklink Mini Monitor card as my first reference monitor kit and been struggling to get it calibrated…
    The problem comes when trying to calibrate the monitor through DisplayCAL and i1DisplayPro with the monitor set to native gamut (not happening to set to rec.1886 but the accuracy on that mode is not the best).
    The result reminds me of a wrong levels setting, but that’s been checked and is not the case (I’ve tried all settings regarding levels). Image comes washed off after correction applied as a LUT on Resolve.
    Also, colorimeter correction is applied for the CG247x panel, I’ve tried many different and the result didn’t changed dramatically so that may not be the problem.

    I’ve tried many different settings and can’t seem to get to understand what’s going on and how to approach… Maybe some of you can shine a little light on it, I’ll be very grateful.

    Thank you,
    Xavi.

    settings on both monitor and resolve are: video/limited levels, RGB 444, gamma bt1886, custom whitepoint (checked through i1Dpro)

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

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

    #29523

    Xavi Julia
    Participant
    • Offline

    new test going full-on with full data levels RGB 444 on all settings and quite similar result…
    may it be a validation error?

    thanks,
    Xavi.

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

    Vincent
    Participant
    • Offline

    new test going full-on with full data levels RGB 444 on all settings and quite similar result…
    may it be a validation error?

    thanks,
    Xavi.

    Looks like you are applying a “native to sRGB” LUT3D (actually it works the opposite but just to simplify explanation) on an Rec709/sRGB mode in your monitor.
    Take a look on a*b* report 2D plot. Looks like user fault. It is desaturated twice.
    LUT3D should be applied on the OSD mode where it was made. Also check that you are not using some vendor/OS settings that translate all content on the fly to sRGB.

    Also it may be an issue of mismatch full vs legal range on some stage. This is easier to check: just send a full saturation 100% green and red patches to screen an measure them with ArgyllCMS spotread. Monitor should be on native gamut OSD preset. Compare measured coordinate from EDID or full native gamut green and red primaries coordinates. If there is desaturation, then there is something wrong in your HW+driver+OSD setup. You’ll need to fix this before proceeding with DisplayCAL.

    • This reply was modified 2 days, 8 hours ago by Vincent.
    #29578

    Vincent
    Participant
    • Offline

    “just send a full saturation 100% green and red patches to screen an measure them with ArgyllCMS spotread”
    I meant a video file through resolve and the decklink with no LUT3D applied.

    #29585

    Xavi Julia
    Participant
    • Offline

    new test going full-on with full data levels RGB 444 on all settings and quite similar result…
    may it be a validation error?

    thanks,
    Xavi.

    Looks like you are applying a “native to sRGB” LUT3D (actually it works the opposite but just to simplify explanation) on an Rec709/sRGB mode in your monitor.
    Take a look on a*b* report 2D plot. Looks like user fault. It is desaturated twice.
    LUT3D should be applied on the OSD mode where it was made. Also check that you are not using some vendor/OS settings that translate all content on the fly to sRGB.

    Let’s see if I understood correctly… I’m indeed applying a “native to sRGB” conversion in the LUT generated by displayCAL because I do the correction with gamut set to native on the monitor. What you suggest is that after calibration I may switch monitor settings to rec709 gamut? I’m actually changing no monitor setting from calibration to validation. (Only if I were to apply the LUT in CN7 instead of video monitoring in resolve, but avoided that method just to make sure not to add more possible errors.)

    It’s desaturated twice indeed… By OSD mode you mean the monitor setting, right? As I just mentioned, that should be the same as no setting was changed.

    a*b* report looks desaturated twice in the measurement report but not on the self check report… May that be because the problem happens when applying the 3DLUT or in the validation settings?

    I’ll now check the saturation test you mentioned. Let’s see if I got it right: I’m going to send 100% sat green and red patches (generated manually in resolve) with monitor set to native gamut (EDID?) and then read it with displayCAL and it should read 100% green and red, right?

    I believe I will see no desaturation here, cause out of the tests I’ve done, desaturation happened when applying 3DLUT, native gamut was very saturated (as you would spect).

    I also check how the results were with no calibration done to the monitor and gamut set to rec709 and it gave me pretty decent results with no “double desaturation” present. They were obviously not perfect, but much closer. That’s why I think the problem will have to be related to either the 3DLUT(expecting levels or video and receiving the other or something related to the LUT expecting a different kind of signal with different primaries or whatever…) or the validation settings.

    Thank you so much Vincent!

    #29588

    Vincent
    Participant
    • Offline

     

    I’ll now check the saturation test you mentioned. Let’s see if I got it right: I’m going to send 100% sat green and red patches (generated manually in resolve) with monitor set to native gamut (EDID?) and then read it with displayCAL and it should read 100% green and red, right?

    It should measure native primaries coordinates.  Compare them to EDID primaries or to the profile boundaries you used fro making the LUT3D. Shoudl be close within some small dE error

    #29600

    Xavi Julia
    Participant
    • Offline

    I didn’t even know what spotread was, but after some time I managed to run it, even add the spectral correction, these are the results (in XYZ coordinates):

    every setting in both monitor and davinci set to full range and RGB444, monitor gamut set to native, gamma set to 2.2

    BEFORE CALIBRATION (cg247x native gamut), as I could not find any info regarding the gamut’s primaries I could only look for them on color navigator where only X and Y coordinates are shown.

    GREEN TARGET (0.2104 0.7194)
    spotread measurement (19.988775 66.917062 5.446266)

    RED TARGET (0.6878 0.3096)
    spotread measurement (52.476452 23.638673 0.066774)

    (values are exactly as CN7 shows them, seems like they’ll have to be multiplied by a 100 to match those from spotread)

    AFTER CALIBRATION (REC1886):

    LUT gamma set to rec1886 and gammut rec709 (all settings on Resolve template in displayCAL by default except colorimeter correction and number of patches, set to 175) lut applied in davinci.

    GREEN TARGET (38.5647 71.7164 9.7728)
    measurement report (49.6512 74.2976 14.2071)
    spotread measurement (36.9891 72.1408 11.8736)

    RED TARGET (43.6517 22.3199 1.4658)
    measurement report (33.1572 18.9571 3.1201)
    spotread measurement (42.4316 21.2111 2.3934)

    what seems odd is that “spotread” and “validation” (in displaycal) measurements do not match. I’ve attached both the validation measurement and the self check report

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

    Vincent
    Participant
    • Offline

    You’re mixing different set of coordinates. CIE xy vs CIE XYZ. Get an online converter or read tehir definition. A fast check on green seems that it’s on spot so OK.

    Also measurement report is PCS translated, you have to translate it to actual white point readings (abs). That’s the reason to use spotread since it’s faster. Spotread can be configured to return CIE xyY.

    #29609

    Xavi Julia
    Participant
    • Offline

    Ok thanks for helping me dive into all this technical terms… Other than that, results seem good, right?

    I don’t exactly understand what PCS (profile connection space right?) does and how to translate it to white point readings, may it have something to do with the option on the “validation” window called “Simulation Profile”? And then deactivating that would avoid PCS translation?

    Does that mean that the measurement report is set to report something different and the actual calibration is good?

    #29611

    Vincent
    Participant
    • Offline

    Ok thanks for helping me dive into all this technical terms… Other than that, results seem good, right?

    Your Resolve setup is still wrong once applied LUT3D,  maybe you set them twice.

    Im my previous message I just said that  CIE XYZ -> CIE xyY native green looks like native green should be.

    I don’t exactly understand what PCS (profile connection space right?) does and how to translate it to white point readings, may it have something to do with the option on the “validation” window called “Simulation Profile”? And then deactivating that would avoid PCS translation?

    Does that mean that the measurement report is set to report something different and the actual calibration is good?

    PCS is lingua franca for all profiles. Check absolute in report HTML move to xyY or XYZ and you’ll see measured values with no translation.

    #29617

    Xavi Julia
    Participant
    • Offline

    Your Resolve setup is still wrong once applied LUT3D,  maybe you set them twice.

    Im my previous message I just said that  CIE XYZ -> CIE xyY native green looks like native green should be.

    Ok but then what about spotread’s measurement? That looks as if it was good, doesn’t it?
    That’s the thing, I still don’t understand why they show different readings.

    I think the problem with the 3DLUT might not be it applied twice, cause I’ve tried applying it both on resolve and color navigator, checked many times and always happens the same… So maybe it’s something with the 3DLUT settings, but I’ve tried almost all combinations (different in/out levels, vcgt on and off…) and I always get the same result.

    May it have something to do with the “Simulation profile” setting under Validation? What does it exactly do?

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

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS