- This topic has 53 replies, 4 voices, and was last updated 9 months ago by
.
-
Posts
-
The initially uploaded 3D LUT is almost neutral when it comes to greys, except in the dark region where it reduces the blue level (see chart).
This can be however removed, resulting in a 3DLUT with neutral greys. Does this one measure better in your setup?
CN7 HW CAL to D65 Rec709 is excellent, use it as is: CAL5 or whatever you called it, no LUT3D in resolve or lutbox, plug to decklink use it.
Regarding the grey range issue you may want to comment it in ArgyllCMS mail list indicating that you tested with typical XYZLUT profile but also witha single curve matrix profile that you tested to have a perfect neutral grey and display matches that profile. So… where are these errors coming from?
I want to try this on my computer bc I seen no such grey range errors… but I did not make them with 3.4.x, maybe there is an issue that was not before.
Anyone who read this may try it if you have a display with HW cal that have excellent grey ramp response. Also anyone who needs VCGT calibration and got excellent grey range results on older ArgyllCMS, try it now.
IF this (https://hub.displaycal.net/forums/topic/cg2420-calibrating-using-stuart-pointons-cs2731-edr/page/3/#post-144543)
is show through ‘Blackmagic SDI to HDMI micro converter 12G’ and LUT3D was created with 1single curve + TRC, then the culprit is LUT3D/DeviceLink file.Yes this is measured through the same pipeline as mentioned above (Mac – Decklink – BM LUT box – Eizo)
But this is very strange. Which ArgyllCMS version were you using, x64 macoS, x86 win, x64 win?
Windows 11, DisplayCAL 3.8.9.3, Argyll V3.4.0
Test1 )As I said on my previous message , create a CAL5 os something like that where you simulate Rec709 primaries with CN7 instead of native, to check if you can work without LUT3D at all. In my experience with ColorEdge CS models that also use lut-matrix-lut hardware instead of a true LUT3D it should be very good Rec709 simulation regardless of that Colorspace sales department say.
Yes I have a CAL already clipped to Rec709 and it looks good. See attached verifications
BTW, to test CN7 hardware calibration to Rec709 it is not done that way.
You tested if custom matrix profile matches HW calibration, which is useful to use that profile as an input for LUT3D creation:
https://hub-assets.displaycal.net/wp-content/uploads/users/rich-lapthorn/2025/08/27/No-simulation-profile-No-LUT-in-LUT-box-Measurement-Report-3.8.9.3-%E2%80%94-Resolve-%E2%80%94-2025-08-27-20_16_47.htmlBut to validate if HW calibration to some known colorspace liek Rec709 is OK, you should do:
-CN7 to rec709 D65 g2.4 100nit, or whateever you set for brightness and gamma.
-No lut in lutbox or resolve, no use macOS profiles for resolve
-in DisplayCAL, use simulation profile as display profile, rec709 and your gamma (usually 2.4 relative black output 100%), no device link. (you skiped this last part in your report)If this results in a very good matching with Rec709 g2.4 you can use it as is. No lut3d at all.
You can also use this setting to validate any other HW calibration like AdobeRGB (2.2g), sRGB with sRGB TRC or DisplayP3. Just change simulation profile and target TRC.
Oh right so maybe I have been doing it wrong?
To test the hardware calibration this was my process:
- CN7 to rec709 D65 g2.4 100nit
- No lut in lutbox
- in DisplayCAL, no simulation profile and no device link
To test the LUT in the LUT box I did this:
in DisplayCAL, simulation profile as display profile (2.4 relative black output 100%) and no device link
To simulate the LUT I did this:
in DisplayCAL, simulation profile as display profile (2.4 relative black output 100%) and device link
Is any of this correct?
Oh right so maybe I have been doing it wrong?
To test the hardware calibration this was my process:
- CN7 to rec709 D65 g2.4 100nit
- No lut in lutbox
- in DisplayCAL, no simulation profile and no device link
This way you test if the custom profile made by DisplayCAL or CN7 matches the display. This is a requirement for making a LUT3D, destination profile (the custom profile you made) must describe accurately display.
It is a valid test but it is not useful to test what you want.To use HW calibration in resolve with no LUT3D at all, like if you had
“a perfect monitor that behaves exactly as Rec709 g2.4”, you want to test if HW calibration matches Rec709 g2.4. So you :
use simulation profile rec709, use it as display profile, and choose your gamma (usually 2.4 relative black output 100%), no device link.This test is a pure HW cal or factory preset validation to some known colorspace.
Do you see the difference between validating against a custom profile versus a known colorspace?
1st one (what you did) is a requirement for ICC color management to work as expected (Photoshop, or Resolve if you use “use macOS profiles for Resolve”), or to make accurate LUT3D.
2n one (My message) is just validating if display, as is, with whatever factory preset or HW calibration loaded, matches some known colorspace.Only the 3rd step changes.
-When you were making a LUT3D for CN7 at native colorspace you to do the 1st one as a test to validate that such custom profile is a valid input for LUT3D maker (since such LUT3D is not working as you want, so you want to find which step is causing the issues => validate if cutom profile is accurate).
–But if you are using *only CN7* to calibrate to Rec709 you need the 2nd one.To test the LUT in the LUT box I did this:
in DisplayCAL, simulation profile as display profile (2.4 relative black output 100%) and no device link
That’s OK.
To simulate the LUT I did this:
in DisplayCAL, simulation profile as display profile (2.4 relative black output 100%) and device link
That validates device link, ICC equivalent to LUT3D. It’s is the same as “To test the LUT in the LUT box I did this”, but instead a LUT3D you use a device link.
Is any of this correct?
Ok, I THINK I understand
The method you are describing only works if the display is set to be Rec709 right? So I am comparing what I think the monitor should be via my CN7 profile to a simulated Rec709 profile in Displaycal
I think I had confused myself as previously I have been working with the display in it’s native state and not clamped to a colour space and the above process would not have worked
To verify the display do I always need to profile it in Displaycal first? The measurement report button is always grayed out unless I select an ICC or ICM in the settings
To verify the display do I always need to profile it in Displaycal first? The measurement report button is always grayed out unless I select an ICC or ICM in the settings
On macOS always bc some weird bug/feature… it should not be needed on all cases, but that’s the way it is right now.
On Windows with old displaycal (3.8.9.3) when validating a monitor connected through your AMD/nvidia, no, or just 1st run. You choose “<Current>” on top combo box and this way you can validate current display profile, like the icc profiles created by CN7 or i1Profiler or basiccolor display or Benq Palette Master Ultimate or whatever.
On Windows when validating Resolve output, yes, you need a base profile created with DisplayCAL, bc some weird bug or “feature”… it should not be needed on all cases, but that’s the way it is right now. So a quick matrix+single curve profile like you did will do the job (do not install it, just choose it from the middle upper combo where you can switch calibrations).
When you choose “use simulated profile as display profile”, your custom profile will be ignored.
When new DisplayCAL (Erkan’s port to python3) becomes more usabe under Windows maybe we should request to simplify these verifications.An alternative way to verify is HCFR, an open source CalMAN-like, but as Calman it does not evaluate a*b* grey range in a single number so you can evaluate how things are.
Preferences/Reference display gamma + black compensation, input offset =100%. This should be close to Calman’s Rec709, D65, power law 2.4gamma. And close to DisplayCAL verification simulate proile + use simulation profile as display profile, Rec709, gamam 2.4 relative black output 100%.
HCFR is more useful for TVs, dealing with 6 axis CMS for primaries and 10 point grayscale, in case you need to setup some WOLED TV.
Remember to use same CCSS in HCFR as you did with DIsplayCAL.When you choose “use simulated profile as display profile”, your custom profile will be ignored.
So if the custom profile is ignored… can I just chose any old profile rather than generate a new one?
I have done a proper verification of the display now with the settings as discussed
- CN7 to rec709 D65 g2.4 100nit
- No lut in lutbox
- in DisplayCAL, simulation profile as display profile and no device link
report attached
When you choose “use simulated profile as display profile”, your custom profile will be ignored.
So if the custom profile is ignored… can I just chose any old profile rather than generate a new one?
For HW cal yes, choose the XYZLUT or single curve matrix, asi you did for this report. Choosing one is just for “unlocking” the measurement report button.
It’s a bug or maybe a feature related to HDR LUT3Ds where brightness is absolute so profile must inform about actual brightness to compare results and those things… but I do not remember very well the reasons to be locked unless a profile is chosen.I have done a proper verification of the display now with the settings as discussed
- CN7 to rec709 D65 g2.4 100nit
- No lut in lutbox
- in DisplayCAL, simulation profile as display profile and no device link
report attached
Nice HW cal, use it as is.
AFAIK OSD controls for limited HDMI range and such are independent of HW cal, so you can switch between 0-255 and legal levels without recalibrating… or at least all Coloredge CS models I have used work this way.
