- This topic has 5 replies, 2 voices, and was last updated 6 years, 9 months ago by
.
-
Posts
-
The NEC PA271W was hardware-calibrated using Spectraview II while the Eizo CG245W was hardware-calibrated using ColorNavigator. The goal is to generate very accurate profiles on top of these calibrations using DisplayCAL. Calibration was all set to “as measured” so the operation done was “Profile only”.
However, the profiles generated by DisplayCAL resulted in raised blacks with visible red/yellow colorization when opening LagomLCD’s black test image in Photoshop. This does not happen when using the profiles generated by Spectraview II and ColorNavigator.
Taking a closer look at the profiles using DisplayCAL’s Profile Info tool showed that both Spectraview II and ColorNavigator map L* = 0 to native black (R,G,B) = (0,0,0), whereas DisplayCAL’s profiles map it to a non-gray value (R!=G!=B). Furthermore, the R, G and B curves vary widely percentage-wise before converging at L* = 19 and closely staying together from there onwards to L*= 100. Shouldn’t they be close together throughout the whole range of L*, considering that both monitors are hardware calibrated (linear vcgt) and therefore close to perfect grays? I experimented a bit and found out that to “fix” this, one has to turn on Black point compensation in the profiling settings.
I’ve read these two very informative threads on black point compensation:
- https://sourceforge.net/p/dispcalgui/discussion/932493/thread/ab587f24/
- https://sourceforge.net/p/dispcalgui/discussion/932493/thread/0f08590e/
But still have the following questions:
- Why is black point compensation under profiling settings? Shouldn’t profiling be limited to characterization and not calibrating/modifying the behavior of the monitor (albeit subversively via ICC profile)?
- How is black point correction (calibration option) related to black point compensation (profiling option)? From the documentation and the thread discussions, they both seem to be purposed for fixing (or not fixing) the hues near black.
- Irrespective of #1 or #2, how come colorification gets introduced by DisplayCAL/ArgyllCMS? Shouldn’t it agree with Spectraview II, ColorNavigator (and also my eyes) that the grays are already perfect and therefore the TRC’s should have their RGB curves close together throughout the whole range of L*?
Attached please find the 4 ICC profiles described above.
From the measurements, black is D50 L*a*b* 1.6060 0.0784 -1.5987, so not exactly neutral (which is pretty normal). The profile models this well (D50 L*a*b* 1.6136 0.1274 -1.5983).
Taking a closer look at the profiles using DisplayCAL’s Profile Info tool showed that both Spectraview II and ColorNavigator map L* = 0 to native black (R,G,B) = (0,0,0), whereas DisplayCAL’s profiles map it to a non-gray value (R!=G!=B).
Equal RGB does not mean the resulting color is neutral! The amount of RGB needed to produce a neutral (or any) color is determined by the profile that in turn is determined by the actual display response.
Furthermore, the R, G and B curves vary widely percentage-wise before converging at L* = 19
I don’t see this in the tone response curve graph at all.
I experimented a bit and found out that to “fix” this, one has to turn on Black point compensation in the profiling settings.
If you’re using Photoshop (or other color managed software that employs black point compensation), this isn’t necessary though.
Why is black point compensation under profiling settings?
Because it is a profiling option, it doesn’t have anything to do with calibration.
How is black point correction (calibration option) related to black point compensation (profiling option)?
These two settings are not related.
Irrespective of #1 or #2, how come colorification gets introduced by DisplayCAL/ArgyllCMS?
Unequal RGB doesn’t mean colorization, see above.
Hello Florian, thanks for the reply. Is my understanding correct that what you meant by “Equal RGB does not mean the resulting color is neutral” is that it is precisely the unequalness that needs to be applied in order to achieve neutral gray (RGBout of the TRC graph is fed to RGBin of vcgt, and in turn, RGBout of vcgt is sent to monitor). To keep it simple, I’ll just refer to the CG245W in the discussion below.
The CG245W was previously hardware-calibrated (to 60cd/m^2, 6500K and Gamma 2.2) using ColorNavigator, and the ICC profile it generated (CG245W2658508100000004.icc, appearing to be single curve + matrix type?) advertises that the monitor is well-calibrated such that R=G=B throughout 0 < L* < 100. Please see letter ‘c’ in the image below.
Looking at the profile generated by DisplayCAL (CG245W-2-2017-07-12-10-37-S-XYZLUTMTX.icm), it appears that DisplayCAL agrees (with ColorNavigator) that the monitor’s gray balance is well-calibrated, at least for L* > 20 wherein R, G and B are close together til L* =100 (Please see letter ‘a’ in the image below). However, for L* < 10, the R, G and B curves diverge considerably and vary by almost 300% amongst each other (Please see letter ‘b’ in the image below, when L* = 2.544).
Finally, enabling black point compensation in the profiling settings (please see letter ‘d’ in the image below) “fixes” the “colorization” (but not necessarily as you have said), as it seems to use L* = 0 as some sort of anchor point to keep the curves close together.
Considering the discussion above, the questions would then be:
- Why do the R, G and B TRC’s diverge so widely when L* < 10?
- What does black point compensation in DisplayCAL do? Is it similar to Adobe’s black point compensation wherein the assumed source and target profiles are that of PCS (complete gamut) and the monitor’s (limited gamut) respectively? (that is, L* = 0 is mapped to the monitor’s native black (R,G,B) = (0,0,0) even if the correspondence is incorrect measurement-wise). But looking at letter ‘d’ in the image below (wherein BPC is enabled), L* = 0 is mapped to non-zero (R,G,B) instead. Why?
- Given that images viewed using DisplayCAL’s ICC profile (without BPC) differs visually from the ones viewed using ColorNavigator’s, which one should one trust/use? One could argue that XYZ LUT profiles should be more accurate since it allows finer display characterization. But maybe measurements near black (especially when the white level/luminance is not very high) are unreliable and therefore it’s not a good idea to measure and calculate data points for L* < 10 (and instead extrapolate based on more reliable measurements made in L* > 10, trusting that the display device behaves more or less linearly)
(Additionally attached is the profile generated by DisplayCAL w/ BPC turned on)
However, for L* < 10, the R, G and B curves diverge considerably and vary by almost 300% amongst each other (Please see letter ‘b’ in the image below, when L* = 2.544).
You’re misinterpreting the graph. The way to calculate a useful percentage difference between the curves (not that I think it is useful generally) is by taking full range (0..255 for RGB or 0..100 for L*) into account. The difference is much, much smaller (around 3% peak for the point highlighted in your screenshot) than the percentages you came up with. Furthermore, this just means the black point (which for most LCD-based displays is a dark blue/purple gray) is of course recorded in the profile, as it is part of the display response.
What does black point compensation in DisplayCAL do? Is it similar to Adobe’s black point compensation wherein the assumed source and target profiles are that of PCS (complete gamut) and the monitor’s (limited gamut) respectively?
BPC (including the Adobe implementation) is just a very simple form of perceptual mapping of the lightness axis. This is usually employed so that a source black lower than the target profile black will not be clipped, by offsetting and scaling all input values.
But looking at letter ‘d’ in the image below (wherein BPC is enabled), L* = 0 is mapped to non-zero (R,G,B) instead. Why?
Because the measurements indicate that there is a small dead region just above black for your display (meaning there is no increase in brightness from the display up to roughly RGB level 3 or 4).
But maybe measurements near black (especially when the white level/luminance is not very high) are unreliable
The i1 DisplayPro/CM Display is a quite capable instrument that has no problems with black levels thar are a lot lower than what typical computer monitors produce. In your case, the black level is about 0.09 cd/m2, which isn’t that low. ArgyllCMS does adaptive integration time readings based on luminance, meaning it’ll even read dark tones reliably and consistently (albeit slowly) – within instrument and display limits of course.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.Because the measurements indicate that there is a small dead region just above black for your display (meaning there is no increase in brightness from the display up to roughly RGB level 3 or 4).
Thank you for the explanations again, Florian. This was the key to (my) understanding the tone response curves generated by DisplayCAL. The title of this thread/topic might as well have been “ColorNavigator and Spectraview II crushes black when gamma target is set to 2.2”. Opening LagomLCD’s black test image in MS Paint shows that (0,0,0) to (4,4,4) don’t have any discernible change in brightness. Using DisplayCAL’s intensity measurement tool against these blacks displayed on MS Paint also gave this same behavior. Calibrating to sRGB tone curve instead “fixes” the problem.
Is this black crush normal for Gamma 2.2? When I tried opening LagomLCD’s black test image (using MS Paint still) on a DisplayCAL-calibrated (to Gamma 2.2 as well) TN-LCD monitor, I could distinguish (2,2,2) from (1,1,1) and (1,1,1) from (0,0,0) if only very barely. Can we conclude then that both Spectraview II and ColorNavigator’s calibrations are broken? Assuming 8-bit bitdepth, 252^3 / 256^3 means an immediate reduction by almost 5% in total number of colors. While it can be argued that (0,0,0) to (4,4,4) is really supposed to be mapped to a very tight range of L* (< 1 if I am not mistaken, which means their difference in brightness is really barely noticeable?) wouldn’t it still be an outright waste of bits/encoding on their part?
From the measurements, black is D50 L*a*b* 1.6060 0.0784 -1.5987, so not exactly neutral (which is pretty normal). The profile models this well (D50 L*a*b* 1.6136 0.1274 -1.5983).
By black did you mean “monitor black”? Looking at the profile generated by DisplayCAL (CG245W-2-2017-07-12-10-37-S-XYZLUTMTX.icm), because BPC is turned off, is my understanding correct that intensities of L* < 1.6136 are clipped to “monitor black”, whereas, on the other hand, no offset or scaling is performed on L* > 1.6136? By the way, how to extract this black point measurement from the ICC profile? Is this under the “Characterization measurement values” tag in Profile Info? Thank you
Is this black crush normal for Gamma 2.2?
I can’t talk about the SpectraView software. Generally, if the calibration is just a simple output offset, the first few steps in a gamma 2.2 system are very very small, e.g. assuming a 100 cd/m2 peak white, RGB 1 1 1 is 0.00051 cd/m2, 2 2 2 is 0.0023 cd/m2, 3 3 3 is 0.0057 cd/m2. Now adding the black floor back in (around 0.1 cd/m2 for a typical IPS panel display), these steps may become imperceptible.
By black did you mean “monitor black”?
Yes.
because BPC is turned off, is my understanding correct that intensities of L* < 1.6136 are clipped to “monitor black”,
They are clipped to the nearest color, so it may not be exactly monitor black.
By the way, how to extract this black point measurement from the ICC profile?
Look at the accompanying *.ti3 file.
Is this under the “Characterization measurement values” tag in Profile Info?
Yes.
