Possible video correctness/gamma issues with non-sRGB profile |
||||||||||||||||||||||
Issue descriptionPlaying a recent trailer (https://www.youtube.com/watch?v=W4CB5SeBGkI), I noticed that black levels seemed elevated. I compared Chrome vs. Edge, VP9 vs. H264, and forcing sRGB vs. allow default color correction. Partial screenshots of each attached. Note that this video was uploaded as 1920 x 1080, even though it's 2.35:1 so there are black bars which are encoded into actual video content. I included this in the screenshots since they're useful for reference. With color management enabled, both Chrome 62 (forced to sRGB) and Chrome 64 (using the ICM profile for my display) showed elevated black levels. The dark area in the lower left shows RGB values about (16,15,16). The black bar at the bottom appears to be (5,0,6). When I force an sRGB profile in chrome://flags, the dark lower left corner is (7,5,7) and the black bar at the bottom is (1,0,1). This is based on the VP9 version of the video. I don't believe Edge color manages video, but when I use it for comparison, it's similar to the VP9 force-sRGB rendering. The dark area bottom left is (5,8,7), and the black bar is consistently (0,0,0). Edge gets the H.264 version of content, so small differences are to be expected. I am using the standard ZR30w.icm profile shipped by HP that corresponds to my display for this test (not the custom calibration profile that at least previously had known compatibility issues with Chrome).
,
Nov 14 2017
,
Nov 14 2017
Please attach your currently active .icm or .icc profile.
,
Nov 14 2017
On this system (work), I use the standard HP_ZR30w.icm profile (attached).
,
Nov 14 2017
(also, the profile that had compatibility issues should work as of 62).
,
Nov 14 2017
Thanks, that complex profile was for my home display, I'll do another qualitative assessment on how that does on images and video at home when I get a chance. Note that the issue I was reporting here was solely something I noticed on video, I haven't really looked at many photos on this display at work (though I suspect I would have noticed if this behavior extended into images).
,
Nov 14 2017
So, this is the same "what are we to do with video color spaces" that we had back in issue 763260 . We're treating bt709 as having an sRGB transfer function, so, on a monitor which has a 2.2 transfer function, we end up ramping up the values near 0. In particular 1 maps to 6 and 7 maps to 15. As with the previous issue with "how is a video color space to be interpreted", I'm indifferent to the particular approach that we take here, as long as it's reasonably robust (in other words, all of the specs are lies and conventions, not actual specifications).
,
Nov 14 2017
,
Nov 14 2017
Mapping 1 to 6 and 7 to 15 shouldn't be a problem if the output display is really pure gamma 2.2, as they would all produce results very near zero brightness. Either we're interpreting the profile wrong, or the profile doesn't describe what the screen is doing very accurately I think.
,
Nov 14 2017
This is apples ICC profile for the same display. It's pretty similar, but uses a lookup table and is brighter near zero.
,
Nov 21 2017
I don't think the existence of "better" profiles sufficiently addresses this issue. In any case, I was watching a different video (https://www.youtube.com/watch?v=G_UHknhNbAQ), this time on my home system that should have an accurate if complicated ICC profile built via calibration. vox-m64-eg9600 is a screenshot with color management applied; subjectively, it felt washed out, but very concretely, there was extremely visible banding in the darker area of the image (below the logo). The banding in that region corresponds to RGB values jumping by two per level. vox-m62-srgb forces the color profile to sRGB, which IIUC minimizes (but perhaps doesn't eliminate) correction, and while like the m64 image there is visible banding in the lighter areas, the darker ones increase by RGB values of 1 per band, and aren't visible on my display. I've attached my ICM file, but IIRC, this is effectively like most displays just a gamma 2.2 device. re: issue 763260 ; I'm not sure why we were looking at Rec.709 at all? While Rec.709 does specify a transfer curve, subsequent specs have said pretty explicitly that this is not how content should be rendered. BT.1886 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.1886-0-201103-I!!PDF-E.pdf) defines 2.4 as the reference gamma. EBU 3320 (https://tech.ebu.ch/docs/tech/tech3320.pdf) aligns with BT.1886 on 2.2 being the "reference" gamma, but the bottom of page 11 provides additional text on why the transfer function in Rec. 709 should be ignored: "Whilst the camera may have a nominal opto-electrical transfer function according to ITU-R Rec. BT.709, this is in practice modified by the intention of the director in camera control or in grading. The television system has been deliberately designed with an end-to-end system gamma of about 1.2, to provide compensation for the ‘dim surround’ effect [6]. Therefore, the monitor gamma is not, and never has been, the inverse of the camera gamma."
,
Nov 21 2017
Correction to #11: EBU 3320 aligns with BT.1886 on 2.4 as the reference gamma (not 2.2).
,
Nov 21 2017
Could you post your about:gpu as well? On many windows machines we end up doing 8-bit-to-8-bit color management for video, which is obviously not ideal, and I'm wondering if that is what is happening here.
,
Nov 21 2017
The problem is that on some (most) windows platforms, we copy yuv->rgb, then we do rgb->rgb color correcting. If we could it all in one step, or use a higher-precision intermediate format, some of these issues should go away. The about:gpu you posted says "disable_delayed_copy_nv12" which I think means that it is doing the yuv->rgb->rgb path.
,
May 18 2018
This issue has popped up a couple of times now. It seems to come down to the fact that some ICC profiles state that the monitor is gamma 2.2, but it's actually closer to sRGB or rec709. Since this affects a small number of users, and many of those are actually well-informed enough to understand what an ICC profile does, I think we should say that this is working as intended when it comes up.
,
May 19 2018
I'm not sure I follow the conclusion in #16; the samples here were on a custom ICM profile that reflects what the display is actually doing, so at least for the particular data here it should not be the case that this is being caused by the ICM misreporting the actual transfer characteristics of the display.
,
May 21 2018
Well, the original report (at work) was using a 2.2 profile. Let me look into #11 a bit more.
,
Jul 18
,
Sep 4
Summary of investigation and discussion on chrome-color: * Almost all manufacturer-provided profiles declare pure 2.2 gamma (most common), sRGB, or 2.0-ish gamma. * Actual behavior of monitors, as measured using a colorimeter, is all over the place. Near black we saw everything from steeper-than-sRGB contrast near black to outright negative slope, and overall gammas often drifted outside the 2.0 to 2.4 gamma range. * The manufacturer-provided transfer functions are therefore of little value. * 8-bit to 8-bit re-transfer tends to run into quantization issues if the transfer functions are different. This is particularly severe when going between hybrid linear-gamma transfer functions (such as sRGB) and pure gamma. There seemed to be consensus towards pushing all transfer functions near 2.2 gamma---BT 709, sRGB, ~2.1-2.3 pure gammas---on both content and display side to a common transfer function so that most re-transfers are 1:1. This common transfer function could be based on sRGB or BT 1886 with a finite contrast ratio and rescaling to put black at zero. hubbe proposed this standard-seven-parameter curve IF(x < 0.019904, x * 0.050148, pow(0.944159 * x + 0.056258, 2.4) - 0.001001) which is indistinguishable from a BT 1886 curve with a 1000:1 contrast ratio and rescaled to put black at zero.
,
Dec 7
,
Dec 8
Picking up for tracking.
,
Dec 10
@ccameron, can you summarize your objections to the 1886 curve that hubbe@ proposed some time ago? https://chromium-review.googlesource.com/c/chromium/src/+/1199599 That seemed like an elegant solution to these more complicated monitor profiles, so I'd like to understand where you stand on it more concretely. |
||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||
Comment 1 by dalecur...@chromium.org
, Nov 14 2017