HDR tonemapping producing subpar results with default config

[NSQY]

mpv version and platform

Windows 10 1809

mpv 0.29.0-107-gd6d6da4711 Copyright © 2000-2018 mpv/MPlayer/mplayer2 projects built on Sun Dec 16 00:57:00 UTC 2018 ffmpeg library versions: libavutil 56.24.101 libavcodec 58.42.102 libavformat 58.24.101 libswscale 5.4.100 libavfilter 7.46.101 libswresample 3.4.100 ffmpeg version: git-2018-12-15-be60dc21

Reproduction steps

Attempt to watch HDR content on SDR monitor

Expected behavior

Accurate reproduction of colours and brightness levels

Actual behavior

Colours (particularly in the red spectrum) are not accurately reproduced, light often behaves unnaturally and visibly shifts mid-scene

Log file

https://0x0.st/sdlQ.txt

Sample files

If someone can tell me how to losslessly cut an mkv with HDR metadata intact I can provide samples

From what I can tell, tonemapping with mpv currently has two major issues what make it rather unpleasant to the end user: Reds are awful, I don't know if there's something special about this part of the spectrum but mpv does not play well with them at all - at least with the default settings. I've found I can improve reds dramatically by tweaking some settings such as the following but this comes with the cost of interfering with the rest of the film. tone-mapping-desaturate=0 hdr-compute-peak=no

Here are some examples of reds/yellows not behaving correctly, I'll be using madVR as a pseudo reference as I don't have the SDR BD on hand and they seem to have no such issues with their tonemapping solution. These examples are from The Dark Knight 2008, mpv (default) has no HDR-specific config, mpv (tweaked) users the aforementioned config from the previous paragraph. Full gallery for easier viewing: https://imgbox.com/g/DvoY5yAjFH Examples:

Fire - madVR: https://images2.imgbox.com/db/c3/TRqmFfaz_o.png mpv (default): https://images2.imgbox.com/50/1b/L9crP04w_o.png mpv (tweaked): https://images2.imgbox.com/e6/0d/HROmk5iG_o.png

Explosion - madVR: https://images2.imgbox.com/5d/0d/KzBne9Hd_o.png mpv (default): https://images2.imgbox.com/a8/8a/kDpQb97n_o.png mpv (tweaked): https://images2.imgbox.com/e4/5b/eji8jTxh_o.png

Secondly, hdr-compute-peak often causes noticeable shifts in brightness throughout the film even when there's not much going on. I noticed this while watching The Big Lebowski for example, while they were standing around talking the brightness suddenly shifted and it was very noticeable and uncomfortable. Here's an example of it shifting dramatically within a few frames, again, from The Dark Knight 2008: https://images2.imgbox.com/75/a9/LuuoGHun_o.png https://images2.imgbox.com/a9/0c/SpBDirqQ_o.png

One thing in paricular that I've noticed about this is it's at its most egregious during sudden shifts, such as cutting from a dark scene directly to an explosion; perhaps it would be possible for mpv to scan ahead of time so such shifts can be accounted for?

[NSQY]

I found a valid sample https://4kmedia.org/sony-camping-in-nature-4k-demo/ At 1:05 this file shows a closeup of a camp fire which demonstrates the the issue reasonably well, Default config: https://images2.imgbox.com/1e/8c/REmolmmV_o.png Tweaked config: https://images2.imgbox.com/d6/91/vpuRlo3e_o.png

[mia-0]

mpv seems to refuse to treat this sample as HDR and complains about an invalid peak here (0.29.1).

I also find the brightness shifting with --hdr-compute-peak to be quite unpleasant and annoying, even if it is relatively smooth. I only have a single HDR movie in my collection (Annihilation), where tone-mapping=reinhard with tone-mapping-param=0.6 yields much better results than the defaults.

[NSQY]

tone-mapping=reinhard + tone-mapping-param=0.6 produces some nice results, but I'm unsure if I would consider them better than the default; although that being said I can definitely see why it would produce superior results in a a film such as Annihilation.

Regarding brightness, a possible course of action with --hdr-compute-peak is to make it more conservative, other tonemapping solutions have similar techniques (dynamic brightness) however they do not suffer from significant shifts, at least noticeable ones.

I looked around and found some more scenes to test these settings, one thing that struck me as interesting is that a few seconds after one of my examples, the camera shifts to a close-up of the fire. Here mpv outputs a very good image that does not suffer from any 'red' issues. mpv (default): https://images2.imgbox.com/1f/4d/XGHeNxDw_o.png mpv (tweaked): https://images2.imgbox.com/99/7b/0ZFXHJpk_o.png

This also a good example of the damage that is done by enabling hdr-compute-peak=no and tone-mapping-desaturate=0 in certain scenes which leaves the user in a bit of a bind, do they disable tone-mapping-desaturation to improve red scenes? Or do they keep it enabled and have bright scenes ruined? This is obviously not an ideal solution in any world.

I have some more examples of mpv not dealing with bright scenes well, even with "tweaked" config; from Interstellar: madvr: https://images2.imgbox.com/5a/bd/yGKWUgwg_o.png mpv (default): https://images2.imgbox.com/4f/df/4miFqIQy_o.png mpv (tweaked: https://images2.imgbox.com/98/93/ARtMkK8T_o.png

I also have a recording demonstrating how poorly hdr-compute-peak handles sudden shifts in its current state https://0x0.st/sdRG.mp4

[haasn]

re: desaturation, it's mostly a question of:

1. how bright is the fire?
2. what do we expect bright fire to look like?

judging by the madVR result, I think they are doing tone-mapping per channel instead of linearly, which results in a lot of bright colors getting chromatically shifted; i.e. what was red to begin with ends up white, but colors close to it end up various shades of orange and yellow.

This style of tone mapping is also what hollywood has been doing for ages, which is why our brains are used to it. It's not chromatically accurate, but it might be more aesthetically pleasing. I could see myself adding an option to allow users to choose between the two modes of tone mapping, based on user preference (accurate colors or hollywood colors).

The more interesting question is concerning the desaturation itself: which one of the two mpv images is closer to our eye's perception of the same scene? Maybe desaturation of bright colors is not the correct approach in general? The reason it exists is because there are some scenes that just look extremely weird without it, usually very bright stuff like looking into the sun. I don't have much experience doing that in real life, so I can't say whether it's really unnatural or if it just feels unfamiliar.

Maybe we should disable desaturation by default, or tune it to be less aggressive? (e.g. perhaps not desaturate all the way towards white, but caps the desaturation coefficient)

[haasn]

One approach you could play around with is this patch:

diff --git a/video/out/gpu/video_shaders.c b/video/out/gpu/video_shaders.c
index 342fb39ded..d047cf19a8 100644
--- a/video/out/gpu/video_shaders.c
+++ b/video/out/gpu/video_shaders.c
@@ -678,7 +678,8 @@ static void pass_tone_map(struct gl_shader_cache *sc, bool detect_peak,
         float base = 0.18 * dst_peak;
         GLSL(float luma = dot(dst_luma, color.rgb);)
         GLSLF("float coeff = max(sig - %f, 1e-6) / max(sig, 1e-6);\n", base);
-        GLSLF("coeff = pow(coeff, %f);\n", 10.0 / desat);
+        const float desat_cap = 0.5;
+        GLSLF("coeff = %f * pow(coeff, %f);\n", desat_cap, 10.0 / desat);
         GLSL(color.rgb = mix(color.rgb, vec3(luma), coeff);)
         GLSL(sig = mix(sig, luma * slope, coeff);) // also make sure to update `sig`
     }

desat_cap can be freely configured between 0 and 1: 0 meaning no desaturation, and 1 meaning full desaturation as before

Does that make the fire scenes more believable? A value of 0.5 still prevents e.g. the sony clip staring-into-sun from being too weird looking.

[aufkrawall]

@haasn Could you take a lot at what VLC does with the latest version and its D3D11 renderer? With it, saturation is not pale while there are no "smearing" artifacts at the same time. I tried do achieve the same result with the OpenGL renderer or mpv, but it doesn't seem to be possible.

[NSQY]

I have spent my entire afternoon attempting to compile mpv correctly with MSYS2 so I could test your patch; for my own sanity I will not be trying again anytime soon, sorry. Maybe I will be able to get something working in a VM.

I could see myself adding an option to allow users to choose between the two modes of tone mapping, based on user preference (accurate colors or hollywood colors).

This seems like it would be a nice addition to mpv

Regarding desaturation, I agree with your point here - as I stated earlier the current solution does indeed leave the user in a less-than-ideal scenario, and unfortunately I don't have a solution. I think tweaking it to be less aggressive would be a better solution than disabling desaturation entirely, as you've mentioned it can help with particularly bright scenes. As I mentioned earlier I'm having trouble compiling mpv on Windows so I cannot test your patch currently, I will see if I can figure something out tomorrow. I might just boot into a Linux live USB and compile/test natively on there.

[haasn]

I implemented the tunable desaturation patch from above + added a new option in --tone-mapping-per-channel in #6410.

Feel free to try it out and give feedback.

[laichiaheng]

@haasn If it works well, will there be a backport for mpv0.29.2?

[NSQY]

Greetings, sorry for the delay - busy over the weekend Just a few oddities before comparisons, I noticed when jumping through files mpv will often apply extreme desaturation on a frame, then the next frame it will 'recover' and output correct results; see these videos:

https://0x0.st/s5H9.mp4 https://0x0.st/s5Hp.mp4

This has made testing slightly annoying as I will have to watch the entire scene in realtime to verify that mpv is actually outputting incorrect colours instead of just a single incorrect frame caused by seeking, it doesn't seem to be consistent either.

Secondly, while testing The Lion King (and Mad Max) I noticed at the very start and end of the film, with desaturation enabled I was getting white artifacts in certain areas, see this clip: https://0x0.st/s5HG.mp4 The artifacts shift when I interact with parts of the screen (the OSC in this example), and it only happens in fullscreen. For a minute I thought tone-mapping-desaturate=0.0 solved this however upon closer inspection this is still an issue even with it disabled, it's just that desaturate=0.5 causes the artifacts to become bright white and therefore more noticeable. (Side note, why does the OSC have any affect on the VO? Surely this can't be right?) Log: https://0x0.st/s5Xr.txt

Thirdly, I'm getting inconsistent results between films; I expected this to a certain extent but the differences between films are quite shocking, 'Darkest Hour' is basically perfect while other films are outputting bad (abhorrent) results . I'm unsure why exactly this is happening, the only thing I can think of is the nits that they were mastered at, any thoughts? Perhaps something different should be done with the tonemapping if we can identify a common theme between certain films so it doesn't adversely effect films that don't have HDR issues. I found this issue (https://github.com/mpv-player/mpv/issues/5969) from some time ago which seems to be related, in this haasn comments that the film in question (Mad Max) was mastered at a ridiculously high brightness, perhaps this is the root cause? Would it be possible to tune the desaturation algorithm to be less susceptible to extreme values? (Another side note regarding mastering, I recall your comments https://github.com/mpv-player/mpv/issues/5960 regarding --hdr-compute-peak, would it be valid to change the algorithm here to ignore things that are ridiculously bright in comparison to the rest of the scene? Or would this cause clipping?)

I've tested these films which do not seem to have any desaturation issues when viewing with tone-mapping-desaturate=0.5, not all of these exhibit "extreme" examples of explosions/fire/brightness as such they may not be the best examples for this topic but I thought it would be best to include these in my results for good measure. Annihilation Darkest Hour Fury Harry Potter and the Sorcerer's Stone Jurassic Park (1993) The Dark Knight Rises (odd...) The Lion King (with the exception of the aforementioned issue)

Fims with desaturation issues: Interstellar (This one isn't too bad, it's just extremely bright objects (stars)) The Dark Knight Mad Max (This film is so bright it completely breaks desaturation and compute peak, fire swaps between looking realistic to the "red" that I've shown so extensively in The Dark Knight; and compute peak sees how bright the film is dims the entire film instead of just dimming certain scenes)

The Dark Knight: https://imgbox.com/g/rjS26OpA90 Mad Max: https://imgbox.com/g/33dHrUkeY9

I'm yet to test --tone-mapping-per-channel

[haasn]

Just a few oddities before comparisons, I noticed when jumping through files mpv will often apply extreme desaturation on a frame, then the next frame it will 'recover' and output correct results; see these videos:

This is sadly a known limitation of the way the algorithm works, since the result of the computation is delayed by one frame. I want to rework it to do it frame-perfect, but most likely not as part of mpv. (I'll probably experiment with this stuff in libplacebo first. I have a small-ish test program written to ingest individual frames and run the tone mapping algorithm on it, in case you're interested in helping to test)

To make testing with mpv easier, what you can do is seek to a specific frame (e.g. using --pause --start HH:MM:SS) and then force a redraw (by e.g. showing the OSD). That way the it will only ever use the one frame's average.

Secondly, while testing The Lion King (and Mad Max) I noticed at the very start and end of the film, with desaturation enabled I was getting white artifacts in certain areas, see this clip: https://0x0.st/s5HG.mp4

Is this only with the changes on my branch, or on current master? Does setting --deband=no fix it?

(Side note, why does the OSC have any affect on the VO? Surely this can't be right?)

Updating the OSC triggers a redraw when the frame is paused. Some shaders depend on random state (in particular, the built in --deband does), which gets reseeded even on a redraw.

Would it be possible to tune the desaturation algorithm to be less susceptible to extreme values?

In theory we already did. The conclusion from that issue was to do desaturation after average level adjustment. But maybe for absurd movies like this, using the "hollywood" style tone mapping would be the better solution.

Another side note regarding mastering, I recall your comments #5960 regarding --hdr-compute-peak, would it be valid to change the algorithm here to ignore things that are ridiculously bright in comparison to the rest of the scene?

It's possible, but how would you code that without tracking the values per pixel until the end of the frame? It could maybe be done by storing a histogram of values, but that would explode memory usage. That said, I've been thinking about maybe redesigning the averaging buffer as a sort of temporal "heat map", that design would allow some degree of post-processing. Or at the very least, we could apply the same "decaying buffer" approach to a histogram.

Or would this cause clipping?

There are two inputs to the tone mapping algorithm: scene max and scene average. Scene max is important to prevent clipping, and scene average is what triggers the darkening/lightening (aka "eye adaptation" simulation). We could exclude outliers from the scene average detection without it needing to affect the scene max.

That said, depending on what tone mapping curve is selected, the "scene max" also affects the overall brightness of the result. (Hable in particular is sensitive to the scene max, whereas e.g. mobius or reinhard are not)

[NSQY]

To make testing with mpv easier, what you can do is seek to a specific frame (e.g. using --pause --start HH:MM:SS) and then force a redraw (by e.g. showing the OSD). That way the it will only ever use the one frame's average.

Thanks

Is this only with the changes on my branch, or on current master?

Current master, I first noticed this on the 14th of Dec I believe

Does setting --deband=no fix it?

No, seems to be caused by --sigmoid-upscaling=yes scale=bicubic doesn't seem to suffer from this, both ewa_lanczossharp & Spline36 do

[haasn]

Random thought: What if instead of desaturating towards vec3(luma), we desaturate towards the per-chanenl tone mapped version? That way we will end up using "hollywood"-style desaturation for overly bright regions but still preserve the chromatic accuracy of non-highlights.

[Doofussy2]

Hi @haasn, sorry to horn in but I was helping someone on the Emby forum with what appears to be same issue that is being reported, here. I hope you don't mind, but I'm going to quote from that thread and post a link.

https://emby.media/community/index.php?/topic/67254-option-for-hdr-tone-map-luminance-value-setting/

I noticed MPV handles HEVC differently, quite differently. the color red and yellow are slightly boosted. i busted out my i1Display Pro and strangely both MPV and MPC-HC came out with identical grey scale and color spectrum when i did a full sweep in both environment using my trusted H264/AVC calibration source. for a while i thought i was going crazy. until i did side by side comparison of both MPV (FFmpeg) and MPC-HC (Direct Show) renders and discovered that with H264/AVC they both render identical R709 space and exact same grey scale. however, when the source is HEVC, MPV pushes the yellow and red up higher on the Rec 709, somewhere around maybe 3~4 delta on the spectrum. which is quite significant for anyone to notice comparing side by side. i also noticed this with HDR HEVC UHD sources, which explains my result earlier today when messing around with HDR playback, that MPV tend to have more saturated look.

[haasn]

That post doesn't really contain any useful information.

[haasn]

Random thought: What if instead of desaturating towards vec3(luma), we desaturate towards the per-chanenl tone mapped version? That way we will end up using "hollywood"-style desaturation for overly bright regions but still preserve the chromatic accuracy of non-highlights.

I gave this a try in #6415, and I'm really happy with the results. Numbers could possibly use some tweaking, I just picked something that I think is reasonable by default.

[haasn]

Btw @HyerrDoktyer I think I might know what's causing the issues with random white pixels when desaturating, the way the curve was implemented it could possibly "underflow" for too dark pixels and end up applying super aggressive desaturation.

That bug is fixed as part of #6415 (but not #6410).

[haasn]

I also implemented a totally new design for the HDR peak detection, based on an idea proposed by @CounterPillow. Basically we switched from an FIR filter (running average with sliding window) to an IIR filter (geometric decay).

The new design has several key advantages:

• responds more quickly to changes while remaining relatively stable to fluctuations
• MUCH simpler code, reduced VRAM usage and code complexity massively
• can use much larger averaging windows without running into risk of overflow or VRAM limits
• as a combination of the above benefits, we can make our scene change detection much less aggressive (I bumped up the value from 20 nits to 50 nits and also made it user-configurable).
• (later) can be generalized to keep a heat map per region/pixel instead of frame-global, so we could do more fancy stuff down the line maybe

I pushed these changes onto #6415. Please try it out and let me know what you think.

[shinchiro]

I've compiled the mpv build with the mentioned PR if anyone to test it. ^{_{(since I'm on way of rebuilding my ffmpeg anyway)}}

mpv-x86_64-20190101-git-fee7a96.zip

[aufkrawall]

@haasn Thanks for the changes, the new tonemapping looks way better than the old.

I noticed that there is still kind of "smearing ringing" effect, which with the old tonemapping was caused by low --tone-mapping-desaturate values. It's very visible in the Samsung "Chase the Light" demo and I compared second 23 vs. VLC D3D11:

mpv: https://abload.de/img/mpvabilj.png

vlc D3D11: https://abload.de/img/vlcogf0o.png

That was with hdr-compute-peak=no, as yes still produces a too dark and pulsating result with this video. But the "smearing" effect doesn't seem to be related to if it's enabled or not.

Download the demo here: https://drive.google.com/uc?export=download&id=0Bxj6TUyM3NwjSkdPVGdvUV9KZDA Link taken from here: https://4kmedia.org/samsung-chasing-light-4k-demo/

[Doofussy2]

Using nvdec with hdr-compute-peak=yes, I get a blank screen.

Portable mpv log.txt

D3D11 worked just fine. In that log, I also used `tone-mapping-desaturate=0.0' which turned the screen from all black, to all blue.

[haasn]

@aufkrawall I'm not entirely sure what effect you're referring to, but I think this sample suffers greatly from being over-mastered. Enabling peak detection helps a lot.

Some screenshots of my own:

• new mpv, --hdr-compute-peak=yes
• new mpv, --hdr-compute-peak=no
• old mpv, --hdr-compute-peak=yes
• old mpv, --hdr-compute-peak=no

It's plain as day how much better the new desaturation algorithm performs compared to the old one. (Although this particular sample also works okay without desaturation)

However the peak detection is indeed still a bit sub-par on this sample. In particular, I noticed issues during the initial fade in, followed shortly by the sunrise. This rapid increase in brightness over the course of several frames triggers at least one scene change detection. Maybe we should use the difference between two successive frames rather than the difference between the current frame and the current average, for scene change detection? I can give it a try.

That said, even if we don't trigger any scene change detection, it's still sort of "weird" looking due to the specific timing of the fade in followed by the sun, which makes it sort of adapt twice in a row. Probably no way around this other than to use the HDR10+ dynamic metadata. (Which FFmpeg has a patch for now)

[haasn]

@Doofussy2 pushed a fix for your issue, try again?

[aufkrawall]

Thanks for looking at that sample. Please take a closer look at the sunflower petals. There is ringing around them, at least without peak detection. This is also very extreme in your screenshot without desaturation. You could of course argue that VLC D3D11 looks less saturated. But it's still way more vivid than mpv's previous Hable tonemapping and doesn't seem to show any sign of such artifacts. madVR also looks more vivid than VLC D3D11 and doesn't show such artifacts either (but maybe a slideshow instead :D ).

I'm on Linux right now, will post screenshots of another scene once I booted Windows.

[haasn]

Maybe we should use the difference between two successive frames rather than the difference between the current frame and the current average, for scene change detection? I can give it a try.

Gave it a try. Gets rid of this false positive but introduces others. We need some fundamentally different approach to scene change detection, I think. Maybe we should just bias the IIR towards larger changes somehow. Some crazy thoughts: what if we keep track of the avg/peak in gamma light instead of linear light? More stuff to try, I guess.

FWIW, here's the patch for what I just tested:

diff --git a/video/out/gpu/video.c b/video/out/gpu/video.c
index af7432591b..dbb8f7db27 100644
--- a/video/out/gpu/video.c
+++ b/video/out/gpu/video.c
@@ -2487,6 +2487,7 @@ static void pass_colormanage(struct gl_video *p, struct mp_colorspace src, bool
             uint32_t counter;
             uint32_t frame_sum;
             uint32_t frame_max;
+            float prev_avg;
             float total_avg;
             float total_max;
         } peak_ssbo = {0};
@@ -2512,6 +2513,7 @@ static void pass_colormanage(struct gl_video *p, struct mp_colorspace src, bool
             "uint counter;"
             "uint frame_sum;"
             "uint frame_max;"
+            "float prev_avg;"
             "float total_avg;"
             "float total_max;"
         );
diff --git a/video/out/gpu/video_shaders.c b/video/out/gpu/video_shaders.c
index cc07fa67da..1001d2c45a 100644
--- a/video/out/gpu/video_shaders.c
+++ b/video/out/gpu/video_shaders.c
@@ -615,11 +615,11 @@ static void hdr_update_peak(struct gl_shader_cache *sc,
     // Scene change detection
     if (opts->scene_threshold) {
         float thresh = opts->scene_threshold / MP_REF_WHITE;
-        GLSLF("  float diff = %f * cur_avg - total_avg;\n", scale);
-        GLSLF("  if (abs(diff) > %f) {\n", scale * thresh);
+        GLSLF("  if (abs(cur_avg - prev_avg) > %f) {\n", thresh);
         GLSLF("      total_avg = %f * cur_avg;\n", scale);
         GLSLF("      total_max = %f * cur_max;\n", scale);
         GLSLF("  }\n");
+        GLSL(prev_avg = cur_avg;)
     }

     // Update the current state according to the peak decay function

[haasn]

@aufkrawall on that sample, we can replicate the VLC D3D11 look by fully tone mapping per channel. Does that solve the issue you're having?

If you prefer this kind of look, we could maybe make the new desaturation curve a bit more tunable so you can effectively make it always engage for bright scenes like this.

[Doofussy2]

I was using shinchiro's test build. I'm afraid I'd have to wait for another build. I haven't gotten around to teaching myself how to build my own. But it's on my to-do list. Just need enough time... But I'm happy to run tests.

[aufkrawall]

@haasn Yep, that seems to do the trick. Fantastic! 👍 I suppose that might be an alternative if peak detection has issues or on lowend GPUs. At least the old peak detection was too slow for my Gemini Lake hand calculator. Haven't tried the improved version yet though.

[haasn]

If you prefer this kind of look, we could maybe make the new desaturation curve a bit more tunable so you can effectively make it always engage for bright scenes like this.

No need, the argument range was already high enough. You can just set --tone-mapping-desaturate=1.0 --tone-mapping-desaturate-exponent=0.0 to get it to always desaturate with fuil strength, regardless of the brightness level. (Thanks math!)

[aufkrawall]

I'm really happy how each of the HDR videos I got look that way while the tonemapping is still basically for free regarding GPU performance. I would like the more vivid result of leaving --tone-mapping-desaturate-exponent at its default value even more if there weren't the "ringing" artifacts, but it's a huge improvement over Hable anyway.

The new peak detection is still too heavy for Gemini Lake, while it can deal with 4k 60fps without it (+ dithering and display-resample). mpv is just miraculously well optimized.

[Doofussy2]

I was just doing comparative testing between madvr and mpv. @haasn I think you've nailed it with these new improvements!

Using this video https://4kmedia.org/lg-chess-hdr-demo/

MadVR

New mpv

And this was my config

hwdec=d3d11va hdr-compute-peak=no tone-mapping=hable tone-mapping-desaturate=1.0 tone-mapping-desaturate-exponent=0.0

[haasn]

But wait, there's more!

With help from @daddesio I developed a new scene change detection algorithm that solves the shortcomings of the previous one, thus allowing us to avoid the "eye adpatation" effects while also allowing us to pick a slow averaging filter. It also doesn't break on fades. Give it a whirl. (Pushed to #6415)

Now you should hopefully be able to use --hdr-compute-peak=yes even on stupid samples like the chasing the light one. (Although there's still the problem of the logo at the top right)

[haasn]

Btw, there's a subtle blue tint in the mpv version of those screenshots that I think I've observed while testing too. It goes away for me when using an ICC profile, so maybe our "built in" gamut adaptation algorithm needs improving.

Edit: Never mind, the one I observed is part of the source I'm testing on, and turning on the ICC profile only makes it less noticeable (since I have a wide gamut monitor).

[Doofussy2]

Can somebody whip up test build, please? I haven't got the hang of making my own build, yet. I'd love to test this!

[Doofussy2]

Btw, there's a subtle blue tint in the mpv version of those screenshots that I think I've observed while testing too. It goes away for me when using an ICC profile, so maybe our "built in" gamut adaptation algorithm needs improving.

It has to do with the grayscale, I believe. Here's how it looks in the current mpv release.

[haasn]

I'd also like to point out that I think the new tone mapping (with peak detection enabled + the default desaturation) works really well when using --tone-mapping=mobius instead of hable. Maybe we should even change the default?

[Doofussy2]

Well, I can't test the new stuff you just added, but with shinchiro's test build, this is what I get with that same scene, using mobius.

hdr-compute-peak=yes

hdr-compute-peak=no

hwdec=d3d11va hdr-compute-peak=yes tone-mapping=mobius tone-mapping-desaturate=1.0 tone-mapping-desaturate-exponent=0.0

[Doofussy2]

And with

hwdec=d3d11va hdr-compute-peak=yes tone-mapping=mobius

[haasn]

@Doofussy2 @aufkrawall I checked the source, the thing on her back is actually blue-ish, not white. (it comes out to #25263b in sRGB without any tone mapping)

[Doofussy2]

@Doofussy2 @aufkrawall I checked the source, the thing on her back is actually blue-ish, not white. (it comes out to #25263b in sRGB without any tone mapping)

Oh ok, but it's still really dark. With hable, it seems the correct brightness?

[haasn]

@Doofussy2 I get somewhat different results from you, mind. This is with my latest branch. It's possible we have slightly different versions of the file?

compute=yes, desat=default, curve=hable compute=yes, desat=default, curve=mobius

By the way, I'd prefer it if you used actual movie clips rather than marketing wank.

[Doofussy2]

Yeah, I was saying that I can't test with your latest adjustments. I haven't completely figured out the build process. So I'm testing with the build that shinciro posed, earlier. So it's likely different results.

[aufkrawall]

I probably can test it on Linux tomorrow.

[Doofussy2]

By the way, I'd prefer it if you used actual movie clips rather than marketing wank.

For sure.

[Doofussy2]

So here's a shot from Interstellar at 2:34:10. It's very bright, and I've had some issues when playing this.

hwdec=d3d11va hdr-compute-peak=yes tone-mapping=mobius

hwdec=d3d11va deinterlace=no hdr-compute-peak=no tone-mapping=hable tone-mapping-desaturate=1.0 tone-mapping-desaturate-exponent=0.0

I feel like balance is somewhere in the middle?

[haasn]

I don't have that movie in HDR unfortunately, can you get a clip to me somehow?

Also, I pushed a new option to #6415 that allows adjusting the upper limit on how much to boost dark scenes (by over-exposing them). The current limit was always hard-coded as 1.0, meaning that frames could only ever get darker - never brighter. While you're playing around with this stuff anyway, it might be a good idea to play around with this option as well.

It's possible that a conservative value like --tone-mapping-max-boost=1.2 might help detail recognition on dark scenes without making them look too funny (by being too bright). Thoughts?

[haasn]

I feel like balance is somewhere in the middle?

In theory, that can be accomplished. mobius is tunable (that's sort of the point), and I never put much thought or testing into the default param (0.3). It's possible you could get a more in-between result by using a higher param, perhaps --tone-mapping-param=0.5?

Edit: I think I realize now what you actually mean: basically, the scene is very bright, but mpv makes it look "normal" brightness again, and you want it to "remain" bright? That's sort of a difficult thing to balance with the ability to play e.g. shit like mad max which is mastered at "sun brightness" levels. Those movies would end up entirely bright if we put an upper limit on how much we can darken stuff.

[Doofussy2]

That whole scene is swirling brightness. And much of it can be too bright, but only just. It's hard to describe. The whole movie is kinda too bright. That scene goes drectly from darkness, to super bright. When I compare it to watching it with the metadata passed to my display, it's still super bright, but I can see a little more detail. I'm going to try tuning mobius, and see what I get.

[Doofussy2]

So here's what that looks like with;

hwdec=d3d11va hdr-compute-peak=yes tone-mapping=mobius tone-mapping-param=0.1

Which isn't horrible...just a little dim. You really should get a hold of the whole movie. The lighting and color/saturation throughout the whole movie is kinda odd. But this is closer to what it should be, I think. Hable is I think a little too bright. But this is pretty extreme. Changing the param didn't make a lot of difference.

hwdec=d3d11va hdr-compute-peak=yes tone-mapping=mobius tone-mapping-param=0.5

[Doofussy2]

Actually, I'm going to stick with hable. There a lot of other bright scenes that now look better, to me. Like this one