- This topic has 12 replies, 3 voices, and was last updated 1 year, 9 months ago by
.
-
Posts
-
I just ran my very first cal+profile in a long time using DispCal + argyll. I have a question (fragen zum) abut “Black” calibration which other software packages don’t go into detail like DispCal. Here is an excerpt from the Verification Report (screen capture) :
https://1drv.ms/u/s!AkD78CVR1NBqmONUGVERt-QAaV4t3w?e=koo4A7
Here is the actual HTML report file :
https://1drv.ms/u/s!AkD78CVR1NBqmONV52_QijBBiQh-6g?e=OrB9i8I hope to succeed at making the following clear. Please forgive my ignorance in advance. If you go down to Item Overview > #02, RGB = 0 0 0, you see Lab = 2.98 -0.02 0.01. But when this is compared to the actual measurement, 2.88 1.62 -7.82, of course, I end up with a huge dE value (6.93), Of course. I don’t debate that. It has to do with the fact that my monitor black point is considerably “blue”.
My naive question : is there any way, through a different calibration approach, to “improve” the match in black point? Which would lead me to discuss all the calibration options offered by DispCal/argyllll, I know…
My take on this is that, *ideally*, i would want to have a calbration such that I get the same chromaticities from Monitor Black to Monitor White : is that feasible, technically? Or is that a stupid idea?
Check out the documentation regarding calibration settings and scroll down the the section for Black point correction.
Basically yes you can do it but for most LCD’s it’s going to raise the black point and lower your contrast ratio enough that you probably won’t like the results, but you can always try and see how it turns out all it’ll cost you is a little of your time.
I attached the result of my initial calibration efforts below. It’s clear that the white point chromaticities are slowly “faded” into the darn absolute black point chromaticities (of my LED display) at about RGB = 70,70,70.
I went over the documentation a few times already and I confess I’m struggling to understand the different Black options offered.
I understand I don’t want to force any “Black level” ; “As measured” is fine. That option seem to have been designed to align multiple monitors.
For “Tone Curve”, I already determined my monitor “native” response is gamma 2.31 but if I choose that option, then I don’t have access to Black output Offset, which is 100% by default. I’m not clear yet on reducing the value down to 0% would do?
I think, in my case, I want to experiment with the Black point correction settting? I’m going to leave at “Auto” to begin…
Check your monitor OSD, under custom or user mode nexto RGB gains settings check for “offset”. Make very small modifications and use DisplayCAL RGB balance popup on “black” icon to track how it changes. It will change white too.
It’s very very unlikely that you can correct black & white, but maybe you can narrow error to 4dE black within 1-2dE error in white to target. Depending on your GPU taht 1-2dE in white can be corrected in GPU LUT without issues (no banding).Alas, this Dell U4320Q OSD only offers RGB individual channels adjustment : I can only increase/decrease each channel’s maximum output. There are no “offset” adjustments to be found here, sadly — we get what we pay for…
I was hoping, perhaps, that the black chromaticities were tied up to the white RGB ‘gains’ but no such luck. Black remains the same ‘bluish black’ no matter what.
- Do I have any options to better manage the black point?
- Does it really matter if the black appears bluish?
I was thinking, perhaps, very naively, that transformations from L < 20 would (somehow?) map out to reasonnably “neutral” tones by virtue of the profile?
What I mean by that is, suppose a Lab color equal to 20, 0, 0 (a dark neutral gray), when that value is sent to the monitor through the profile, isn’t going to be “managed”? Such that the device values sent to the monitor will appear “neutral”? Please excuse my ignorance…
OK. Quick Photoshop test…
Made a new Lab document. Filled it with Lab = 10,0,0 (I did not want to go all the way down to Zero — not yet!) which normally translates to ‘equal’ RGB values (for well-behaved color spaces). Converted AbsCol to the monitor profile (see attached screenshot) and did not get ‘equal’ RGB values : got 30 30 24, a whole lot ‘less blue’ which is what I want, given my monitor bluish black point.
BTW, in Photoshop, there was no difference between converting AbsCol or RelCol.
Any kind of video card LUT correction in black will imply contrast drop… so maybe it0’s better to leave it as is.
Regarding PS or any other editing tool, abs colorimetric is not “abs” (rendering image form file to screen, not printing) because if it were that way a ProphotoRGB image with 255 white will need to render as yellowish on a D65 screen. Hence all of them render image to screen as whitepoint relative. A side effect is that if you wish to softproof simulating white paper color it expect taht screen is calibrated to the same white as light source used for making paper to screen comparisons.
With software LUT3D you can use “abs” although it may have issues with display profiles defined with a PCS white (d50) + matrix to transform to actual whitepoint (i1Profiler profiles for example).
I’m not so worried about contrast decrease, Vincent? After all, I can crank up the White Luminance to compensate, instead of the current 90 cd/m2 or so that I have my monitor set at, can’t I simply bump it up to get the same “contrast ratio”?
You are right about PS “AbsCol” rendering style. When they first came out with ICC support, and a a couple of versions thereafter, an AbsCol conversion from Lab 100,0,0 to sRGB would make the white point “bluish”, to reflect the “absolute” difference in white point. And ProPhoto would render yellowish on a D65-calibrated monitor.
Thank you for all you help and patience,
I’m not so worried about contrast decrease, Vincent? After all, I can crank up the White Luminance to compensate, instead of the current 90 cd/m2 or so that I have my monitor set at, can’t I simply bump it up to get the same “contrast ratio”?
It works the opposite way. White cd/m2 remains the same but if you want to correct black , black output will be lifted to some cd/m2 (RGB 000-> A, B, C non zero) till the mix is closer to white color. Hence contrast will drop. Also you cannot improve contrast in white. Native contrast is a maximum window between black & white, anythong you do will make it smaller.
Anyway you can try partial BP correction in calibration tab: black point correction, auto or manual slider … but i’ve no tested this option.Please allow me to insist, Vincent. Why would “White cd/remains the same”? Why couldn’t I manually increase white Luminane from 90 to 120 or more? Suppose a Black Luminance or 1 cd/m2. With a white Luminance set at 90, it would make for a 90:1 contrast ratio, right? So if, by calibration, the Black Luminance is raised to 3 cd/m2, does it mean that, if I want to maintain the same 90:1 contrast ratio, I have to raise the white Luminance to 3 x 90 = 270 cd/m2?
Unless display has some weird response, if you rise from 100 to 120cd/m2 without RGB gain change, black will be rised by same amount => constant CR, it’s a window on a strip.
If you do not change brightness but change RGB gain to fix white point to some non native value, contrast will drop (or some channel will clip in 0-50-100 RGB gain configurations with 50 default value)
If you do not change brightness but change RGB for black output in GPU (by calibration), contrast will drop and white remains the same <- this is the scenario i was talking about.In your example comtrast ratio will remain the same *** 30:1 *** no matter if you keep 90cd/m2 ( 90 / 3 ) or if you push brightness till 270 cd/m2 ( black 9cd/m2) because contrast in LCD backlight display is a static window on a brightness ruler.
Your reply piqued my curiosity, Vincent. So I fired up Excel, created a white square and a black square, side by side, in the middle of my monitor. I only experimented with the ‘Contrast’ slider in the OSD. The current value is 49%. Can you conclude from these results that your description above applies?
1 @49% : White XYZ = 87.2 90.2 74.8 / Black XYZ = 0.79 0.76 1.07
2 @65% : White XYZ = 131 135 115 / Black XYZ = 0.91 0.88 1.18
3 @40% : White XYZ = 66.8 88.9 58.2 / Black XYZ = 0.67 0.64 0.95
4 @75% : White XYZ = 167 170 149 / Black XYZ = 1.12 1.07 1.84
I have not bothered to push Contrast all the way to 100% and measure. It seems to me that Black Luminance is “relatively independent” of peak Luminance?
Native contrast is static, constant, a window. Cannot improve. Contrast OSD control is not like CRTs and should be left as default value.
Tweaking contrast OSD value makes firmware to tweak some oclusion in panel… but it won’t go further than native CR. Tweaking contrast OSD may cause some channel to clip so unless very careful testing is done, do not modify it:
-RGB gains for white
-offset fro tweaking a little black & white
-brightness
-some saturation controls & 10-20 point graiscale controls if present (like in modern TVs) to limit native gamut to something smaller like sRGB
And that’s it. Without fine tunning internal calibration with a Lut-matrix or LUT3D thorugh a HW calibration SDK thats all you can do on your HW.
DisplaycAL will correct grey using videocard and ake a profle storing actual display response, that ICC profile can be used for color management or to make a LUT3D.Rising brightness rises backlight output, but CR (panel inner property) stays the same, “leaking” light even full oclusion is set (RGB 000)
