- This topic has 53 replies, 4 voices, and was last updated 9 months ago by
.
-
Posts
-
Understood! So do a verification of the calibration before I load the LUT into resolve and see if it shows better results than after I add the LUT
Just greyscale color. Easiest way is to verify against profile generated by CN7 (not by displayCAL)… but on macOS this is not easy.
Maybe creating a “profile only” matix profile on macOS (by selecting all target as measured in calibration tab and disabling interactive popup).If you can use a windows latop it would be easier.
If that does show better results then is this just something I would need to accept as part of the process?
Or maybe there is something that is messing things. Check TRCs on custom XYZLUT profiles.
On another note, is there a way for me to use DisplayCal to verify my CN7 calibration with internal probe? It would be nice to compare the two and see if there is a worthwhile improvement.
AFAIK there is no ARgyllCMS driver.
Did you try getting the greyscale as close as possible to the reference using OSD controls before doing the LUT?
@Vincent
I have realised I am getting a noticeable green tint in my greyscale!It appears to be in the calibration before I get to the LUT. I’m not seeing the same tint when using the internal probe with CN7
This is making me think there is either an issue with Stuart’s EDR or there is a drift in my i1D3
I did a verification last night (attached) and I thought it looked pretty good, but when I look at a greyscale ramp the green tint is obvious to my eye
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Did you try getting the greyscale as close as possible to the reference using OSD controls before doing the LUT?
HW cal through ColorNavigator7. Maybe it has no access to OSD RGB gains at all.
@Vincent
I have realised I am getting a noticeable green tint in my greyscale!green tint in “all” greyscale? (your new issue) is not the same as bad a*b* grey range (1st issue) which menas that greys have different color tint between them
It appears to be in the calibration before I get to the LUT. I’m not seeing the same tint when using the internal probe with CN7
This is making me think there is either an issue with Stuart’s EDR or there is a drift in my i1D3
I did a verification last night (attached) and I grey calance thought it looked pretty good, but when I look at a greyscale ramp the green tint is obvious to my eye
No, did the test I suggested, which i am not seeing in your post.
Issues must be isolated, not added with whetever misconfiguration you may have:Plug CG2420 to computer if it was not (no decklink, no external lut3d), Do the following HW cals (use other tahn 1 or 2 if you have them used )
CAL1 = Rec709, D65, use internal probe, and use “color managed” colorimeter correction (= factory matrix correction for internal probe), bc it needs it
CAL2 = Rec709, D65, use i1d3, and use “no compensation” colorimeter correction (= RG phosphorEDR), bc it needs it
Now on OS, not in resolve, validate those calibrations with i1d3 and WLED PFS CCSS correction. Easier with a windows laptop due to macOS limitations with Displaycal.
Watch for WP deviations and choosing “RGB + greyblance” on HTML report upper combo check “combined a*b* grey range” (if greys have different color tint, your 1st issue).WP “visual” deviations can be caused by wrong correction, i1d3 firmware not matching its actual behavior (what you called “drift”) or just because you and CIE 1931 2deg std observer do not match where these WLED PFS red spectral peaks arise (or green / blue broad spikes).
Usually this last one is solved by choosing a visual matching white xy coord instead of D65 as in any other calibration software (calman, colorspace, CN7…)All coloredges should have a pristine a*b* grey range out of the box, bc it is a QC factor (you pay for excellent deltaC color uniformity, neutral grey and HW cal, in that order). So first you verify this and once you are sure that monitor is well behaved then you can search where that grey range of your 1st calibration report comes from.
Isolate issues, skip resolve, do not add more nodes to pipeline that may mess things. Test CN7 calibration on OS as regular monitor, full range signal or even better, use USB-C/DP.
Test display “alone”.Numbers do not tell the whole story. A new calibration after a long warm up might help. Red really crashes from 15 to 0 percent on the white balance. The 5% needs a little red and it will bring up the 10%. The dipping of red and blue is causing green to show. Is it the meter or is it the speed of the reading wrong or the display? Doing tests with something else proves its not the screen.
Plug CG2420 to computer if it was not (no decklink, no external lut3d), Do the following HW cals (use other tahn 1 or 2 if you have them used )
CAL1 = Rec709, D65, use internal probe, and use “color managed” colorimeter correction (= factory matrix correction for internal probe), bc it needs it
CAL2 = Rec709, D65, use i1d3, and use “no compensation” colorimeter correction (= RG phosphorEDR), bc it needs itOk, so firstly I have moved everything over to a Windows device, connected the monitor directly (HDMI) and I have done a CN7 calibration with the internal probe in one slot (colour managed) and then a another calibration in a second slot using CN7 and the iD13 (no compensation)
Both calibrations are clamped to BT.709
Now on OS, not in resolve, validate those calibrations with i1d3 and WLED PFS CCSS correction. Easier with a windows laptop due to macOS limitations with Displaycal.
Watch for WP deviations and choosing “RGB + greyblance” on HTML report upper combo check “combined a*b* grey range” (if greys have different color tint, your 1st issue).Now this is where I’m a little unlear. To validate the two CN7 calibrations do I just select ‘LCD PFS Phosphor WLED family’ under correction and then untick ‘simulation profile’ on the verification tab? If I do this the white point is miles off on both, but grey balance is significantly better than my previous calibrations. I have attached them both below
check “combined a*b* grey range” (if greys have different color tint, your 1st issue).
I don’t see this option on the report
Test display “alone”.
I’m not quite sure what you mean by this. As in no deckling or Resolve etc?
So what is my next step?
Ok, I think I was using the wrong correction when validating the CN7 with i1D3 calibration!
I just tried the ‘LCD PFS Phosphor WLED IPS, 98% Adobe RGB/96% P3 (HP DreamColor Z24x G2) and the results were significantly better across the board (see attached)
I also tested the same HP Dreamcolor correction with my original calibration that I had set up on the Mac with CN7 and i1D3 and the results for that were even better!
So as I am getting much better results connected directly to a Windows device, what does that tell us?
Ok, I think I was using the wrong correction when validating the CN7 with i1D3 calibration!
I just tried the ‘LCD PFS Phosphor WLED IPS, 98% Adobe RGB/96% P3 (HP DreamColor Z24x G2) and the results were significantly better across the board (see attached)
I also tested the same HP Dreamcolor correction with my original calibration that I had set up on the Mac with CN7 and i1D3 and the results for that were even better!
So as I am getting much better results connected directly to a Windows device, what does that tell us?
Differences between HP Z24x G2 and Stuart’s CG319X CCSS should be minimal in white point and none when evaluating grey range a*b* bc if greys have the same color a “wrong” correction will measure the same “wrong” grey shade from black to white.
different CCSS/EDR with the same spectral signature (plot them with “specplot “) => white point, just that.
Now regarding grey a*b* range. Results from HW cal are excellent as expected for any ColorEdge. So the problem is not the display or HW cal.
Try to validate in macOS ***without any LUT3D*** through resolve. IDNK if you use a decklink card or you use it in macOS as any other monitor.
If you use it with a decklink try to validate first as a GUI monitor connected directly to mac, then through the card.
Try to isolate the point in the pipeline that introduces that slightly colorartion in greyscale for a*b*Thank you, that’s a relief to know there isn’t an issue with the monitor and that I have a decent HW calibration. Now to work out where the weak link is.
Could you help me clarify the next steps?
1. I reconnect the Monitor to the Mac, but without the decklink, so just as a secondary monitor
2. How do I validate this on the Mac? Do I need to run a calibration in Displaycal before I can Validate? Or can I just go straight to the verification tab?
3. Once (if) I have a successful verification connected directly to the Mac (No LUT) I connect the Monitor back to the decklink and do another verification
Does that sound about right?
So as instructed I connected the Monitor directly to the Mac via HDMI and did another verification. I unticked simulation profile, is this correct?
The grayscale results were outstanding!
I then re-attached the monitor to the decklink and in Displaycal unticked ‘interactive display adjustment’ and ran a short ‘XYZ LUT and matrix’ profile (This was necessary to run a verification through Resolve) and once again did a verification with ‘simulation profile’ un-ticked.
This time grayscale isn’t quite as good as the previous verification when connected directly to the Mac, but it is still very, very good at around 0.6 delta E
So I think this is great news right? If I can see these numbers via the decklink then does this mean the problem must either be with my Displaycal calibration or my LUT?
It feels like I’m getting close
2. How do I validate this on the Mac? Do I need to run a calibration in Displaycal before I can Validate? Or can I just go straight to the verification tab?
On windows you can directly test current display profile, even if it was not made with DisplayCAL.
On current macOS version it does not work, you can open an issue in its github.The easiest way as I posted before is to create a “single cuve + matrix prfile” in display cal with all calibartion tab set “as measured” and interactive display adjustment disabled, so it won’t create a custom VCGT calibration, using display as is.
If you use an XYZLUT, but all other settings as above, it will create a profile with 3 TRC instead of an idealized a*=b*=0 grey.
Edit: anyway, the XYZLUT profile you created is almost a*b* = 0 so no need to create a new one. Also if you choose “Evaluate gray balance through calibration only” in HTML Report it will evaluate grey vs ideal a*b*=0
This time grayscale isn’t quite as good as the previous verification when connected directly to the Mac, but it is still very, very good at around 0.6 delta E
So I think this is great news right? If I can see these numbers via the decklink then does this mean the problem must either be with my Displaycal calibration or my LUT?
Try to create a LUT3D with this “Resolve_2025-08-24_20-30_S_XYZLUT+MTX.icc” with standalone app (Windows), I do not remember if newer DisplayCAL for macOS has an standalone app for LUT3D creation. Maybe you can do it through DisplayCAL UI, I’ve not used those LUT3D creator oprtions in macOS.
It’s grey is near perfect so when computing LUT3D and applying a minimum gamma correction it should not change grey color.Not quite sure how to use the standalone ‘Create 3D LUT’ app on Windows
I load my ICC profile but it also asks me to select a destination profile ICC profile. Any idea what I’m selecting here? I can’t seem to find any documentation on the standalone app to guide me
There is also no option to select any specific colourspace, therefor my native gamut profile can’t be clipped to rec709
Am I doing something wrong here?
Oh right, so I select Rec709 as source and then my icc profile as the destination?
