- This topic has 53 replies, 4 voices, and was last updated 9 months ago by
.
-
Posts
-
Hi Folks,
I have an EIZO CG2420 that I’m using as a reference monitor for Davinci Resolve. I’ve used CN7 and the probe on the CG2420 to do a basic calibration that looks good, but I’m acutely aware that using DisplayCal with an i1D3 to generate a 3D LUT has the potential to give better accuracy.
Having read through a number of forum posts both here and on Lift Gamma Gain, I think I know what I need to do and I understand the importance of matching the correction file on both DC and CN7 to create a level playing field. I have Stuart’s CS2731 EDR and I have converted it to a ccss in DisplayCal using the ‘Import colorimiter corrections from other display profiling software’ It shows up under corrections as LCD RG Phosphor LED (CG319_TEST) When importing the EDR I selected the top option ‘i1Profiler (i1 DisplayPro, ColorMunki Display, Spyder4, Spyder5) Was this the correct option? Or does it even matter? The EDR seems to import without issue.
The second problem is I have no idea where to import Stuart’s EDR file for CN7. I saw the path on Windows mentioned on a LGG thread however I am on a Mac. I think I need to rename the CG319 to match the original and then replace it but despite searching I just can’t find it
If anyone could help me locate that CN7 folder on a Mac I would be hugely greatful
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Would I be right to presume; if I can’t match the colorimeter corrections to start with then there is no point doing this and I would be better off just using CN7 and the built in probe?
Hi Folks,
I have an EIZO CG2420 that I’m using as a reference monitor for Davinci Resolve. I’ve used CN7 and the probe on the CG2420 to do a basic calibration that looks good, but I’m acutely aware that using DisplayCal with an i1D3 to generate a 3D LUT has the potential to give better accuracy.
EDR = Xrite propietary format.
CCSS = same content as EDR but text, used by ArgyllCMS ecosystem, You can convert from EDR to CCSS with commandlie app “oeminst” in Argyllcms “bin” folder.Having read through a number of forum posts both here and on Lift Gamma Gain, I think I know what I need to do and I understand the importance of matching the correction file on both DC and CN7 to create a level playing field. I have Stuart’s CS2731 EDR and I have converted it to a ccss in DisplayCal using the ‘Import colorimiter corrections from other display profiling software’ It shows up under corrections as LCD RG Phosphor LED (CG319_TEST) When importing the EDR I selected the top option ‘i1Profiler (i1 DisplayPro, ColorMunki Display, Spyder4, Spyder5) Was this the correct option? Or does it even matter? The EDR seems to import without issue.
“‘i1Profiler (i1 DisplayPro, ColorMunki Display, Spyder4, Spyder5)” => set of default corrections for xrite i1Profiler White LED (sRGB), GB-LED (U2413), WLED PFS ( multimedia/gaming displays)
+
some additional corrections like WLED PFS HP Z24x G2 (close to your CG2420) or WLED PFS Apple P3 displays.
They are labeled so you can identify them.Color Navigator => default setting “color management” does not use EDR for i1d3 (your CG2420 colorimeter eikll need thta config). You should switch no “no compensation” so CN7 will use EDR corrections form Xrite. The problem is that CN7 EDRs do nit have an WLED PFS sample close to your CG2420. It will be using GB-LED (Dell U2413, closer to old Eizo CG277 or CG2730)
The second problem is I have no idea where to import Stuart’s EDR file for CN7. I saw the path on Windows mentioned on a LGG thread however I am on a Mac. I think I need to rename the CG319 to match the original and then replace it but despite searching I just can’t find it
If anyone could help me locate that CN7 folder on a Mac I would be hugely greatful
Install “suspicious package” app. That app will let you inspect “.pkg” files, the “system installers” for macOS (vs DMG with are portable/direct copy).
On folder tree you’ll find EDR path, I cannot check right now but it should be in /Library/Application Support /Eizo /Sensor/i1DisplayPro EDR
or something like that.So:
-save older version “RG_phosphor….edr” to other path or rename it.
-copy Stuart’s CG319 to that folder and rename it to mac to match older RG_phosphor fileÇ
-match file ownership and permissions to that file, because CN7 may not like if you do not let it as it was.
-run CN7, calibrate with i1d3 colorimeter form Xrite to native gamut, D65 and your chosen white level (likely to be 100nit), 2.2gamma, when prompted DO NOT use “color managed” but “no compensation”, so RG_phoshor EDR will be used (but it use the forged version you replaced)
-On DisplayCAL use the CCSS correction that matches Stuarts EDR (dustribuyted with Stuart EDR or generated from “oeminst” app) choose yoru settings, make LUT3D… etcCG2420 + internal colorimeter + “color managed” setting in CN7 + calibrate to Rec709 gamut
AND
CG2420 + i1d3 colorimeter + “No compensation” setting in CN7 + “Stuart EDR” + calibrate to Rec709 gamut
AND
CG2420 + i1d3 colorimeter + “No compensation” setting in CN7 + “Stuart EDR” + calibrate to NATIVE GAMUT + DisplayCAL LUT3D created using Stuart CCSSAll three should be very close. Maybe 1st one gives you a slightly different whitepoint. Remember that any measurement done with CG2420 internal colorimeter needs to use “color managed” setting for colorimeter correction in CN7. It is i1d3 colorimeter the one that needs “no compensation” to use EDR. ARgyllCMS cannot make use of CG2420 colorimeter and I’m affraid that CN7 cannot make use of it for CN/ verification (same for CG2730), but other CGs can.
You can convert from EDR to CCSS with commandlie app “oeminst” in Argyllcms “bin” folder.
Do I need to worry about using oeminst if I use the correction importer in Dispaycal? It seems to import the EDR ok and gives me a new option ‘LCD RG Phosphor LED (CG319_TEST)’?
It seems that is imported, you need to do nothing in DisplayCAL.
Remember “no compensation” for i1d3 in an unpatched CN7 matches “GB-r … U2413” (5th one).
It will match CG319 TEST when you replace the EDR in CN7 folder. Maybe it is a good idea to close CN7 app on macOS bar (upper right) before replaceing files. When you have replaced them and make sure that file ownershiop & permissions are as orinal une, restart Cn7Thanks for your help Vincent,
I was able to successfully replace the EDR in CN7 with Stuart’s CS2731 file and did a comprehensive 4000 patch calibration which seemed to return excellent results
I have done an XXL verification and wondered what your opinion on the attached results are?
Cheers Rich
It works well. I wish I would see reports on color like that with display profile matching its testing profile. My profile lumance does not match by many nits since adjusting backlight but the color report is still the same. I used to think every change to on screen controls meant a new profile was needed. Changing controls to match the simulated color space is not a problem on mine. I tweaked color control and then the saturation and brightness of the color management system OSD controls using HCFR. Got it delta e to .1 and .2 on its color checker patterns for skin tone. Got its delta L lumance to match using color filters and color paterns using eyeball. Lumance is more important on Primaries is what I read from a old thread. Secondary colors is important to get it hue right.
Looking well to me.
More patches is not always the best. Any Coloredge should have a near perfect grayscale color tint on any whitepoint, but your LUT3D shows a mild to high grey range in a*b* (~1.7).
This is typically caused by some “noise” in all these patches or by some interpolation error (# 007, 020, …).
If you do not mind, leave it as is or check visually in a greyscale MP4 1920×1080 sample, but a much small patch XYZLUT may solve the issue.Also as said before, compare vs CN7 Rec709 HW cal or even CN7 native calibration in greyscale.
Thanks Vincent, that’s interesting. What might you suggest as a sensible amount of patches to use?
Can I also ask, if I add a LUT box into the equation (BM micro converter 12g) would it make sense to scale the data levels in the 3D LUT? So input full and output limited? Or would it be better to go full levels all the way to the monitor?
Why do you want output = limited for a monitor?
Because my pipeline is set to limited levels for broadcast and usually Resolve would clamp the levels to limited if I loaded the LUT that way and output to my monitor which is also set to limited. If I use a LUT box then I am removing Resolve from the equation and therefore need to clamp the levels in the LUT
I tried a smaller sample size but it didn’t make a huge amount of difference.
Next I decided to try and remove the amount of corrections being made to see if that would help
- Calibrate CG2420 with CN7 and i1D3 (Stuart’s EDR) Profile set to D65, 100cd/m, gamma 2.4, Native gamut
- Calibrate CG2420 with Displaycal (Stuart’s CCSS) Resolve preset, calibration settings all set to ‘as measured’
- Create 3D LUT with gamma 2.4 relative and 100% Black output offset and relative colorimetric
Once the LUT is loaded, this gives me a measurement report that has an RGB grey balance with a Delta E of 1.52 which hovers just about in the perceptible range. Does this appear to be the best this monitor can manage? Or is there something else I should be trying to refine this?
To be clear I certainly don’t think these results are bad, but I just want to see if they can be better
It’s way easier if you check a*b* range your current HW cal at native gamut, the one you used to create LUT3D to Rec709.
If it is excellent, then LUT3D creation or perhaps some node in your pipeline is adding that extra tint in greys, usually by rounding errors.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
If that does show better results then is this just something I would need to accept as part of the process?
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.
