- This topic has 6 replies, 2 voices, and was last updated 2 years, 8 months ago by
.
-
Posts
-
Hi! I’m trying to match a Macbook Air M1 with a BenQ PD2700QT (using the visual whitepoint tool of DisplayCal). With both displays calibrated, I have 100% sRGB in the Mac and 99.6% with the BenQ. First, I tried to match the BenQ to the Macbook, but it ended with a 98.9% sRGB, so I restored the BenQ to the original calibrated profile, and now I’m trying to match the Mac to the BenQ.
After I calibrated the Mac, I got a very similar result compared to the BenQ (yet not equal) with 100% sRGB; the only problem is that when I tried to verify the profile, I got a very high value with “Measured vs. assumed target white point ΔE*00” like 10.52.
I already tried to reverify and recalibrate. Also, I’m running it on slow and with more than 3k patches.
Also, it’s normal to get 0 in all ΔE values? I get this with every verification that I do.
Hi! I’m trying to match a Macbook Air M1 with a BenQ PD2700QT (using the visual whitepoint tool of DisplayCal). With both displays calibrated, I have 100% sRGB in the Mac and 99.6% with the BenQ. First, I tried to match the BenQ to the Macbook, but it ended with a 98.9% sRGB, so I restored the BenQ to the original calibrated profile, and now I’m trying to match the Mac to the BenQ.
Why do you care about it?
After I calibrated the Mac, I got a very similar result compared to the BenQ (yet not equal) with 100% sRGB; the only problem is that when I tried to verify the profile, I got a very high value with “Measured vs. assumed target white point ΔE*00” like 10.52.
That is because you are aiming to a whitepoint that is not D65, which is expected as you are doing a visual match.
When aming to a visual matched white don’t care about that number AND DO NOT USE LUT3D with absolute colorimetric intent when simulating “D65” standard colorspaces. You should use relative col (do not change my white) or an alternative std colorspace with hacked white to your visual matched white.
I already tried to reverify and recalibrate. Also, I’m running it on slow and with more than 3k patches.
If you are creating a profile to use in macOS, in desktop, it is useless as macOS color management is very limited. Aim for defaul matrix + single curve profile + BPC and as testchart no more than some lut testchart with 1xx patches (to track accurately greyscale).
Also, it’s normal to get 0 in all ΔE values? I get this with every verification that I do.
It seems a bug in erkan’s port to python 3 of displayCAL. Before Sonoma vanilla DisplayCAL (python 2) did not show that behavior on macOS, at least on teh computers I’ve used. Current displayCAL (python2) is broken in Sonoma AFAIK.
Thanks for the answer!
Why do you care about it?
Care about what exactly? Not having 98.9% sRGB? I just want my primary display to have the most accuracy possible.
AND DO NOT USE LUT3D with absolute colorimetric intent when simulating “D65” standard colorspaces. You should use relative col (do not change my white) or an alternative std colorspace with hacked white to your visual matched white.
Sorry, I didn’t understand that part much. How can I not use “LUT3D with absolute colorimetric intent when simulating D65”standard colorspaces” ? And how to “use relative col (do not change my white) or an alternative std colorspace with hacked white to your visual matched white.”?
If you are creating a profile to use in macOS, in desktop, it is useless as macOS color management is very limited. Aim for defaul matrix + single curve profile + BPC and as testchart no more than some lut testchart with 1xx patches (to track accurately greyscale).
Yeah, I kinda realized that. I’m just not sure on how to change this settings. For what I understand the type of curve it’s auto defined by the amount of patches and speed? So in that case, what would be an ideal setting here?
It seems a bug in erkan’s port to python 3 of displayCAL. Before Sonoma vanilla DisplayCAL (python 2) did not show that behavior on macOS, at least on teh computers I’ve used. Current displayCAL (python2) is broken in Sonoma AFAIK.
I was imagining this
Thanks for the answer!
Why do you care about it?
Care about what exactly? Not having 98.9% sRGB? I just want my primary display to have the most accuracy possible.
Accuracy is not “coverage”.
AND DO NOT USE LUT3D with absolute colorimetric intent when simulating “D65” standard colorspaces. You should use relative col (do not change my white) or an alternative std colorspace with hacked white to your visual matched white.
Sorry, I didn’t understand that part much. How can I not use “LUT3D with absolute colorimetric intent when simulating D65”standard colorspaces” ? And how to “use relative col (do not change my white) or an alternative std colorspace with hacked white to your visual matched white.”?
You are using a macbook white as reference, even if it s not. It’s fine your visual reference.
If because of reasons (obs metatmetic failure, device innaccuracies, wromng configuration) a “numeric match” doe snot provide a visua match on white, then you do a perceptual / visual match. So you are not using D65 as whitepoint on perceptually matched display. You are using another coordinates.DisplayCAL will calibrate to taht white and make grey color match teh color of that white. Then it will store measured xy as profile whitepoint and it will not be D65, it will stote the actual coorndinates, the ones you measured.
So you cannot use absolute colorimetric intent when making LUT3D if your calibrated display is using an alternative (numerical) white or it will correct that white to “numerical match to D65”.
If you want ti preser that alternative white point taht visually match to macbook you shludl preserve that non-D65 white: relative colorimetric is the easiest way. Creating an alternative colorspace with Rec709 gamut and your alternatie white point can be another option, but rel col is easier if you do not know exatly how all this gears work together.If you are creating a profile to use in macOS, in desktop, it is useless as macOS color management is very limited. Aim for defaul matrix + single curve profile + BPC and as testchart no more than some lut testchart with 1xx patches (to track accurately greyscale).
Yeah, I kinda realized that. I’m just not sure on how to change this settings. For what I understand the type of curve it’s auto defined by the amount of patches and speed? So in that case, what would be an ideal setting here?
Test chart combo, choose default testchart for lut profiles,,, if you are using that profile for desktop use. If you are going to use that profile for Resolve, for making a LUT3D, macOS limitations do not apply, you won’t be using it.
It seems a bug in erkan’s port to python 3 of displayCAL. Before Sonoma vanilla DisplayCAL (python 2) did not show that behavior on macOS, at least on teh computers I’ve used. Current displayCAL (python2) is broken in Sonoma AFAIK.
I was imagining this
Thanks, I think I’m understanding now.
You are using a macbook white as reference, even if it s not. It’s fine your visual reference.
If because of reasons (obs metatmetic failure, device innaccuracies, wromng configuration) a “numeric match” doe snot provide a visua match on white, then you do a perceptual / visual match. So you are not using D65 as whitepoint on perceptually matched display. You are using another coordinates.DisplayCAL will calibrate to taht white and make grey color match teh color of that white. Then it will store measured xy as profile whitepoint and it will not be D65, it will stote the actual coorndinates, the ones you measured.
So you cannot use absolute colorimetric intent when making LUT3D if your calibrated display is using an alternative (numerical) white or it will correct that white to “numerical match to D65”.
If you want ti preser that alternative white point taht visually match to macbook you shludl preserve that non-D65 white: relative colorimetric is the easiest way. Creating an alternative colorspace with Rec709 gamut and your alternatie white point can be another option, but rel col is easier if you do not know exatly how all this gears work together.I’m not creating a LUT3D, just profile for desktop use. So I think that this doesn’t apply to me.
Test chart combo, choose default testchart for lut profiles,,, if you are using that profile for desktop use. If you are going to use that profile for Resolve, for making a LUT3D, macOS limitations do not apply, you won’t be using it.
I did all my previous calibrations using auto-optimized with 3k (and I’m using only for desktop). Should I recalibrate everything using the default testchart or that isn’t necessary?
