Colour in mpv is dimmed compared to QuickTime Player #4248
mpv version and platform
macOS 10.12.3, mpv 0.24.0, pre-built by stolendata
Open the attached sample video in mpv and QuickTime Player.
The colour in mpv looks the same as in QuickTime Player.
The colour in mpv is dimmed compared to QuickTime Player.
QuickTime Player (good)
The video is tagged with the colour profile that Finder describes as
No final conclusion yet, unfortunately.
Meanwhile, we do know what would be needed to achieve 100% color consistency with QuickTime Player (the only color-managed video player so far).
However, there are two problems:
I’ve been an ardent advocate for the second POV, arguing that color management on a computer means, above all, color consistency between applications and a measurably correct color reproduction, and that it makes no sense to try and emulate isolated video technology from former times including its shortcomings (apart from, maybe, an optional legacy mode).
Unfortunately, I had no time left in the last year, so I could not continue with this discussion. However, I have been doing some additional research which I will hopefully be able to present here when it’s finished.
QuickTime Player is macOS only. An mpv player with correct ICC color management would be the first video player to reproduce this behavior on other operating systems.
Just to avoid misunderstandings: When I wrote about color consistency between all applications, I did not mean between all video player applications (because then this would be a Mac only issue, als long as QuickTime Player is the only video player with this behavior), but really between all applications (with some kind of visual output, of course).
So this is an issue for all operating systems, it’s only that so far only QuickTime Player solves it, and thus only on macOS.
To elaborate for those who are not deeply into this discussion:
Basically, the issue at hand is the handling of color appearance phenomena (→ Wikipedia).
Color perception is always subjective (color only exists in our heads), but the CIE 1931 Standard Observer model (which ICC colorimetry is based upon) did a pretty good job in mapping the spectral power distribution of the light to human color perception. However, this model works only for standardized viewing conditions, e.g. a certain amount of surrounding light. If viewing conditions change much, the way the color appears to us starts to differ from that model.
For instance, if the surrounding light becomes very dim, we begin to see that the “black” colors on an LCD screen are still emitting light, i.e. they are actually gray, not black (which, BTW, means that the following will not apply to OLED screens …). This makes it seem as if the image has less contrast. To adjust for this appearance phenomenon, the image contrast must be enlarged in dim viewing environments.
How much it must be enlarged to preserve the appearance is more subjective than the basic colorimetry of the CIE 1931 Standard Observer model is, so it’s a matter of debate. (This vagueness also provided a certain amount of leeway for producers of TV sets to deliver an incorrectly high contrast under the disguise of a color appearance correction, as “high contrast sells”.)
But for the sake of the argument, let’s just assume a contrast enhancement is required for dim viewing environments (and CRT or LCD screens).
In the early days of television, video was basically the direct transferral from a live analog video signal to the TV sets of viewers. Since the video studio was bright, but the viewing environment around a TV set was assumed to be typically dim, a contrast enhancement was required. Since there was little video processing technology at the time, the easiest way to achieve this contrast enhancement was the “creative combination” of the physical equipment. Use a CRT with a bigger gamma value than the video camera has, and you get the desired contrast enhancement.
So when the analog TV workflow standardized, the contrast enhancement became “baked in” into the process flow. It didn’t matter much at which process stage exactly the contrast enhancement was performed as long as it was a standardized place and it was guaranteed the the TV set would reproduce the image with enhanced contrast.
Now let’s have a look at modern ICC color management on a computer. Here, the digital process chain is strictly modularized. Incoming image data are converted from the specific behavior of the physical input device to an abstracted, standardized color space (sRGB, Adobe RGG, ProPhoto RGB, Rec. 709, whatever …) and stay in that space until, at the very end of the process chain, they are converted to match the specific behavior of the physical output device.
Between the two conversions and the input and the output stage colors are let completely untouched (unless you want to do color editing, of course). This is absolutely crucial for a working (i.e. inter-application consistent) color management on a computer.
So, if we want to take color appearance phenomena into account on a computer, there is only one architecturally correct place to do this, and this is the conversion at the output stage (i.e. the ICC display profile). Because strictly speaking, if we want to take color appearance phenomena into account, the “physical output device” the ICC display profile describes is not just the monitor per se, but the monitor in a specific viewing environment, the complete physical reproduction system that starts with the light emitting device and ends in our heads.
So if we feel a contrast enhancement is required because of dim viewing conditions, we need a specific ICC display profile for this viewing condition. This profile will, of course, affect all ICC color managed applications on this computer exactly in the same way, which only makes sense – and assures that color remains consistent between these applications.
When ICC color management was introduced, computers weren’t fast enough for video color management. So video applications remained a “color island” on computers and still used the old ways of baking in a fixed, assumedly required contrast enhancement. So they stayed incompatible with ICC color managed applications. Additionally, the assumption of a required contrast enhancement makes little sense for computers because a dim viewing environment is certainly not the standard viewing environment of a computer.
This all changed when the ICC color managed QuickTime Player was introduced by Apple (2009, IIRC). It’s remarkable no-one followed suit, so far. Unfortunately, mpv in its current incarnation (last time I had time to look, that is) again follows the old, incorrect ways of baking in an assumedly required contrast enhancement. (What therefore puzzles me is that @fumoboy007 reports that mpv is delivering less contrast than QuickTime Player – last time I checked, it was more. But I’m currently on the road and cannot check. In any case, mpv seems to be incorrectly color managed currently.)
A psychological issue in this whole discussion might be that users have sticked with contrast enhancing video applications while moving to computers with brighter viewing environments, in effect becoming accustomed to a contrast that is too bright, while considering a correct contrast to light. (But again, this is obviously not the issue for @fumoboy007.)
it's probably because @fumoboy007 doesn't use a ICC profile generated for his display by a colour management software but just the standard one provided by the OS, which doesn't include all the necessary info that mpv needs. just on a side note, for me it seems pointless to have colour management enabled if one just uses a standard profile that doesn't represent the characteristics of ones display anyway, but yeah that is a whole different problem. see this in his log.
so it assumes a most likely wrong contrast value. can't expect it to look 'right' like this.
just to prevent any misunderstandings. i don't mean to say that what mpv does currently is right or wrong, since i don't have a clue. the right person to talk to for this (or the person to convince) is @haasn, but you probably know that already.
I would say that this is correct. All my Macs are color calibrated with an X-Rite i1Display Pro and the color reproduction in QuickTime and mpv is identical. My understanding is that QuickTime makes similar assumptions to mpv according to certain heuristics or flags in the video file (https://mpv.io/manual/master/#video-filters-format).
Haven't tested fully color managed workflows such as with Final Cut Pro X, but I imagine they would work?
No idea about the slope limit thing. Haven't tested Windows either.
I do get the
I'm also using the icc-profile-auto option. I'm not sure whether this is required or enabled by default.
The difference between quicktime and mpv boils down to the question of how to handle the display's black point.
The approach used by most transfer curves designed for interoperation / computer usage is to keep the calculations the same regardless of the black point; in doing so essentially “squishing” the output response along the axis of the display's output. This has the advantage of being easily reversed and using identical math in all environments, but has the downside of crushing blacks on non-ideal displays. Slope limiting, like the type sRGB has built in (and quicktime implements for pure power curves as well) is a workaround to the black crush issue.
The approach used by conventional television/film, and mpv, is to keep the overall output curve shape the same and squish the input signal along this curve, thus also achieving an effective drop in contrast but without crushing the blacks. This conforms to the ITU-R recommendation BT.1886, which is why mpv uses it. The catch is that to perform the conversions correctly, mpv needs to know what the display's black point is. “Fake” profiles, “generic” profiles, “black-scaled” profiles and profiles which already incorporate stuff like slope limiting lack the required information, so mpv doesn't know how much to stretch the profile by - and these profiles usually already have a “contrast drop” built into them, so mpv will most likely end up double-compensating either way.
So the best solution is to use a real (colorimetric, 1:1) ICC profile that's measured for your device, instead of a “perceptual” pseudo-profile that tries to do contrat drop etc. in the profile already.
That said, it's possible we could do a better job of working around such profiles - for example, instead of assuming contrast 1000:1 and applying the contrast drop based on that, we could instead delegate black scaling to the profile, and simply perform the required slope limiting / gamma adjustment to approximate the BT.1886 shape under these conditions. The QTX values of 1.96 gamma + slope limiting are probably a good choice for a ~1000:1 display, so we could fall back to those values instead.
Only if the CMM does not incorporate slope limiting for matrix profiles.
Which is precisely the point where it becomes incompatible with ICC color management, for the architectural reason discussed above (no color appearance corrections whatsoever before the final display profile conversion – which then affects all applications identically).
Which is aiming at conventional video workflows, not computers, and is architecturally incompatible with ICC color management.
The additional catch is that its color reproduction becomes incompatible with other ICC color managed applications.
But the display profile is the one and only place where perceptual/appearance phenomena should be dealt with in ICC color management. Nothing “pseudo” about that.
It’s also the right choice for ICC compatibility with any display. (Well, without slope limiting in case of LUT display profiles.)
First, let me clarify my situation.
My understanding of the difference between the players is as follows.
Is this correct? Do we all agree on the reason? This is the first step.
Yes, unfortunately this doesn't really tell us anything about the response curve except by implying that it was most likely mastered on a BT.1886-conformant device. So one way or another, BT.1886 is what the mastering engineers are most likely using and therefore the best way to watch this sort of content; and even apple's slope-limited gamma 1.96 more or less approximates the 1886 shape overall as well, so they clearly agree with this.
(Although IIRC, a better approximation would be gamma 2.20 and not gamma 1.96, the former being a far more widespread value. 2.2 vs 1.96 most likely has to do with the perceptual contrast drop issue that UliZappe mentioned earlier)
It does matter because QuickTime is built around the needs of this black-scaled pseudoprofile, while mpv is built around the needs of colorimetric (1:1) profiles. QuickTime's usage of slope limited 1.96 as the input curve assumes that this “error” will combine with the display profile's “error” to approximate the BT.1886 shape overall. mpv on the other hand assumes the display profile has no error and uses the exact BT.1886 shape as the input curve instead. Hope that makes sense.
It uses a 2.4 gamma shape, but squishes the signal range along the curve to prevent black crush. This is a bit more complicated than
Well, both “recognize” it, but only QuickTime Player interprets it as an ICC profile for an ICC color managed video application. mpv in its current incarnation is not ICC color management compliant but tries to emulate conventional TV color processing; as @haasn wrote in his reply, Rec. 709 “doesn't really tell us anything about the response curve” (i.e. his POV does not take it seriously as an ICC profile) “except by implying that it was most likely mastered on a BT.1886-conformant device” (i.e. his POV is referring to BT.1886 instead, which is a spec which is only aimed at conventional TV color processing (by intentionally using different tone response curves for input and output devices (in order to achieve color appearance correction)), something completely at odds with the basic concept of ICC color management, as I tried to explain above).
From an ICC color management POV, the current mpv implementation makes as much sense as arguing This image is tagged with ProPhoto RGB; this doesn't really tell us anything about the response curve except by implying that it was most likely edited on an sRGB display.
BT.1886 cannot be applied to ICC color managed video on a computer, but @haasn keeps trying to do so.
Ah, thanks for the added screenshots and the clarified wording! I took “dim” to mean less contrast, but you actually meant dark = more contrast. Yes, that’s completely in line with the expectation that because of its current color management implementation, mpv produces an image that is too dark.
Yes, but mpv is not ICC color management compliant as it additionally introduces a contrast enhancement by trying to emulate BT.1886, which is orthogonal to ICC color management.
… which is indeed the simplified gamma of Rec. 709 …
We probably more or less do. The disagreement is about which one gets it right.
From my POV it’s (aesthetically) obvious again in your screenshots that QuickTime Player gets it right and mpv is too dark but @haasn seems to feel the other way round. What can be said objectively, however, is that mpv currently breaks the inter-application consistency aspect of ICC color management.
Only those who still use the conventional TV color processing workflow.
In any case, that’s completely irrelevant for watching video on an ICC color managed video player. The very idea of ICC color management is to abstract from specific hardware conditions. If I watch an image in ProPhoto RGB, I do not have to care at all about what equipment editors of this image used.
No, that’s a non-sequitur. As I just said: ICC color management abstracts from this kind of thing.
No, Apple says Rec. 709 means (simplified) gamma 1.961, period. Because that’s what the Rec. 709 ICC profile says.
Sometimes it seems to me that even tiny unicorns you’d find in the bit sequence of a video would be an unambiguous hint for you that this video is meant to be watched on a BT.1886 monitor.
ITU-R BT.709-6 does not actually define the electro-optical transfer function of the display, only the source OETF. It is meant to be used in conjunction with ITU-R BT.1886, where one of the considerations, to quote the recommendation, is:
ITU-R BT.709 actually has a notation on the opto-electronic conversion that states:
As a final note, in Appendix 2, ITU-R BT.1886 states:
Essentially, BT.709 defines the OETF but does not provide a common EOTF, which is one of the primary goals of BT.1886.
What is this Rec. 709 ICC profile you speak of? The standard itself does not have one. It seems that the ICC itself provides a Rec. 709 Reference Display profile based on ITU-R BT.709-5 from 2011 that uses a gamma of 2.398.
OK cool, we all agree (more or less) that the difference between the players is the gamma value used for gamma-decoding the video pixels. Now let’s agree on the technical details. The following is my current understanding.
Effect of Surround Luminance
Is this correct? Do we all agree on the technical details? Step two.
Yep, but ITU-R BT.709-6 per se is no ICC color management spec. OETF and EOTF and specifically the idea that different values could be used to adjust for color appearance phenomena are concepts from the conventional TV world that are incompatible with the ICC idea of keeping the color constant and adjust for color appearance phenomena in the input and output profiles only.
In the conventional video world, yes. This is not what we have to deal with if we want an ICC color managed video player on a computer.
This quote should make it completely clear that this is an approach to color handling that’s incompatible with ICC color management.
The ICC profile Apple has provided with macOS since it introduced ICC compatible video color management, or any other Rec. 709 ICC profile that is built with the Rec. 709 parameters (not hard to do).
Of course. It does not deal with ICC color management.
We don’t need a Rec. 709 display profile, we need a Rec. 709 input profile for correct ICC video color management – because the video data is the input. The correct ICC display profile will always be a profile that exactly describes the physical behavior of the specific display it is made for. The idea that you have to use a display with a specific behavior is completely foreign to ICC color management; the very idea of ICC color management is to get rid of such requirements of the conventional workflow.
If you happen to have a computer display that by chance or intentionally has the exact specifications of an ideal ITU-R BT.1886 display (which, as you quoted yourself, is recommended in conjunction with ITU-R BT.709), then you can use the (maybe ill-named) ICC provided Rec. 709 display profile. Since this profile assumes a gamma of 2.398 for the display color space, it neutralizes the gamma 2.398 based contrast enhancement of the BT.1886 display (when converting from XYZ or Lab to the display color space) which is unwanted in ICC color management.
I can only repeat: Color processing in a conventional TV workflow, which architecturally still stems from the analog era, is very different from and incompatible with the ICC color management approach on computers which aims at inter-application consistent and metrologically correct colors, not assuming and “baking in” any kind of alleged “TV like” viewing condition with specific color appearance phenomena. Unfortunately, moving from one approach to the other seems to produce a lot of confusion.
This is true, but the significance of this fact for our context is overrated and produces a lot of confusion. There is no direct connection between this fact and the technical gamma of video (and still imaging) reproduction.
In analog video, where there was no digital modelling of visual data and you had to deal with whatever physical properties your devices had, it was kind of a lucky coincidence that the perceptual nonlinearity of humans and the EOTF of CRTs are very close. That meant that twice the voltage = twice the brightness. Nice, but nothing more.
In 8 Bit digital color reproduction, it makes sense to use a similar nonlinearity to have more of the limited precision available in the area where the human eye is most sensitive for differences. It is not crucial that the nonlinearity used mirrors the human perception precisely; it’s just about a useful distribution of available bit values.
In 16 Bit (and more) digital color reproduction, it’s completely irrelevant, because enough bits are available. You might as well use no non-linearity at all.
So historical technical limitations aside, we may look at an image reproduction system as a black box. It doesn’t matter at all what internal representation is used, it only matters that output = input.
The only thing that’s relevant for our discussion is the relative difference of contrast required because of color appearance phenomena (i.e.
Conventional video was an isolated system, and one that assumed a standardized viewing condition, so it was not very important where the appearance correction took place, but on the other hand, you had to deal with whatever devices you had. So the reasoning was:
None of these points are true for consistent color reproduction on a computer and ICC color management. In ICC color management, the reference values are always the absolute, unambiguous, gamma unrelated XYZ or Lab values of the PCS (profile connection space); gamma is a mere internal implementation detail of the various RGB and CMYK color spaces that should be considered to be completely opaque when it comes to implementing appearance correction.
No. In ICC color management, we want them to be correct and therefore unambiguous absolute XYZ or Lab values. (Lab, of course, was developed with the goal of being linear to human perception.) Linearity is nice when you have only 8 Bit color, otherwise it doesn’t matter (for viewing, that is – editing, of course, is a lot easier with perceptual linearity). What is crucial is unambiguous, absolute values.
OETF and EOTF are concepts from the conventional video world. For historical reasons, you’ll find these expressions in ICC color management, too, but basically, they’re only internals of the input and output profiles and the devices they describe. So, whether you have a gamma 1.8 display with a corresponding display profile or a gamma 2.4 display with a corresponding display profile, ideally does not matter at all in an ICC color managed environment. A specific XYZ or Lab value from the PCS should look exactly the same on both displays.
Can use in ICC color management. They could use any other parameters as well, as long as there is a corresponding video profile that produces correct XYZ/Lab values in the PCS.
Of course, it is the official standard for HD video and currently the de facto standard for almost all video.
No. It was intentionally different, so that the combination with a Rec. 1886 display would produce the desired appearance correction for dim viewing environments.
Possibly, but not crucial. What’s crucial is the intended contrast enhancement relative to the Rec. 709 TRC.
Only in a conventional, not ICC color managed video workflow.
That sounds nice, but is hardly achievable. We cannot look inside the head of the author, we don’t know her/his equipment. What if the equipment was misconfigured?
The ICC profile connection space assumes a viewing environment with 500 lx. So the objective goal can only be:
Metrologically exact color reproduction of the XYZ/Lab values of the connection space for a viewing environment with 500 lx plus appearance correction for other viewing environments, if necessary. (As I said, how much correction is required is a matter of debate.)
Yes. This way, all imaging applications are affected in the same way, as it should be.
But there is a big problem: So far, Joe User has almost no way to get appearance corrected profiles for his display.
True for CRTs and LCDs (extent is matter of debate). Remains to be seen for OLEDs (since with them, black does mean no light at all, not dark gray)
With Laptops, tablets and smartphones you could easily add something like very bright, i.e. outside.
Interestingly, it is controversial if dark needs even more correction than dim, or, on the contrary, less.
As I said, the exact amount a matter of debate, not least because “dim” is not actually a very precise term (or if it is – 10 lx –, it only covers are very specific situation), and of course, the specific display properties also play a role.
More specifically, BT.1886 defines a EOTF that tries to emulate the appearance of a CRT response on an LCD, while preserving the overall image appearance - by reducing the contrast in the input space (logarithmic) in accordance with the human visual model, rather than the output space (linear).
Everything you wrote seems correct to me. One thing I'd like to point out is that ICC distinguishes between colorimetric and perceptual profiles. As I understand it, colorimetric profiles should not include viewing environment adjustments, black scaling or anything of that nature - while perceptual profiles should incorporate all of the above.
It's possible that we simply need to start using a different input curve for perceptual and colorimetric profiles? I.e. use a pure power gamma 2.2 (or whatever) + BPC on for perceptual profiles, and BT.1886 + BPC off for colorimetric profiles.
No, these orthogonal issues.
For the sake of easier argumentation, let’s for now limit the color appearance phenomena to the influence of the amount of surrounding light (as all the video specs do). Then, you can easily tell color appearance issues from other color management issues by simply assuming a situation with a 500 lx viewing environment, which would imply no output color appearance adjustment at all, as 500 lx is the reference environmental illuminance of the ICC profile connection space.
In this case, the issue that colorimetric vs. perceptual profiles try to address is still unchanged: What do we do if the source color space is larger than the display color space? Cut off out-of-gamut colors (colorimetric conversion) or reduce the intensity of all colors proportionally until even the most saturated colors are within the display color space (perceptual conversion).
Color appearance correction for viewing environments with an illuminance different from 500 lx is completely independent from that question.
Architecturally, the basic issue is as simple as this: In a correctly ICC color managed environment, color appearance correction affects all (imaging) applications exactly in the same way, and thus is an operating system/display profile task and outside the scope of any specific application. All mpv could and should do is provide metrologically correct Lab or XYZ data to the profile connection space and then simply perform a Lab/XYZ → Display RGB conversion strictly along the lines of the ICC display profile.
All color appearance correction, if required, would be included either in this display profile (which would imply several display profiles for several viewing environments) or in the operating system’s CMM handling of display profiles (which would imply that applications would have to use this CMM when performing color output conversion).
Unfortunately, in the real world it’s neither common to have several display profiles for different viewing environments nor to have a color appearance aware CMM. Apple seems to intend to develop the ColorSync CMM in this latter direction, which, if consistent with an acknowledged color appearance model such as CIECAM 2000, would be a huge step forward in correct computer color reproduction for all kinds of environments, but it’s not there yet, and it would again be Apple only, anyway.
So maybe a lot of the current confusion and inconsistencies stem from the fact that mpv understandably (given the limited real-world conditions) wants to perform its own color appearance correction when from an architectural POV, it shouldn’t.
Yep, but that’s just another way of saying that mpv wants to perform its own color appearance correction when from an architectural POV, it shouldn’t.
A BT.1886+BT.2035 mastering environment is the conventional TV approach that hardwires a specific viewing environment (the one which was considered standard in the 1950ies) and does not care about the ICC color management architecture.
It is simply not ICC color management compliant and as such inappropriate for a video player on a computer.
Nice, so we mostly agree on the technical details of gamma, Rec 709/1886/2035, and ICC color profiles. Now let’s try to put all this information together to arrive at a sound solution.
The process looks like this: source color → CIELAB color → display color.
Bringing ICC Color Management to Video
The process looks like this: source color → display color.
Deriving the Conversion From Source Color to PCS
The process now looks like this: source color → CIELAB color → display color where the first conversion uses a gamma decoding value of 1.96.
In other words, I think we should change our gamma decoding value from 2.4 to 1.96.
Well, I certainly do, as this has – in effect – been my argument all along.
Just to be fair and to be precise academically:
Strictly speaking, the video application need not “care” about the first function, either, because just as the display color space is defined in the display profile, the video source color space is defined in the video profile, in this case Rec. 709 – if we take the Rec. 709 color space as an “ICC profile”, as ICC color management always does.
The simplified gamma approximation of the Rec. 709 complex tone response curve is 1.961, so from an ICC POV this is the gamma value to use. It is certainly no coincidence that the Apple derivation you quoted resulted in this value and not, let’s say, in 1.95 or 1.97. I think it’s fair to assume that Apple “reverse-engineered” this derivation to demonstrate that even from a conventional video processing POV it’s OK and consistent to switch over to ICC video color management – if only you agree that in this day and age, and on a computer, it makes no sense at all to hardwire a color appearance correction for a typical 1950ies viewing environment.
It’s also important to recall that color appearance phenomena come with a high level of subjectivity, much higher than the CIE colorimetry for the standard colorimetric observer (see e.g. the already quoted Wikipedia article for the abundance of different color appearance models that all try to model color appearance phenomena correctly). There is no way to demonstrate with psychophysical experiments that Apple’s assumption of a factor 1.25 color appearance correction is wrong and it’s e.g. 1.23 or 1.27 instead. The statistical dispersion is simply too large for this kind of precision. So the suggested 1.961 gamma value might not be the correct value, but neither is it wrong, and it’s the value that makes video color processing consistent with ICC color management, so it’s the value of choice.
@UliZappe This is something I don’t understand. The tone response curve function in
(The line on the right is the 1.961 curve; the two lines on the left are the actual curve and the 2.09 curve.)
I don’t think Apple used the inverse of the Rec 709 OETF. Instead, I think they “reverse-engineered” the Rec 1886 EOTF.
You're assuming this is a common practice. It doesn't seem to be. When I generated my ICC with argyllCMS, it just measured the display's response as-is and did not incorporate a “dim ambient contrast boost” into the curve, at least not as far as I can tell. For this to be a good default practice, it would be required for all profiles to actually exhibit this behavior, no? Also, isn't it up for debate whether or not ambient-sensitive contrast alterations are even required or not? I remember @UliZappe arguing quite vehemently against them.
By the way, you can experiment with this right now. If you want to cancel out the gamma boost of 1.25, you can use
For sure. The inverse of the 709 OETF never makes sense. The EOTF is never the inverse of the OETF.
Visual trial and error won’t get you anywhere in a question like this. If you use one of the well-known curve-fitting algorithms (least square etc.), you’ll find that mathematically, the closest approximation is 1.961.
Here is a visual representation of the complex Rec. 709 tone response curve (dots) and gamma 1.961 (line):
I don’t think @fumoboy007 meant to say it’s common practice. I think he meant this is what should be done to emulate conventional TV behavior in an ICC compliant way. If so, he is correct.
Right. This is our problem if we want mpv to be ICC color management compliant and behave like conventional TV.
Well, it shouldn’t be the default practice, because the default viewing environment for a computer certainly isn’t a 10 lx environment.
But for special situations such as people wanting to use their computer as a TV set in a dim environment, there should be additional profiles for dim environments that they can switch to in this case.
Which is exactly the problem we have if we want to emulate conventional TV’s results in an ICC color management compliant way: To do this, we need display profiles with color appearance correction for a dim viewing environment (or a CMM which applies appearance correction to display profiles), and Joe User does not have them.
This is wrong, and only shows how much confusion the EOTF/OETF concept creates in the context of ICC color management. Again, it is a historical concept which made sense back when the only way to achieve desired contrast changes was by “creatively” combining equipment with different EOTFs/OETFs.
Of course, in an ICC color management context, you do have the task of converting optical into digital (= “electrical”) data and vice versa, too. But in ICC color management, this process is exactly, metrologically defined and therefore an “internal detail” you need not care about. If you create a precise ICC profile for physical input or output equipment, the “EOTFs” or “OETFs” depend solely on the physical transfer characteristics of the equipment such that the Lab/XYZ values stay the same when moving from the physical into the virtual world and vice versa. You need not even think about them – you can always start from the Lab/XYZ values of the profile connection space and be assured that these are correct.
So if, by chance, you happen to have an input device (scanner, camera, whatever) with an OETF of 2.81 and a display with an EOTF of 2.81, then you’ll have – by coincidence – an EOTF that’s the inverse of the OETF. Of course this can happen. But it’s irrelevant. What is relevant is that you stick to the input and output profiles for conversion to and from the profile connection space, and do not change the Lab/XYZ values in between.
So, in the case of mpv, this means:
video source in Rec. 709 → conversion to Lab/XYZ using the Rec. 709 TRC ≈ gamma 1.961→ keeping Lab/XYZ values constant → conversion to display RGB using the display profile TRC
And this is not what mpv currently does.
Ah I see, @UliZappe. Interesting that Apple gave their reasoning as
I did more research. The literature supports the foundation that our logical argument was based on. Here are some excerpts from A Technical Introduction to Digital Video by Charles Poynton to drive this discussion home.
Poynton is saying that the Rec 709 OETF is the inverse of the natural CRT EOTF but with a contrast enhancement to help with “dim surround” viewing environments. Removing that contrast enhancement will get us back to the original picture for normal viewing environments.
I don't think it's okay to simply dismiss this. The "simplification" from complex curve with linear segment to pure power curve actually significantly alters the curve's behaviour near the black point. Just to make it clear, curve-matching by numerical analysis in linear light is the wrong approach. Our perception is quasi-logarithmic, so if anything, you want to minimize the sum of
Simple trial by experimentation is enough to arrive at this conclusion, which is what both the ITU-R and Apple seem to have done (seemingly independently). The only major disagreements at this point are:
I completely agree in general. I only referred to the question why in the given example the Y' of Y'CbCr is ~171 in one case and ~180 in the other. This is nothing that could result from the difference between the complex and the simplified TRC of BT.709.
True, which is why Apple’s CMM uses a technique called Slope Limit (see above in this thread) to kind of force a linear segment during conversion in the CMM itself, independent of the specific TRC that is used. This fixes the loss of detail in dark regions.
Hello again. I did some more detective work mucking around with Apple's color management APIs and I was able to discover the exact constants that Apple is using for HDTV -> sRGB in Quicktime X/AVFoundation. There is a 1.96 like gamma curve, but the black levels are defined with a linear slope of 16 in the very low range. These two functions capture the logic.
The following attached images show the default output when decoding the Quicktime HD test video on iOS (uses CoreImage and CoreVideo logic and matches output of QTX), then the output of my Metal shader that makes use of non-linear to linear methods mentioned above. For comparison, the final image is what this test video decodes to with the BT.709 defined gamma (this final image is basically what mpv decodes as). Note that difference in the going to black area just above the colors, one can see the white boxes appearing at some point after the 50% of the screen width mark, the best match is with the slope of 16.
Yep, both is true (gamma 1.961 in fact), but both was already discussed here and in fact already correctly implemented in mpv and my Slope Limit patch for Little CMS before @haasn decided it would be a good idea to emulate an ancient, incorrect, out-of-date technology instead which is completely incompatible with computer color management as we know it.
1.96(1) is simply the closest gamma approximation of the complex Rec. 709 TRC, although Apple went to great lengths to argue for it independently from that mathematical connection in the paper where they introduced it when they introduced video color management on computers (see the post from @fumoboy007 on 20 Mar 2017 above, paragraph “Deriving the Conversion From Source Color to PCS”). They probably did this to soothe the many video traditionalists (the video community seems to be incredibly retro oriented technologically). You will find 1.96 and 1.961 over and over if you search this thread.
With regard to slope limiting, note that this is not an Apple only behavior. Both Apple’s ColorSync CMM and the Kodak CMM do this, while the Adobe CMM also implements it, but uses 32 instead of 16 for the linear segment. Little CMS is probably the only of today’s relevant CMMs that does not implement it. Unfortunately, at least 3 years ago, Marti Maria (the author of Little CMS) did not want incorporate my patch in the main branch of Little CMS for fear of copyright issues (at least this was his explanation; he might have also disliked to “pollute” the “clean” CMM with the very “pragmatic” industry approach of slope limiting).
Uhm, no – certainly not with the default parameters. Which parameters do you refer to?
@mdejong Last comment seems incorrect. By default, mpv does not perform color management at all. It simply outputs the encoded colors as-is, and relies on the display implementing the correct transfer function implicitly. That looks like this:
If you explicitly set target gamma 2.2 (which is what mpv falls back to for e.g. HDR content), you get this:
And this is what it looks like when using an sRGB ICC profile as the target (assuming a 1000:1 contrast), which would be more suitable for a PNG:
Observe that opening this png in krita displays identically to what I get in mpv if I let it use my monitor's native display profile (krita on top, mpv on bottom):
Interestingly, for a typical 1000:1 contrast, gamma 1.961 is a very good fit for BT.1886 at the low end, whereas gamma 2.2 better approximates it everywhere else:
For the TRCs other than BT.1886, black point compensation was done as if the CMM performs linear scaling in the PCS.
Finally, this is what the end-to-end response looks like, if we assume the input was encoded with the exact (piece-wise) BT.709 function. (Note that now, the "Inverse BT.709" graph is identical to what a purely linear function would look like, i.e. 1:1 end-to-end response)
We can indeed verify the claims that the BT.709+BT.1886 interaction near perfectly simulates a gamma drop of 1.2. We can also see that the apple curve (pink) is pretty far from the ideal curve (green) on the low end (below 10% or so). In fact, they're much closer to the gamma dropped curve (black) than the "linear" curve.
Ahh, yes I looked back at the output and it seems I had dragged the wrong movie file into mpv. What that 3rd image shows is reversing the BT.709 segmented gamma function exactly. The point of that was that using this exact set of 1.96 constants generated an output that matches QT X. I actually only need compatibility with the was Apple does things for my purposes.
Re this 1.2 "gamma drop", I can see how the Apple 1.96 + slope logic is rendering recorded video input in a way that looks more representative of the original scene. Does the "gamma drop" you describe counteract a "dark room" boost applied to video? The reason I am asking is because I would like to encode computer generated RGB values and I am not sure if encoding with the BT.709 segmented curve makes sense. Is the more correct approach to actually encode RGB using the Apple 1.96 segmented gamma curve so that exactly reversing the encoded values would return the original RGB values.
The gamma drop is the "dark room boost" applied to the video.
It doesn't. Encode with sRGB.
What are you basing this statement on? Encoding with sRGB would introduce yet another slightly different "black level" linear segment at the bottom and a slightly different gamma curve (offset 2.2 gamma) into the mix. Decoding a sRGB gamma encoded value with 1.961 segmented curve would generate something, but the RGB values would not be exact inverted values as compared to the original RGB values. I can only assume that the original camera hardware that encodes to the BT.709 format also applies this "gamma boost" and that this is why Apple implemented decoding the way they did.
To clarify: You should do both encoding and decoding in sRGB. The reason is because it's (mostly) unambiguous, invertible, and widely supported. It's also designed for use with digital media and computer monitors, and in particular therefore makes a good fit for "generated" RGB content, which is typically assumed to be in sRGB anyway.
That's not really how it works in practice. Your camera would typically record to some vendor-specific logarithmic HDR color space like S-Log or V-Log, or even just raw floating point values (e.g. in OpenEXR frames, which is what the source footage for e.g. Tears of Steel is available as). This gets tone mapped, graded and encoded to BT.709 as part of the mastering process, by doing subjective adjustments on a reference display in a reference viewing environment.
If you follow ITU-R standards such as BT.709, then this reference viewing environment is essentially a pitch black room, and the reference display is modelled by BT.1886.
I cannot both encode and decode with sRGB as a single solution because video already encoded as BT.709 assumes that a BT.709 matrix is used to convert from YCbCr to RGB and this data is encoded with the BT.709 piecewise gamma function. Encoding to sRGB is non-standard and it will not display correctly in QT X or any other Apple tools (like preview in Xcode).
I am trying to achieve compatibility with the method that Apple uses to encode and decode video. It is interesting to implement a completely different approach, I will most likely implement a sRGB encoding and decoding approach for a completely different piece of software. Just ignoring the Apple approach and implementing a non-standard approach is not an option. What I am trying to address is how Apple actually implemented encoding and decoding, I am now convinced that I have the exact decoding approach down, but the encoding from RGB is still a bit of a mystery.
I created this graph to show the exact differences between grayscale values as sRGB, BT.709 (with no dark room boost), and Apple gamma 1.96 with a linear segment. The approach I settled on is to encode RGB data using the 1.96 gamma curve so that when decoded with Apple AVFoundation APIs the results are as close to each original pixel as closely as possible.
So, I just discovered that it is possible to encode YCbCr and explicitly tag it with ffmpeg as using the sRGB gamma curve and still have QuicktimeX player display it properly. This approach actually provides slightly better numerical results when doing a round trip from sRGB input pixels -> BT709 encoded -> sRGB because the gamma curve represents the original data more closely. It is not a huge difference in terms of precision, but it makes a bit of difference in some cases like really smooth gradients. Here is an example ffmpeg command line:
Note how passing -color_trc iec61966_2_1 above will tag the YCbCr data as having been encoded from the sRGB gamma function. This encoded data can then be decoded by Apple APIs since the sRGB curve is supported as a gamma function. This also means that ffmpeg knows how to decode the data properly which is not the case when gamma 1.961 encoding data.
I have not found any way to encode "full range" data in a way that can be decoded on iOS devices. If you can provide an encoder or approach that works with 420 and main H.264 profile then I would be interested to see it working.
Edit: I've discovered that BT.1886 does result in nearly identical results as sRGB on one of my monitors, but not if I start mpv on the other monitor. I'm not sure why it can detect one monitor's ICC profile and not the other's, but the logs suggest that it errors out trying to retrieve the second monitor's ICC profile.
I think this is the source of me thinking that the BT.1886 EOTF was incorrectly implemented in mpv, and I no longer believe this. For historical significance, I'll leave my original comment below.
I was trying to find out why mpv doesn't implement the Rec. 709 transfer curve, instead only implementing (and incorrectly at that) BT.1886, and I find... A whole lot of people talking in abstractions and not actually doing the math to double check.
BT.1886 depends on the contrast ratio of the monitor in question. Yes it uses a power of 2.4, but BT.1886 is only ever 'x^2.4' when you have an infinite contrast ratio, such as an OLED monitor in a dark room. Having done the math on my own monitor using a colorimeter, I found that the resulting BT.1886 curve is almost identical to sRGB... For my monitor only.
Lets do the math to prove that. I'll be doing this with Qalculate, a desktop calculator program which has graphing and other nice features.
The ICC profile I generated for my monitor (using a colorimeter) indicated at the time a luminance value of 250.95 cd/m². This is mapped to a Y value of 100 for the white point. The black point, meanwhile, has a Y value of 0.1022. We multiply that by the white point luminance divided by 100 to get the luminance of the black point, and arrive at 0.2564709 cd/m².
Now, lets look at the equation defined in BT.1886 (with variables expanded and equations put in an order that makes sense):
brightness = luminBlack^(1/2.4)/(luminWhite^(1/2.4) - luminBlack^(1/2.4))
Overall, that means:
luminance = ((luminWhite^(1/2.4) - luminBlack^(1/2.4))^2.4)*max(input + (luminBlack^(1/2.4)/(luminWhite^(1/2.4) - luminBlack^(1/2.4))), 0)^2.4
So lets put that into Qalculate, and plug in our white and black luminances... So, it says that overall, the curve should approximately be:
218.12005*max(input + 0.060160214, 0)^2.4
Lets graph that, and also scale it so that 0.2564709 maps to 0, and 250.95 maps to 1.0... And compare it to Rec. 709 and sRGB:
(Note: I don't know why it shows negative values; I've tried narrowing the plot to a range of 0 to 0.00000001 and it still has them converge perfectly on zero, but having some room under them. I'm guessing some rounding issue where it turns into -0.0 due to floating point weirdness.)
So, when I give mpv my color profile with all sorts of data, and it claims to use BT.1886 for Rec. 709 content, I would expect almost identical output from it compared to if I had specified that the content uses sRGB. This is clearly not the case, so you guys must not be implementing the equations correctly.
By the way, interesting thing about Rec. 709: the original draft had no mention of BT.1886, because BT.1886 was a standard that came out later and is focused on calibrating reference monitors so that they perceptually are the same as each other, and roughly the same as an old CRT, despite widely different contrast ratios. The BT.1886 standard explicitly states, and I'm copy/pasting directly from the document here (emphasis theirs, not mine):
And following that sentence is the specifications for the Rec. 709 OETF, of which I used the inverse for in my graph above.
So for crying out loud, please at least give both a Rec. 709 and a BT.1886 transfer curve, and don't just assume BT.1886 will cover for Rec. 709 - especially not a flawed and incorrectly implemented version of it. It doesn't help anyone.