- This topic has 11 replies, 3 voices, and was last updated 4 years, 2 months ago by
.
-
Posts
-
Is correct whitepoint more important than keeping the Calibration grayscale tone values above 95%?
Whitepoint only needs to be visually neutral, a specific target is not required unless you are aiming for a certain standard (or want to match several displays). Calibration tone values affects banding in the common case of an 8-bit display path (when dithering is not used).
Whitepoint only needs to be visually neutral, a specific target is not required unless you are aiming for a certain standard (or want to match several displays). Calibration tone values affects banding in the common case of an 8-bit display path (when dithering is not used).
So if my display is 10 bit I can safely ignore those values?
Whitepoint only needs to be visually neutral, a specific target is not required unless you are aiming for a certain standard (or want to match several displays). Calibration tone values affects banding in the common case of an 8-bit display path (when dithering is not used).
So if my display is 10 bit I can safely ignore those values?
Display may have 10bit panel, but link to GPU can be 8bit. Display may have 10bit, GPU linked to display at 10bit, but driver may truncate or do some weird things in video card LUT limiting it (standby in windows for example).
Display, link and video LUTs may be >8bit, but rendering “from image to screen through apps color management engine” may be limited to 8bit. Here those values you ask for can be ignored but the choice of TRC stored in profile may play a role.Anyway, a visual assessment of your question: Use a smooth 8bit black to white gradient in non color managed enviroment.
-Is it smooth? It’s OK
-Has some kind of tints although it’s smooth? check a*b* range or severe deviations in grey scale in report in a*b* (usually a*). Slower calibration may help.
-Not smooth, bands?check that you use DisplayCAL calibration loader in windows, check standby policy, check if your GPU is able to load a non trivial calibration and remain smooth (odds that a laptop iGPU will fail are high).Same visual test in color managed enviroment with 10bit display, 10bit link, no GPU banding issues … may have bands. If App uses >8bit or dither they should not happen, if app does not then a simple TRC type may help (single curve)
Whitepoint only needs to be visually neutral, a specific target is not required unless you are aiming for a certain standard (or want to match several displays). Calibration tone values affects banding in the common case of an 8-bit display path (when dithering is not used).
So if my display is 10 bit I can safely ignore those values?
Display may have 10bit panel, but link to GPU can be 8bit. Display may have 10bit, GPU linked to display at 10bit, but driver may truncate or do some weird things in video card LUT limiting it (standby in windows for example).
Display, link and video LUTs may be >8bit, but rendering “from image to screen through apps color management engine” may be limited to 8bit. Here those values you ask for can be ignored but the choice of TRC stored in profile may play a role.Anyway, a visual assessment of your question: Use a smooth 8bit black to white gradient in non color managed enviroment.
-Is it smooth? It’s OK
-Has some kind of tints although it’s smooth? check a*b* range or severe deviations in grey scale in report in a*b* (usually a*). Slower calibration may help.
-Not smooth, bands?check that you use DisplayCAL calibration loader in windows, check standby policy, check if your GPU is able to load a non trivial calibration and remain smooth (odds that a laptop iGPU will fail are high).Same visual test in color managed enviroment with 10bit display, 10bit link, no GPU banding issues … may have bands. If App uses >8bit or dither they should not happen, if app does not then a simple TRC type may help (single curve)
Hmm it seems that windows does render the desktop/apps in 10 bit though because if I set the display to 8 bit in NVCP I see color banding with the profile active, while it’s just smooth with 10 bit selected, this is a true 10 bit panel so I believe no dithering is used.
Also what’s the windows standby bug?
Whitepoint only needs to be visually neutral, a specific target is not required unless you are aiming for a certain standard (or want to match several displays). Calibration tone values affects banding in the common case of an 8-bit display path (when dithering is not used).
So if my display is 10 bit I can safely ignore those values?
Display may have 10bit panel, but link to GPU can be 8bit. Display may have 10bit, GPU linked to display at 10bit, but driver may truncate or do some weird things in video card LUT limiting it (standby in windows for example).
Display, link and video LUTs may be >8bit, but rendering “from image to screen through apps color management engine” may be limited to 8bit. Here those values you ask for can be ignored but the choice of TRC stored in profile may play a role.Anyway, a visual assessment of your question: Use a smooth 8bit black to white gradient in non color managed enviroment.
-Is it smooth? It’s OK
-Has some kind of tints although it’s smooth? check a*b* range or severe deviations in grey scale in report in a*b* (usually a*). Slower calibration may help.
-Not smooth, bands?check that you use DisplayCAL calibration loader in windows, check standby policy, check if your GPU is able to load a non trivial calibration and remain smooth (odds that a laptop iGPU will fail are high).Same visual test in color managed enviroment with 10bit display, 10bit link, no GPU banding issues … may have bands. If App uses >8bit or dither they should not happen, if app does not then a simple TRC type may help (single curve)
Hmm it seems that windows does render the desktop/apps in 10 bit though because if I set the display to 8 bit in NVCP I see color banding with the profile active, while it’s just smooth with 10 bit selected, this is a true 10 bit panel so I believe no dithering is used.
No, it’s Win is 8bit, but link display-GPU may be 10bit. Some apps CAN use OpenGL to draw a 10bit surface like Photoshop. Other apps are much better like Lightroom or CaptureOne, they do dithering and do not care about 8 bit or 10bit pipeline: as long as calibration is smooth, they render smooth images: It is the way to go, same with madVR. Banding in 8bit “LINK” (desktop is 8bit) is limited to nvidia, they truncate without dither althjough soem users have reported to enable dithering in registry, search in this forum. AMDs send 8bit data of that sample smooth gradient through their high bitdepth luts, then dither to whatever bits that link supports (10 or 8) so no banding at all… unfortunately there is no desktop series OpenGL driver to draw 10bit surfaces so no 10bit in Photoshop.
So in the end you cannot have “all” and you have to choose what are your priorities.Also what’s the windows standby bug?
Not exactly “windows standby bug”, if you use OS LUT loader LUT trucation happens unless reboot. On resume standby OS may be trying to do something on video LUTs. If you use basiccolor display it uses that way of LUT loading and truncation happens, same for i1Profiler (or was, not tested in 3.x).
DisplayCAL LUT loader and avoiding standby if possible is the safe choice… (edit) or buy a monitor with reliable HW calibration and avoid the problem from start.one last question what observer do you recommend to use for adjusting the white balance if the display in question is a WRGB OLED, 1931, or 1978, or the newest one CIE2012?
I would use 1931 because HTML report verification is done against it. If it gives you unpleasant white, try the new one, then ignore white CCT on verification
Hmm none of the ccss corrections, or observer seems to give me a neutral white, am I maybe affected by metamerism failure, and would custom white points help?
Hmmm i tried to do a calibration of only gamma, and 1000 patches but the LUT/ gamut coverage is very weird, it shows red/magenta/orange way below the triangle,
Compared to my VA DCI-P3 here which shows magenta/red as oversaturated in the other picture
woops ignore the first picture, i uploaded the wrong one.
Disable any “dynamic” features of the display and re-do calibration and profile from the default patch set (auto 175).
