- This topic has 4 replies, 3 voices, and was last updated 10 months, 2 weeks ago by
.
-
Posts
-
My Dell U4320Q does not have a memory to store calibrations.
(Unlike some of the better / more expensive units who do…)
All I find in the OSD is a menu for dialing color temperature and/or RGB sliders for setting the white point. Typical.
So, when creating an ICC profile for such a monitor, is it true that *IF* dispCAL creates downloadable calibration curves in the resultant ICC profile, that I am necessarily “losing” levels?Please excuse the newbie question…
There is only one way to map 256 values into 256 values in a monotonic ramp… and that’s linear y=x.
But ArgyllCMS calculates VCGT in 16bit so
<GPU driver in 8/10bit> -> VCGT 16bit (perhaps truncated to 8/10/12) -> DVI/HDMI/DP at 8-10bit.So if you GPU has LUT >10bit and uses dithering for truncation no “visual loss” of unique grey levels.
AMD and Nvidia shoudl have >=10bit luts but AFAIK only AMD has enabled dithering for “visually lossless” truncation.
intel iGPU AFAIK truncate all to 8bit so banding posterization in non color managed grey ramp due to grey levels loss is common.Le Doge’s DWMLUT uses dithering at OS level so it is possible to apply grey calibration and skip VCGT. This should work on every GPU, but grey ramp correction will be limited to 65 point.
Anyway, even if you skip VCGT and DWMLUT and rely ion VCGT=linear and ICC profile TRC storing all grey color error, most apps excluding AdobeACR, CptureOne and Lightroom do not use dithering, so you’ll have posterization error in gredients, likely worse than VCGT’s.
Thank you, Vincent.
Graeme was often asked a similar question.
My own programming efforts on Windows show that the “gammaramp” area in video RAM is 8-bit, so only 256 entries. But, as Graeme does it, it populates these entries from 16-bit curves.
More food for thought.Do you know what settings to turn off in disCAL to avoid the creation of a VCGT all together?
Thank you, Vincent.
Graeme was often asked a similar question.
My own programming efforts on Windows show that the “gammaramp” area in video RAM is 8-bit, so only 256 entries. But, as Graeme does it, it populates these entries from 16-bit curves.
More food for thought.?
I do not see any contradiction. You feed GPU driver with 8bit values. They get corrected by 16bit VCGT data loaded into GPU lut (if hardware could handle that), so you do not loose unique grey levels. Then this output is truncated to 8 or 10bit in HDMI/DP/DVI connector… but if you use dithering like AMD, even a 8bit DVI connector carry “visually” a 10-12bit corrected output.
so no banding.Do you know what settings to turn off in disCAL to avoid the creation of a VCGT all together?
Set all settings in calibration tab to native and disable interactive pop up. button shoudl change from calibrate & profile to profile only. Use “linear VCGT calibration” when asked (instead of using current).
Thank you, Vincent.
Graeme was often asked a similar question.
My own programming efforts on Windows show that the “gammaramp” area in video RAM is 8-bit, so only 256 entries. But, as Graeme does it, it populates these entries from 16-bit curves.
More food for thought.Do you know what settings to turn off in disCAL to avoid the creation of a VCGT all together?
256 16-bit entries, not 256 8-bit entries: https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setdevicegammaramp
256 entries are plenty as you won’t measure 1000 distinct grey patches anyway. Display instability (and low end probe tolerances) would probably overcome all the gains from extra patches.
Start with the OSD sliders and measure & compare both options. Are sliders enough to give you very smooth gradients AND measurements close to the reference? Great, you don’t need VCGT.
Chances are high though that OSD sliders will not be enough to correct RGB balance across the whole range and will also not correct gamma.
