3D Lut Verification

Home Forums Help and Support 3D Lut Verification

This topic contains 60 replies, has 2 voices, and was last updated by  anonymous SourceForge (@anonymous-sourceforge) 4 years, 4 months ago.

Viewing 15 posts - 46 through 60 (of 61 total)
  • Author
    Posts
  • #577

    Florian Höch (@fhoech)
    Administrator
    • Offline

    Ok. So basically I shouldn’t use the monitor profile.

    Photoshop will automatically use the monitor profile.

    But will it work with D50?

    Yes. This is basically an implementation detail, but device-independent (CIE XYZ or Lab*) color values in ICC profiles are always stored chromatically adapted to D50. This allows linking of profiles through the common PCS (profile connection space) without having to worry about whitepoint differences. It’s also important to note that this will still yield the correct result if the monitor has a non-D50 whitepoint e.g. D65.

    I still have the Rec.709 synthetic profile from DCG, could I use that?

    Presumably not, because it’ll have a D65 whitepoint that leads to the Photoshop TRC “feature” I described.

    “Use the embedded profile (instead of the working space)”

    Yes, don’t assign anything, open with embedded profile.

    #578

    Okay, I get it.
    I got your profile in your edited post, so I will use that and report back.

    Thanks again

    #579

    Ok, I tried with a couple of movie stills, put them in full screen in both apps, and I am absolutely not able to see the switch from Photoshop to Speedgrade. So, that’s great.

    Now, I’ve also tried your pic:

    • When I open it in PS using your embedded color profile, it’s Red.
    • When I assign the Rec 709 D50 Profile, it turns blue.

    If I import it in Speedgrade, it’s blue.

    What does that mean?

    #580

    Florian Höch (@fhoech)
    Administrator
    • Offline

    When I assign the Rec 709 D50 Profile, it turns blue.

    Don’t 🙂 The picture is specifically crafted so it’ll only look correct (red) if the embedded profile is kept.

    If I import it in Speedgrade, it’s blue.

    That would indicate Speedgrade is not employing ICC color management.

    #581

    Right… so it’s not employing ICC color management, but that’s not a problem since I’m not relying on ICC profiles inside Speedgrade, correct?

    #582

    Florian Höch (@fhoech)
    Administrator
    • Offline

    Right… so it’s not employing ICC color management, but that’s not a problem since I’m not relying on ICC profiles inside Speedgrade, correct?

    Correct. The monitor is (through its internal calibration) set up to match Rec. 709 gamma 2.2, so as long as that matches the video material you have in Speedgrade all should be fine.

    • This reply was modified on 2015-05-21 00:47:43 by fhoech.
    #583

    Well, correct me if I’m wrong, but the monitor is set to Rec. 709 not through its internal calibration, but thanks the DCG ICC profile I applied?

    #584

    Florian Höch (@fhoech)
    Administrator
    • Offline

    The last report you attached was against Rec. 709 2.2 (target identical to simulation, so monitor profile only taken into account to calculate black output offset), and showed that it matched very well. So that was a verification of the internal calibration.

    In any case, a very good result.

    #585

    Oh, okay, I didn’t know that.

    But just to clarify, the measurements evolved for the better as I created new ICC profiles in DCG. It also tested much better in Calman who only takes into account the colors on screen, through the active ICC, right?

    So I’m trying to make sure that although Speedgrade does not employ ICC color management, the picture it’s displaying is 100% seen through the active ICC.

    #586

    Florian Höch (@fhoech)
    Administrator
    • Offline

    But just to clarify, the measurements evolved for the better as I created new ICC profiles in DCG. It also tested much better in Calman who only takes into account the colors on screen, through the active ICC, right?

    Yes. The improvements you’ve been seeing are likely through the 1D LUT calibration curves of the profile you’ve created in DCG, because these are globally active through being loaded in the video card.

    #587

    Okay, I see! So when we were talking about color management in different apps, we were talking INSIDE the app itself. In terms of viewing, whether or not an app employs color management, it will still be seen through the DCG curves of the video card.

    #588

    Florian Höch (@fhoech)
    Administrator
    • Offline

    Yes, that seems about right.

    #589

    Ok, thanks. That red picture turning blue gave me a fright 🙂

    #549

    Great, I will give it another go with LCD RG Phosphor.
    Another possible correction I have is LCD RGB LED.

    Yes, I’m now doing hardware calibration, white point and luminance on target, then profiling and got much better results. I’ve posted the whole process on this thread.

    Many thanks for your help
    Jeremy

    #550

    RGBLED is not for your display. It was used in some widegamut LED displays like old HP 2408zx but was abbandoned due to the higher cost. All manufacturers moved to AH-IPS GBLED (blue green led with red phosphorus, like yours) for widegamut LED monitor.
    If you use that RGBLED correction and you have a screen with very good uniformity (no “green tint” zones) its very likely that you’ll end with a little pink white after a calibration. As a side effect if you validate a profile or hardware calibration which is “near perfect” D65, using a RGBLED spectral correction will point to a “fake” greener-white.

    You should use proper spectral correction in DCG for a GB-LED display, not a CCSS file that “lowers” the error made by Color Navigator (like your former choice of WG CCFL). Otherwise it’s like cheating in Solitaire.
    Current Eizo Colornavigator (CN) support for i1D3 is based on an outdated version 0.9 of Xrite’s SDK (current is 2.5.x) with builtin corrections. LG (very poor implementation without GB-LED support), NEC, Dell, Basiccolor and Xrite’s approach for calibration relies on updated SDK version and EDR binary spectral corrections. I’m more confident in this way (which is a limited version of what ArgyllCMS CCSS allow us to do) than in CN “hidden” corrections.
    So if using RG_phosphor or Eizo CX271 CCSS from DispcalGUI colorimeter correction database points to a white further from D65 than other CCSS, then take it as fact (a very highly probable fact) and CN hardware calibration failed there.
    1-3dE errors in white but “accurate” gamut calibration and neutral grey have been seen in other HW calibration process like in Dells, maybe it’s is caused by software fixing brightness target after monitor LUT was wrote.
    Eizo CN has a feature to manually move a/b coords for white in ColorEdges after internal LUT calibration (I think it’s called “white paper visual match” or something like that). Since you can properly measure CN “white” and a “true” D65 white (RGB gain controls in CS240 custom/user mode) with ArgyllCMS+DispcalGUI, it should be easy to fix CN’s white point drift from D65 (inverse ab coords shift) … but only if that slighty high dE in whites issue bothers you.

Viewing 15 posts - 46 through 60 (of 61 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS