Colour in mpv is dimmed compared to QuickTime Player

[fumoboy007]

mpv version and platform

macOS 10.12.3, mpv 0.24.0, pre-built by stolendata

Reproduction steps

Open the attached sample video in mpv and QuickTime Player.

Expected behavior

The colour in mpv looks the same as in QuickTime Player.

Actual behavior

The colour in mpv is dimmed compared to QuickTime Player.

QuickTime Player (good)

mpv (dimmed)

Log file

http://sprunge.us/EQOa

Sample files

Config

player-operation-mode=pseudo-gui
icc-profile="/Library/ColorSync/Profiles/Displays/Color LCD-F466F621-B5FA-04A0-0800-CFA6C258DECD.icc"
hwdec=auto
log-file=/Users/fumoboy007/Desktop/output.txt

Sample Video

https://www.dropbox.com/s/khnzs60z1wz2fjt/Rec%20709%20Sample.mp4?dl=1

The video is tagged with the colour profile that Finder describes as HD (1-1-1) (Rec 709).

[fumoboy007]

cc @UliZappe

I’ve been reading through those old gigantic threads about colour management. What conclusion did we come to?

[UliZappe]

@fumoboy007

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:

1. There is disagreement if QuickTime Player compatibility should be the goal at all. There are basically two points of view: A POV drawing from earlier stand-alone video technology which wants to emulate this technology and its workflow and understands color management as only some (isolated) kind of color control, and a POV drawing from computer technology which understands color management as the more ambitious task of getting consistent color between all applications on a computer (which de facto means ICC color management and QuickTime Player compatibility). After we were almost there achieving this second goal, mpv’s implementation switched to the first POV, trying to emulate classic stand-alone video technology, which produces results different from QuickTime Player.

2. A QuickTime Player compatible (i.e. ICC compliant) mpv will need LittleCMS (the color management library it uses) to be ColorSync (Apple’s color management library) compatible, which means LIttleCMS would need to adopt the so-called Slope Limit technology which corrects the TRC (tone response curve) for near-black colors. While Adobe, Apple and Kodak all use Slope Limiting in their color management modules, it is not an official part of the ICC spec, just a de facto standard. I’ve written a patch to add Slope Limiting to LIttleCMS, but so far, Marti Maria (the author of LittleCMS) has not wanted to incorporate it in the official distribution, because he worries about patent issues and probably also because he wants to strictly stick to the ICC spec. The mpv project, on the other hand, seems to only want to use the unmodified LittleCMS library.

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.

[hrxn]

By the way, can QuickTime Player's behaviour be reproduced on another OS somehow, or is this issue strictly macOS only?

[Cpuroast]

The only other OS that actually had a QuickTime app was Windows, but that has since been abandoned.

[UliZappe]

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.

[UliZappe]

The only other OS that actually had a QuickTime app was Windows, but that has since been abandoned.

And that was the old version of QuickTime Player, which was not ICC color managed, either.

[UliZappe]

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.)

[Akemi]

What therefore puzzles me is that @fumoboy007 reports that mpv is delivering less contrast than QuickTime Player

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.

[ 0.330][w][vo/opengl] ICC profile detected contrast very high (>100000), falling back to contrast 1000 for sanity. Set the icc-contrast option to silence this warning.

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.

[Pacoup]

What therefore puzzles me is that @fumoboy007 reports that mpv is delivering less contrast than QuickTime Player

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

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 ICC profile detected contrast very high error with my X-Rite profiles though, but it doesn't seem to impact things.

I'm also using the icc-profile-auto option. I'm not sure whether this is required or enabled by default.

[haasn]

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.

[UliZappe]

The approach used by most transfer curves designed for interoperation / computer usage is to keep the calculations the same regardless of the black point

Yep.

in doing so essentially “squishing” the output response along the axis of the display's output.

Only if the CMM does not incorporate slope limiting for matrix profiles.

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,

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).

This conforms to the ITU-R recommendation BT.1886

Which is aiming at conventional video workflows, not computers, and is architecturally incompatible with ICC color management.

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.

The additional catch is that its color reproduction becomes incompatible with other ICC color managed applications.

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.

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.

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.

It’s also the right choice for ICC compatibility with any display. (Well, without slope limiting in case of LUT display profiles.)

[fumoboy007]

@UliZappe @Akemi @Pacoup @haasn

First, let me clarify my situation.

• The video I am testing has its color profile tag set to Rec 709. Both players should recognize this.
• mpv produces a darker image compared to QuickTime Player. (I added screenshots above.)
• My display profile is the default display profile that Apple included in my operating system. It should not matter as the issue is the relative difference between QuickTime Player and mpv, which are both color-managed and thus trying to convert colors to this final display color space.

My understanding of the difference between the players is as follows.

• mpv uses a 2.4 gamma to convert the video pixels to the CIELAB color space (and subsequently to the display color space).
• The AVFoundation framework that QuickTime Player is built on uses a 1.961 gamma to convert the video pixels to the CIELAB color space.

Is this correct? Do we all agree on the reason? This is the first step.

[haasn]

The video I am testing has its color profile tag set to Rec 709. Both players should recognize this.

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)

My display profile is the default display profile that Apple included in my operating system. It should not matter as the issue is the relative difference between QuickTime Player and mpv, which are both color-managed and thus trying to convert colors to this final display color space.

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.

mpv uses a 2.4 gamma to convert the video pixels to the CIELAB color space (and subsequently to the display color space).

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 input ^ 2.4, but essentially boils down to scale * (input + offset) ^ 2.4.

[UliZappe]

@fumoboy007

The video I am testing has its color profile tag set to Rec 709. Both players should recognize this.

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.

mpv produces a darker image compared to QuickTime Player. (I added screenshots above.)

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.

My display profile is the default display profile that Apple included in my operating system. It should not matter as the issue is the relative difference between QuickTime Player and mpv, which are both color-managed and thus trying to convert colors to this final display color space.

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.

mpv uses a 2.4 gamma to convert the video pixels to the CIELAB color space (and subsequently to the display color space).
The AVFoundation framework that QuickTime Player is built on uses a 1.961 gamma

… which is indeed the simplified gamma of Rec. 709 …

to convert the video pixels to the CIELAB color space.
Is this correct?

Yes.

Do we all agree on the reason? This is the first step.

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.

[UliZappe]

@haasn

So one way or another, BT.1886 is what the mastering engineers are most likely using

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.

and therefore the best way to watch this sort of content;

No, that’s a non-sequitur. As I just said: ICC color management abstracts from this kind of thing.

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.

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. 😈