- This topic has 60 replies, 3 voices, and was last updated 8 months, 2 weeks ago by
.
-
Posts
-
Thank you for your answer.
I think I would go for the VGGT calibration to D65 plus absolute colorimetric. But I am not sure about the pros and cons. Maybe it’s not good to pull it to D65 if the native whitepoint is 8000K?
IDNK your contrast drop and loss of unique grey levels due to GPU LUT whitepoint correction. Measure and you’ll see. A verification report showing statistics (checkbox) should show that info. This is regarding desktop behavior. On a LUT3D you’ll have the same contrast drop no matter which option you choose. Banding in LUT3D due to unique grey levels loss is up to LUT3D engine on each app (dithering) and you should ask vendor about it. Fr example DWMLUT uses dithering, IDNK Resolve, use its support.
Hi Vincent,
thank you for your quick answer. I made the verification report (attachment). But I don’t understand where I can see the contrast drop and the loss of unique grey levels. Would you like to explain that?
Thank you.
Contrast native – contrast D65. But native contrast is veri high so even correcting to D65 you get 1300.. so don’t care
Unique grey levels are shown with statistic checkbox, about 90% so you loose ~10%. Not very good but it’s a latptop (or an AIO) so this is the only way to correct whitepoint (unless XDR screen).
Thank you so much.
Is the contrast in the report the measured contrast for D65? Where can I see the native contrast?
From the report: “Calibration grayscale tone values 90.6% (232/256)” > Does it mean 236 of the 256 are unique?
What about the low measured luminance? Can’t I correct it? Or shall I not correct it? There is a brightness slider?
There is this “Use Mac display color profiles for viewers” setting in DaVinci Resolve. Do I have to switch it off when I use the GUI LUT?
And it seems that there is a compatibility problem with DisplayCAL on macOS 12.5.1. I can’t open any of the menus from the menu bar with DisplayCAS 3.8.9.3 on macOS 12.5.1.
Thank you.
Sorry for bothering you. Did you see my second post from the 13th of September? Hopefully that are the final questions.
Do only I have problems with DisplayCAL on Monterey or is it a common, known problem?
Thank you.
Thank you so much.
Is the contrast in the report the measured contrast for D65? Where can I see the native contrast?
measure without VCGT calibration applied. for example set as default profile autogenerated profile by macos, then verify. don’t care about dE just contrast. Or use “uncalibrated display report” in top menu, tools.
From the report: “Calibration grayscale tone values 90.6% (232/256)” > Does it mean 236 of the 256 are unique?
Google “injective and surjective and bijective” function. Now translate this knowledge to a 1DLUT in GPU with 256 entries and “256 dot 256” outputs.
It cannot be explained in other way. That is the loss of unique levels. That loss can be ignored if GPU LUT has high bitdepth and dithering, but still that % is a hint of severity of correction applied.What about the low measured luminance? Can’t I correct it? Or shall I not correct it? There is a brightness slider?
on your macbook? read your own macbooks manual!
WP can drift with brightness slider and there is drift there is little you can do about it other than calibrate to a mid way point. Measure WP at several brightness values in slider to see if there is drift. This applies to every display
It should be very low on a macbook or even none.There is this “Use Mac display color profiles for viewers” setting in DaVinci Resolve. Do I have to switch it off when I use the GUI LUT?
likely, because it is using color management by os. Dont use both.
And it seems that there is a compatibility problem with DisplayCAL on macOS 12.5.1. I can’t open any of the menus from the menu bar with DisplayCAS 3.8.9.3 on macOS 12.5.1.
Thank you.
See Erkan’s port to python 3
Thank you for your answer.
The “uncalibrated display report” states “Contrast ratio = 1421:1”. Today I could access the tools menu. Seems to be quite a big contrast loss…?
The first method reported a contrast of 1263.1:1. I chose the default “Color LCD” profile of the MacBook for the verification…?
on your macbook? read your own macbooks manual!
Why so angry? It is a general question for the best practice of calibrating laptops or other AIO devices. I am not asking how to move the brightness slider on my MacBook.
Measure WP at several brightness values in slider to see if there is drift.
Here are the results. I measured the different brightness values with the visual white point editor:
x 0.3143 y 0.3284 | x 0.3139 y 0.3288 | x 0.3158 y 0.3292 | x 0.3145 y 0.3290
I tried following: I switched on the “interactive display adjustment” and adjusted the brightness slider till it was close to 100 cd/m² and continued with the calibration.
But in the verification the Measured luminance was only 88.7 cd/m². I compared it with the other verifications of the CX271 and the FS2331 and noticed that only the CX271 was close to the 100 cd/m² in the verification. The FS2331 has also a much lower measured luminance as the on adjusted with the “interactive display adjustment”.
How does it come? Is it because of the lower qualities of the displays? Would it be okay to raise the brightness during the “interactive display adjustment” to 110 cd/m² to get closer to 100 cd/m² with the measured luminance?
Thank you.
Thank you for your answer.
The “uncalibrated display report” states “Contrast ratio = 1421:1”. Today I could access the tools menu. Seems to be quite a big contrast loss…?
The first method reported a contrast of 1263.1:1. I chose the default “Color LCD” profile of the MacBook for the verification…?
Yes but overall contrast keeps high for an IPS so you can get a black bellow 0.10nit at 100nit white setting. Also human vision is nt linear.
Seems OK for such huge WP correction.on your macbook? read your own macbooks manual!
Why so angry? It is a general question for the best practice of calibrating laptops or other AIO devices. I am not asking how to move the brightness slider on my MacBook.
This is the only way to alter your device brightness. no DDC/CI.
Measure WP at several brightness values in slider to see if there is drift.
Here are the results. I measured the different brightness values with the visual white point editor:
x 0.3143 y 0.3284 | x 0.3139 y 0.3288 | x 0.3158 y 0.3292 | x 0.3145 y 0.3290
I tried following: I switched on the “interactive display adjustment” and adjusted the brightness slider till it was close to 100 cd/m² and continued with the calibration.
CIE xy distance are not “human distance”, easy to track CCT + dE to daylight locus to spot easily “non whiteness”.
But in the verification the Measured luminance was only 88.7 cd/m². I compared it with the other verifications of the CX271 and the FS2331 and noticed that only the CX271 was close to the 100 cd/m² in the verification. The FS2331 has also a much lower measured luminance as the on adjusted with the “interactive display adjustment”.
How does it come? Is it because of the lower qualities of the displays? Would it be okay to raise the brightness during the “interactive display adjustment” to 110 cd/m² to get closer to 100 cd/m² with the measured luminance?
Thank you.
WP correction limits one or two channel max output (inside monitor, or in GPU for laptops and limited functionality AIOs like iMacs). That is what causes contrast loss and that is that causes brightness drop.
Use profile info > calibration curves, see the cut at 255 input. That is WP correction on GPU LUT. You have same way in a LUT3D with absolute colorimetric intent.Thank you so much for your explanations.
This is the only way to alter your device brightness. no DDC/CI.
I altered the brightness slider till I got “Display profile luminance: 99.5 cd/m²” and ” Measured luminance: 98.6 cd/m²”. I guess that is the best I can get out of this procedure.
CIE xy distance are not “human distance”, easy to track CCT + dE to daylight locus to spot easily “non whiteness”.
I did several verifications moving the brightness slider to different positions. Brightness levels between 60 cd/m² and 140 cd/m². The “Measured vs. assumed target whitepoint ΔE*00” stayed always under 0.5 and much less. So the WP drift is marginal.
likely, because it is using color management by os. Dont use both.
To verify what macOS ColorSync is doing I followed your suggestions the that post: https://hub.displaycal.net/forums/reply/31838/
spotread -X /Users/saltarob/Library/Application\ Support/ArgyllCMS/MacBookProRetina2016.ccssWith some primary patches inside Resolve (Red 255.0.0, Green 0.255.0, Blue 0.0.255) I could see that with “Use Mac display color profiles for viewers” enabled the primaries were changed. Whereas without “Use Mac display color profiles for viewers” the primaries readouts of spotread are correct.
But with random patches from the verification report the readout of spotread is not matching the original patch in Resolve. Is there a more advanced way to do such a verification? Would be interesting to see how good this 3DLUT pipeline works.
Thank you.
But with random patches from the verification report the readout of spotread is not matching the original patch in Resolve. Is there a more advanced way to do such a verification? Would be interesting to see how good this 3DLUT pipeline works.
Thank you.
If you are just verifying display profile in a measurement report, those RGB numbers are encoded in display colorspace hence a patch with same RGB number in a Rec709 file will have different coordinates (also it will be encoded on legal range).
Whatever you show in Resolve to be read with “spotread” must be translated to equivalent RGB number in native gamut profile verification report (if you want that knd of comparison as you say in last sentence).
XICCLU tool does that kind of translations device RGB <-> CIE coords but beware scalling (do not use as 0-255 something that is scalled to 0-100).
https://www.argyllcms.com/doc/xicclu.html
I’ve not used it for video but for neutral and near neutral patches in device RGB colorspace for printers so IDNK the exact parameters for your task, read the doc or ask in argyll maillist.If you had another windows laptop it may easier to run “HCFR” (displaycal “cousin”) configured to a Rec709 reference (with or without BPC) with “manual” patches and a pregenerated set of MP4 videos, like AVSForum Rec709 samples. Slow… but since you can’t run resolve’s output in Displaycal, it its a fix.
-You are sending patches in macbook’s native gamut, so colorimeter is measuring primaries more saturated than Rec709…=>P3 look at measured xy coords (wromg P3 coordiante in red may be due to wrong CCSS).
-you are using a colorimeter correction for GB-LED, not for WLED PFS like a mac p3, you’ll have to add CCSS to HCFR folder, check AVSFroum, HCFR thread- I do not remember the folder, i think that it is the same as Argyll in windpws but check.The only misconfiguration in HCFR is CCSS (white). The other issues are on macbook side, it looks like your Resolve is not appying LUT3D or (if there is no LUT3D) that you are not using ICC color management.
Of course if you are trying to measure patches in another colorspace than Rec709 you’ll have to configure HCFR reference to that colorspace, but this is so obvious that requires no further explanation.
-You are sending patches in macbook’s native gamut, so colorimeter is measuring primaries more saturated than Rec709…=>P3 look at measured xy coords (wromg P3 coordiante in red may be due to wrong CCSS).
I figured out that the 3DLUT is only applied in the Color Page of Resolve. Since I was aligning the color patches in the Edit Page I started measuring from there. I didn’t know that the Color Viewer LUT doesn’t work in the Edit Page. The “Use Mac display color profiles for viewers” settings works on the Edit Page.
-you are using a colorimeter correction for GB-LED, not for WLED PFS like a mac p3, you’ll have to add CCSS to HCFR folder, check AVSFroum, HCFR thread- I do not remember the folder, i think that it is the same as Argyll in windpws but check.
Yes I was looking for that in the documentation but couldn’t find anything. Thank you for the hint with the folder. Was not easy to find it in the AVSForum:
C:\Users\xxxxxx\AppData\Roaming\colorEven after adding it to the folder it was not easy to find the right CCSS. Because under HCFR it shows up with a completely different name. I had to look into the CCSS file to figure out which name was chosen. See attachments.
Hope everything was correct now. With these settings I compared the Color Viewer output of Resolve once with the 3DLUT applied and the “Use Mac display color profiles for viewers” setting off and once with no LUT and “Use Mac display color profiles for viewers” on. See attachment.
If my readings are correct then there is no real winner. I am wondering why the 3DLUT shows still so many out of tolerance measurements. DisplayCAL used 1545 patches for that LUT. White seems to be most problematic. ColorSync seems to have a problem with 100% red.
Since both methods show such similar results actually ColorSync is the winner since it works on all Resolve Pages and not just on the Color Page.
Do you think my tests produced any reliable results? What is your conclusion?
Thank you.
Even after adding it to the folder it was not easy to find the right CCSS. Because under HCFR it shows up with a completely different name. I had to look into the CCSS file to figure out which name was chosen. See attachments.
CCSS file :TECHNOLOGY + DISPLAY
Hope everything was correct now. With these settings I compared the Color Viewer output of Resolve once with the 3DLUT applied and the “Use Mac display color profiles for viewers” setting off and once with no LUT and “Use Mac display color profiles for viewers” on. See attachment.
If my readings are correct then there is no real winner. I am wondering why the 3DLUT shows still so many out of tolerance measurements. DisplayCAL used 1545 patches for that LUT. White seems to be most problematic. ColorSync seems to have a problem with 100% red.
Since both methods show such similar results actually ColorSync is the winner since it works on all Resolve Pages and not just on the Color Page.
Do you think my tests produced any reliable results? What is your conclusion?
Thank you.
If both shows error then the display profile asigned to display (macOS colorsync) or used as source to LUT3D is not accurate. => the source of error is in the first steps of the process.
. DisplayCAL used 1545 patches for that LUT.
Maybe some autodim kicked in in macbook while measuring
White seems to be most problematic.
or maybe you choose some other WP that D65 and when creating LUT3D you choose to preserve that white, hence it complains about it. And if you choose that visually matched white you should ignore grey ramo or assign those non D65 to reference.
IDNK waht you did in those steps.
I just realised that I forgot to change the gamma calculation method inside HCFR in my last measurements. I changed it now to “Display Gamma (black compensation” and did the measurements again, see attachments. But there seems to be almost no difference…?
“Autodim” is switched off. My settings in DisplayCAL are like I posted here .
Will attach new screen shots of the DisplayCAL settings together with the verification report.
Thank you.
