- This topic has 53 replies, 4 voices, and was last updated 9 months ago by
.
-
Posts
-
Yes, as DaniJ explained your content is encoded as numbers in source colorspace, and you need to re encode in other numbers that have the “same color” in your display native colorspace.
Ok so I am getting exactly the same problem with poor grayscale when using the standalone LUT creator
In fact it is now very easy to A/B a verification with and without the LUT being active in the same pipeline (Mac – Decklink – BM LUT box – EIZO CG2420) simply by switching the LUT on and off in the BM micro converter software
Without LUT active my grayscale average is 0.12 and the combined is 0.4
With LUT active my grayscale average is 0.55 and the combined is 1.53
In fact the only thing that has improved is the Max Delta E
It’s starting to look like the process of making the LUT is significantly affecting the grayscale measurement
To try and ensure this isn’t user error I am sharing screen shots of my process. Can you confirm whether or not this is correct?
I’m running out of ideas
You mentioned earlier in our conversation that this could be rounding errors. Is that now looking likely? It seems severe!
If that is the case then are we entering the territory of it being better to not apply a LUT at all?
Instead of activate LUT3D (“.cube”) in Resolve, activate “device link” (ICC equivalent to LUT3D between colorspace A to B) in DisplayCAL verification.
If there is some kind of issue in LUT3D calculation, it should be there too.
Also did you try several resolutions like LUT3D? like 17 vs 33. IDNK max mesh resolution for Resolve, maybe others know. Typical LUT3D portable to HW cal in CG-X eizos is 17x17x17 but IDNK how large it can be running on Resolve (computer)Instead of activate LUT3D (“.cube”) in Resolve, activate “device link” (ICC equivalent to LUT3D between colorspace A to B) in DisplayCAL verification.
If there is some kind of issue in LUT3D calculation, it should be there tooI did a verification with device link and strangely the results were better! Although still much worse than without any LUT. I have attached verifications without the LUT, with the LUT and with device link
Instead of activate LUT3D (“.cube”) in Resolve, activate “device link” (ICC equivalent to LUT3D between colorspace A to B) in DisplayCAL verification.
If there is some kind of issue in LUT3D calculation, it should be there too.Resolve software accepts 65 x 65 x 65 LUTS, however I am not loading the LUT Into Resolve, (I have tried using Resolve and the results are the same) instead I am using the ‘Blackmagic SDI to HDMI micro converter 12G’ which allows the use of 33 x 33 x 33 LUTS. I did test 17 x 17 x 17 LUTS as well, however the differences were negligible.
If you attach the profile & the LUT I can take a look for obvious errors.
Thank you!
I have attached the ICC profile and the LUT (renamed to .txt for sharing on this forum)
I’m quite confused about how to proceed! Is this looking like a limitation of using Displaycal with devices that have highly accurate gray balance?
It seems I can either go with a hardware calibration on it’s own and have great gray balance but poor colour accuracy, or a Displaycal calibration with poor grey balance and good colour accuracy. Would you consider the inaccuracies in the grey balance to be more of an issue than the colour?
I’m also confused by the fact the device link verification looks different to verifying with the LUT on. Should they not be very close, if not identical?
I’m still hoping there is an element of user error going on here and that this is fixable, however it’s not looking like it right now
Just for testing purposes create a single curve+matrix profile withput bpc and feed that to LUT3D creator.
Since a matrix profile only stores info about primaries and grescale gamma it “disables” the purpose or a LUT3D where you have a mesh with actual display behavior, but my guess is the culprit are the tiny (very tiny) variations in a*b* =/= 0 for grey stored in the 3 TRC in XYZLUT profile. I may be wrong, hence the testing I request.
Or a simpler XYZLUT with <500 patchesIt seems I can either go with a hardware calibration on it’s own and have great gray balance but poor colour accuracy, or a Displaycal calibration with poor grey balance and good colour accuracy. Would you consider the inaccuracies in the grey balance to be more of an issue than the colour?
BTW IDNK what you call “poor color accuracy” of CN7 HW cal to Rec709, I do not remember a “bad report”. I checked this thread and I do not find it.
= connect to computer, as regular display, calibrate CN/ rec709, validate. Can be easily done with windows laptop.
The only report you did was in native gamut (bc you were going to create a LUT3D)
https://hub-assets.displaycal.net/wp-content/uploads/users/rich-lapthorn/2025/08/24/Verification-2-Measurement-Report-3.9.16-%E2%80%94-CG2420-@-1920-0-1920×1200-%E2%80%94-2025-08-24-201636.html
But you did not test WITHOUT decklink if lut-matrix-lut hardware inside CG2420 can simulate Rec709 properly.Also maybe the culprit is your decklink, or its configuration, or some mismatch between display and decklink output.
Hence you should do your LUT3D test WITHOUT the decklink, using the LUT3D in resolve and display plugged to computer as regular display.
If it is fine this way… DisplaCAL is not to blame. The “noise” is added by card or by some conversions done in the card or mismatch between display and card i/oAs said many times, to not add “external noise”, isolate each component testing the best you can, otherwise you are seeing a chain of errors accumulated by each stage.
Just for testing purposes create a single curve+matrix profile withput bpc and feed that to LUT3D creator
The results were almost identical to using an XYZ LUT and matrix.
I have shared three verification reports:
- No LUT in LUT box, no simulation profile
- LUT in LUT box and simulation profile
- Device link profile, no LUT in LUT box
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.But this is very strange. Which ArgyllCMS version were you using, x64 macoS, x86 win, x64 win?
Last test:
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.
Test 2) Use “colorimetric relative” instead of “absolute colorimetric” for LUT3D creation and use the “single curve matrix profile” you made earlier. So both colorspaces will have neutral grey by TRC and no whitepoint recalculation will be done. Your CN7 whitepoint is on spot, so no further correction by LUT3D is needed.
If test 2 fails maybe you want to report this unusual “collink” behavior to ArgyllCMS list. Collink is teh actual tool that calculated LUT3D and device links. DisplayCAL is a graphical user interface.
Also if test 2 fails then ALL WE should be able to reproduce this issue on our computers with that particular ARgyllCMS version you are using…If test 2 goes very good, then do the same with your XYZLUT profile, use “colorimetric relative” and test validation report.
BTW IDNK what you call “poor color accuracy” of CN7 HW cal to Rec709, I do not remember a “bad report”. I checked this thread and I do not find it.
Apologies, that was a poor choice of words. I only meant the colour accuracy measures better after a Displaycal profiling. I have done numerous tests over the past couple of weeks and it’s quite possible I didn’t share it on here. To clarify I meant using CN7 with the iD13 to calibrate the device to a clamped Rec709, profiling it in Displaycal and then verifying it with simulation profile switched off (This is measurement of the CN7 calibration only, correct?) and then comparing that verification to one with the simulation profile on and the LUT loaded in the LUT box. In this comparison the colour accuracy seemed better once the LUT was applied. Please let me know if I am confused and using the verification tab incorrectly?
But you did not test WITHOUT decklink if lut-matrix-lut hardware inside CG2420 can simulate Rec709 properly.
As explained above, I believe I have but I am happy to do it again and share the results for clarification. Again please correct me if I am misunderstanding you?
Also maybe the culprit is your decklink, or its configuration, or some mismatch between display and decklink output
I thought we could discount that as I can profile the display and then do a verification with ‘simulation profile’ turned off and the RGB gray balance measures around 0.6. This is using the Mac – Decklink – LUT box (No LUT) – Eizo pipeline (see attached verification)
Hence you should do your LUT3D test WITHOUT the decklink, using the LUT3D in resolve and display plugged to computer as regular display.
If it is fine this way… DisplaCAL is not to blame. The “noise” is added by card or by some conversions done in the card or mismatch between display and card I/oLet me do this right now, so that we can confirm the issue is not only coming from the Decklink – LUT box pipeline
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
Test 2) Use “colorimetric relative” instead of “absolute colorimetric” for LUT3D creation and use the “single curve matrix profile” you made earlier. So both colorspaces will have neutral grey by TRC and no whitepoint recalculation will be done. Your CN7 whitepoint is on spot, so no further correction by LUT3D is needed.
Using my native cal again right?
I did a single curve and Matrix profile (No BPC) with an as measured calibration, but the results are similar to all the other tests I have done so far
Verifications are attached as well as my .icc profile and my 3D LUT (renamed to .txt)
If test 2 fails maybe you want to report this unusual “collink” behavior to ArgyllCMS list. Collink is teh actual tool that calculated LUT3D and device links. DisplayCAL is a graphical user interface.
Also if test 2 fails then ALL WE should be able to reproduce this issue on our computers with that particular ARgyllCMS version you are using…So that’s a fail then right?
