- This topic has 33 replies, 5 voices, and was last updated 6 years, 2 months ago by
.
-
Posts
-
Using 2.0 gamma in a dimly lit room will make the image appear quite low contrast (dark colours will be brighter relative to bright colours). Perceived brightness is approximately a 2.4 power function under dim lighting conditions. Try 2.2 for day and 2.4 for night. For bright day time conditions 2.2 might not be low enough, you might need 2.1 or 2.0. I guess that’s why they set them to 2.0 because they assume people are using it during the day (a bad assumption imo). I will soon release an app to gradually transition between day and night calibrations, and manually tweaking shadow detail brightness. Interestingly, altering gamma in a 1D LUT affects not just brightness but also hue and saturation. A higher gamma will not only give increased contrast but also increased saturation, and hues will shift as well , eg. skin tones will become more red.
btw I bought the Acer XB271HU and its out of the box gamma is also 2.05, so don’t feel too bad 🙂
A higher gamma will not only give increased contrast but also increased saturation, and hues will shift as well , eg. skin tones will become more red.
That’s true if you apply ‘gamma’ to the individual RGB channels, because it changes the relation of the channels to each other. A different approach could apply ‘gamma’ to only the luminance component, thus keeping the original hue and chroma intact (but the overall result may be not as visually pleasing – i.e. there’s science behind the effect that in dimmer environments and with decreased brightness, perceived saturation also decreases, making a slight increase in saturation by a higher gamma a desirable side effect in that situation).
Also note that all these effects do not affect color managed applications, as the source profile defines what the output should look like (unless you change the output after it has been colormanaged, which I would recommend against as it defeats the purpose. Of course, you can incorporate a viewing condition adjustment in the overall transform, by creating respective profiles, which is a more powerful and sophisticated approach).
That’s true if you apply ‘gamma’ to the individual RGB channels, because it changes the relation of the channels to each other.
Yes, and unfortunately that is unavoidable with 1D LUT’s. Here is an interesting example you may have already seen http://www.colormancer.com/whitepapers/comparison/filter_comparison.html
3D LUT or pixel shader can avoid it by calculating the lightness value and operating on that instead. But I was thinking, is doing that actually correct? Does gamma apply to the lightness value of any combination of RGB, or only to RGB channels individually?
3D LUT or pixel shader can avoid it by calculating the lightness value and operating on that instead. But I was thinking, is doing that actually correct? Does gamma apply to the lightness value of any combination of RGB, or only to RGB channels individually?
Depends on what you’re after.
btw I bought the Acer XB271HU and its out of the box gamma is also 2.05, so don’t feel too bad
I was about to take comfort at the fact that I’m not the only one in the world who received such an inferior monitor for that much money, but then I remembered that I read that the Acer 271hu has gamma control in its OSD.
I wish I had the wisdom I have now before I bought that Asus pg279q. I would have never bought it.
I will never buy a monitor which doesn’t have a gamma control again, and that’s also the first and last Asus monitor I buy.
Everything on my 150$ Xiaomi phone looks better than on this monitor – calibrated and uncalibrated.I was about to take comfort at the fact that I’m not the only one in the world who received such an inferior monitor for that much money, but then I remembered that I read that the Acer 271hu has gamma control in its OSD.
My XB271HU has only 2 gamma options in its user menu – 1.8 and 2.2 , and 2.2 produces 2.05 actual. Definitely needs a calibration to get good contrast at night! Before it I had the previous years model XB270HU and that one had more gamma options, iirc it was 2.2 and 2.5 and I think they tracked closer to their targets as well. I guess Acer engineers decided less options for the user are better.
And it’s still not perfect – there is banding after calibration because of nvidias refusal to provide dithering in the driver (interestingly the Linux drivers seem to have it) but can be mitigated a bit with high quality calibration mode in display cal (takes 1hr+ to generate the cal file, but reduces banding a bit).
Ok, so now I feel we’re in the same boat 🙂
There’s also a slight banding in my case. yesterday at night I tried a long calibration option with this time trying to keep at lease one of the RGB at 100%.
I’ve set it on medium speed and 2500+- patches.
It seems to indeed reduce banding a bit but I’m now left at 118cdm2 (12 brightness on the OSD!), which is too low, and the black patch is 3 deltaE, so I’ll do it again with higher luminance.
I’m not really sure what contributes more to the accuracy of the calibration: the speed or the number of patches?I think we have the same panel , just different processor/scaler. Try to do as much calibration on the monitor itself, you should lose less brightness that way and the mouse cursor will not change colour (the cursor doesn’t receive calibration).
I like 135cd/m2 personally , or just go as bright as you can go without eye fatigue 🙂
But higher gamma will give you that increased contrast and added saturation that should make the image pop a bit more.
Try also setting Tone Curve : custom , absolute gamma , black output offset 100%. Untick black point correct ,and rate at the default of 4. This should give you the darkest shadows without black crush which should increase perceived contrast a bit more.
I think I used just 20 grey patches and that’s it, no colour patches. Because the 1D calibration LUT is really just for white balance and gamma correction, so I don’t think it actually needs to measure colours. For example if a skin tone was off, displaycal is not going to sacrifice grey scale to make that skin tone better. afaict.
Ok, It seems absolute gamma didn’t have any effect on the results. Also lowering calibration speed to low didn’t have any positive effect either.
The one thing that did made an effect is changing the rgb from 98-96-96 to 100-98-98. now my contrast ratio is somewhere in the 920:1 area, but I have 6470k instead of something very close to 6500k, which I don’t think is very critical.
Also the dots in the lower sections are not as close to perfect as before, so I think I’ll do it again today with relative gamma and that RGB and this will probably be the best I can get..I’m not really sure what contributes more to the accuracy of the calibration: the speed or the number of patches?
Calibration speed sets the “length” of the iterative grayscale iteration.
Patches are for profiling, for capturing monitor behaviour after calibration so color manged applications know how to deal with that screen.I think I used just 20 grey patches and that’s it, no colour patches. Because the 1D calibration LUT is really just for white balance and gamma correction, so I don’t think it actually needs to measure colours. For example if a skin tone was off, displaycal is not going to sacrifice grey scale to make that skin tone better. afaict.
It needs to measure colors after calibration to make an ICM profile so your favourite color managed application could try to correct that skin tone as long as profile is accurate enough and color management rounding errors are not too high.
Profile type and number of patches are up to your choice and depends on how well behaved is your display (matrix vs LUT) and how good is your color managed application dealing with color management rounding errors ( 3 TRC vs matrix + 1 TRC).The one thing that did made an effect is changing the rgb from 98-96-96 to 100-98-98. now my contrast ratio is somewhere in the 920:1 area, but I have 6470k instead of something very close to 6500k, which I don’t think is very critical.
“Whiteness” is not about CCT in kelvin, it’s about white 255 not being pink or green. You could have 6500K CCT and awful pink cast. Think of CCT as blue-yellow axis, that number does not give you information about green-red axis.
Even on color critical displays you should now worry about a “near perfect white” but only 6470K CCT/CDT.
“Whiteness” is not about CCT in kelvin, it’s about white 255 not being pink or green. You could have 6500K CCT and awful pink cast. Think of CCT as blue-yellow axis, that number does not give you information about green-red axis.
Even on color critical displays you should now worry about a “near perfect white” but only 6470K CCT/CDT.
No problem there: the white is definitely white with no color cast. The white is also white in the native white temperature (about 6800K), but I it’s a cooler white which causes me eye strain.
Perceived brightness is approximately a 2.4 power function under dim lighting conditions.
Just wanted to correct this. Perceived brightness according to CIE L* is quite a bit different to 2.4 than I thought. Basically 2.4 is more contrasty than CIE L* (darker in the low end, brighter in the high end).
Source: http://drive.google.com/open?id=1pFG3iWpBqEqsPBqdlyXTtgKaB_Lx8BXZgM5oWk1ihhI
This leaves me wondering why 2.4 looks subjectively better to me in a dim viewing environment, and all I can come up with is that it’s closer to the CRT gamma (2.35-2.55 according to Charles Poynton – http://poynton.ca/PDFs/GammaFAQ.pdf ). Either that or my eyes just like the extra contrast?
Side question: does anyone actually calibrate their monitor to sRGB gamma? Because that is quite a bit different to everything else as well. It seems like the answer should be “no” because its tone curve in the low end is so much brighter than regular gamma that shadow detail would get noticeably crushed if displayed at regular gamma. Same goes for CIE L* – content would look so wrong if created on a monitor calibrated to CIE L* and displayed at something like 2.2 or 2.4 (even with black offset).
This leaves me wondering why 2.4 looks subjectively better to me in a dim viewing environment, and all I can come up with is that it’s closer to the CRT gamma (2.35-2.55 according to Charles Poynton – http://poynton.ca/PDFs/GammaFAQ.pdf ). Either that or my eyes just like the extra contrast?
It depends on how the image material you’re viewing has been encoded. Leaving color management aside, computer graphics are usually encoded (gamma-compressed) with a 2.2 to 2.4 decoding gamma in mind. Thus, the intended result is obtained when displayed on a 2.2 to 2.4 gamma display (or, with color management, any display, as display tone characteristic is compensated for in that case).
Side question: does anyone actually calibrate their monitor to sRGB gamma?
Possibly. It certainly is a valid approach, if you mainly work with sRGB content in color managed applications, but you also want appearance in non-color-managed applications to match (at least in terms of tonal representation).
Same goes for CIE L* – content would look so wrong if created on a monitor calibrated to CIE L* and displayed at something like 2.2 or 2.4
Definitely. CIE L* has very specific (and limited) practical uses (think prepress with softproofing of L*-encoded imagery).
Thanks Florian.
I have another question if you are interested. If you notice on that google sheet, the gamma plot for L* (blue solid line) has this discontinuity near black. I used the formulas in this article which compensate for a rounding discontinuity , but in terms of gamma there is still a discontinuity. Just wondering if you could comment whether that looks normal to you or if I’ve screwed up something with the formulas (which are on sheet1 btw).
