mpv has wrong colors with any tone mapping
alexantr opened this issue · comments
Important Information
- mpv version: 0.33.0-217-gf049acfd43 (and previous)
- Windows Version: 21H1 19043.1110
- Source of the mpv binary: https://download.sourceforge.net/mpv-player-windows/mpv-x86_64-20210725-git-e2109b6.7z
I tested on two PCs. One has NVIDIA card with driver 471.41 another has Intel HD Graphics 630. Same result on both machines.
Reproduction steps
Open HDR movie on SDR display, look for scene with bright saturated red lights. Try to compare picture with picture from another player or on HDR display.
Expected behavior
mpv must show correct colors without hue shifts. Red must be true red not pinkish red.
Actual behavior
Base colors like red, green and blue has hue shift. Movie scenes with red lights look wrong.
Here is comparisons madvr vs mpv: https://slow.pics/c/4kcOizzW
Also I took three HDR10 calibration videos (04-Rec2020-Red-100%.mp4, 09-Rec2020-Green-100%.mp4, 14-Rec2020-Blue-100%.mp4) and compare colors on different players. Almost all have correct hues: red - 0°, green - 120°, blue - 240°. And mpv only has 343°, 154° and 224°.
Log files
log with config.txt
log no config.txt
Sample files
Sample video files and screenshots on GD: https://drive.google.com/drive/folders/1RbSEtaZ05THg6K6Tvrd25T5_mPIjwEN5?usp=sharing
#8849 - I like some clipping. It looks more "natural" like usual SDR videos.
#7892 - no problems
#7742 - I use tone-mapping-desaturate=1 tone-mapping-desaturate-exponent=0 hdr-compute-peak=no
My story not about clipping, it about wrong colors. Clean red, green and blue colors with any brightness have some hue shift. Red color is more noticeable because it presents quite often in movies. bt.2390, hable, reinhard, mobius and other - the all have same problem. Any other player and ffmpeg don't have problems with tone mapping.
I reuploaded all files to my server: https://tmpfiles.xyz/mpv-tone-mapping/
My point about hable, specifically, is because you were using hable with ffmpeg so you could have made an apples to apples comparison between mpv and ffmpeg for the same exact tonempaping algorithm. It looks like you did indeed update your files with the hable case and the issue persists. IMO this looks pretty extreme but I'm not at all familiar with tonemapping options in either mpv or ffmpeg to say what the issue is.
I can reproduce this. I only tested with the red. But if I specify the primaries to the same as the test image, the color appears correct.
target-prim=bt.709
target-prim=bt.2020
The strange shift made mpv's tone-mapping quite diff from other player.
But if I specify the primaries to the same as the test image, the color appears correct.
I think it was just a luck. target-prim=bt.2020 will make any other hdr videos look terrible.
It should be oversaturated when using the wider gamut. But it does appear to be incorrect with the primaries. If I get time, I'll try to run more comparisons.
Look at this example with real scene: https://tmpfiles.xyz/mpv-tone-mapping/_test_files/red-umbrellas.mp4
madVR:
mpv --no-config red-umbrellas.mp4
The difference is very noticeable, I can't ignore it while watching
I've tested Quicktime and latest mpv, and they aren't far off. This is what I get:
Quicktime:
--no-config --icc-profile-auto:
--no-config --icc-profile-auto --tone-mapping=hable:
I've also tested P3 color in a BT.2020 container with mpv. Sample file: https://0x0.st/-4Sy.mov
I'm using 2017 MacBook Pro which has a P3 screen. P3 Red should be at least close to red but in reality it's far off. Setting target-peak to a higher value like 1000 makes the result more reasonable. Don't know if it's intended.
Test result
QuickTime:
--no-config --icc-profile-auto:
--no-config --icc-profile-auto --tone-mapping=hable:
--no-config --icc-profile-auto --target-peak=1000:
I downloaded some previous versions from SourceForge and found which version mpv got the problem.
mpv-x86_64-20200614-git-c7fe4ae has normal colors yet
mpv-x86_64-20200621-git-dc24a43 has hue shift already
--icc-profile-auto resolves my problem, but why mpv has problem without this option after mpv-x86_64-20200614-git-c7fe4ae?
Hmm, I used this version and still can reproduce.
20210502-git-39630dc
Hmm, I used this version and still can reproduce.
20210502-git-39630dc
That's a year later. He's using 2020, you're using 2021.
Look at commits near this two builds https://github.com/mpv-player/mpv/commits/master?after=416668d3c8bb5d09ebb3d5e3dbe715856165898b+524&branch=master
I think the problematic commit is dc24a43
If I add --gamut-clipping=no the colors are correct. This new option is enabled by default
It may also be peak detection. There was an adjustment around that time. Try using hdr-compute-peak=no
@Doofussy2 no. hdr-compute-peak=no changes brightness only.
mpv --no-config
mpv --no-config --hdr-compute-peak=no
mpv --no-config --gamut-clipping=no
mpv --no-config --hdr-compute-peak=no --gamut-clipping=no
I think gamut-clipping must be disabled by default.
Or it can do it's job more accurate to preserve colors.
compute-peak should probably be disabled by default, too.
I think
gamut-clippingmust be disabled by default.
Or it can do it's job more accurate to preserve colors.
I'm asking as one who's new to MPV and asking to add new things to my config:
Does this solve your issue? (should I add it to my config?):
hdr-compute-peak=no
gamut-clipping=no
icc-profile-auto
@ObsessedHacker I'm using hdr-compute-peak=no and gamut-clipping=no now. All my videos I checked look like they should look from my point of view.
@ObsessedHacker you can also try tone-mapping-desaturate-exponent=0 and tone-mapping-desaturate=0.9 to tune oversaturated bright areas.
default vs tuned
Look at the sun.
tone-mapping-desaturate-exponent and tone-mapping-desaturate with default values:
tone-mapping-desaturate-exponent=0 and tone-mapping-desaturate=0.9:
The difference is very noticeable, I can't ignore it while watching
Yep. I see the exact same thing you depict in your screenshots both with software and hardware decoding.
with the following parameters, most scenes look fine. but the yellow highlights become orangeish, is it possible to compensate for the yellow highlights?
icc-profile-auto
no-gamut-clipping
hdr-compute-peak
tone-mapping=reinhard
tone-mapping-param=0.6
tone-mapping-max-boost=1.0
tone-mapping-desaturate=1.6
tone-mapping-desaturate-exponent=3.2
MPV
UWP MediaPlayer
MPV
UWP MediaPlayer
Disable compute peak
Disable compute peak
That doesn't affect the color, only the illumination
icc-profile-auto
But uwp player (if u mean the Microsoft's) doesn't support the correct icc convert at all.
That doesn't affect the color, only the illumination
I know, and I think that's what you're seeing. I think it's darkening the yellow. Did you try it?
I know, and I think that's what you're seeing. I think it's darkening the yellow. Did you try it?
Still orange
icc-profile-auto
But uwp player (if u mean the Microsoft's) doesn't support the correct icc convert at all.
not at all
mpv -no-config
uwp
I know, and I think that's what you're seeing. I think it's darkening the yellow. Did you try it?
Still orange
Try without the ICC and with compute peak disabled. I don't trust the windows ICC. You should make your own.
Try without the ICC and with compute peak disabled. I don't trust the windows ICC. You should make your own.
Orange, still orange，and there's only the yellow highlights will be orange, in the general brightness or the dark scene of the yellow looks well.
tried to adjust tone-mapping-desaturate and tone-mapping-desaturate-exponent, gives white or orange, no yellow results.
mpv
youtube provides the sdr version
All colors are so close, except for the yellow in the flames.
With no-hdr-compute-peak the yellow color is yellow.
mpv --no-config
The yellow is orange:
mpv --no-config --no-gamut-clipping
The yellow is yellow-orange:
mpv --no-config --no-gamut-clipping --no-hdr-compute-peak
The yellow is yellow:
youtube
That's a good example. Take a look at her forehead. Notice the difference in the peak brightness. Applying that to the flames, alters the color. Compute peak drops too low.
Interestingly, the HLG version of that video has notably different coloring. The skin tone is very different. The HDR10 version looks oversaturated.
The HDR10 version looks oversaturated.
I checked madVR. It shows colors less saturated.
madVR target 200nits
Also I enabled Reinhard tone mapping with desaturation I used before bt.2390 and I saw normal colors like in madVR.
Config:
tone-mapping=reinhard
tone-mapping-desaturate=0.9
tone-mapping-desaturate-exponent=0
hdr-compute-peak=no
gamut-clipping=no
Result
I checked another HDR Demo. Look at red umbrellas. Reinhard saves more details like madVR does.
Reinhard vs bt.2390
Reinhard with config above:
mpv --no-config --no-gamut-clipping --no-hdr-compute-peak:
madVR:
Is bt.2390 implementation correct in mpv? Because madVR also uses bt.2390 and has normal, no oversaturated colors. Reinhard in mpv is normal too.
I checked madVR. It shows colors less saturated.
I meant the HDR10 mastering is oversaturated. But from your screenshots, it looks like MadVR compensates when tone-mapping.
I now have multiple versions of that Jazz video, and each has different mastering. So make sure to make comparisons from the exact same video.
gamut-clipping=no
hdr-compute-peak
tone-mapping=reinhard
tone-mapping-param=0.6
tone-mapping-desaturate=1.2
tone-mapping-desaturate-exponent=2.4
tone-mapping=reinhard tone-mapping-desaturate=0.9 tone-mapping-desaturate-exponent=0 hdr-compute-peak=no gamut-clipping=no
yellow is yellow, less contrast, highlights are slightly whitish.
UWP
much more yellow, good contrast, highlights are not white or orange
Is UWP Player can be a reference? It loses too much details in bright areas. That's why warm yellow becomes yellow.
Probably not, to keep the balance within details , color accuracy , brightness etc. seems to be impossible.
here's a edited of uwp screenshot (sdr srgb 8bit) by lightroom (exposure -50, highlight -100), I didn't notice where the details were missing
Is UWP Player can be a reference? It loses too much details in bright areas. That's why warm yellow becomes yellow.
madvr can't too. i think only take a shot for TV can be.
brighter, darker, these are all acceptable, but the color is unaccuracy can't be accept.
samples (from 12bit raw) with adjusted highlights, orange is orange, yellow is yellow.
People might get upset at me closing any HDR/tone mapping related issue... No idea what the state of this is currently but there's gpu-next nowadays and a bazillion new tonemapping options I don't understand so I'll close this. Feel free to open a more concrete issue if something truly is still wrong.