From 3fe882d4ae80fa060a71dad0d6d1605afcfe98b6 Mon Sep 17 00:00:00 2001 From: Niklas Haas Date: Thu, 27 Dec 2018 18:34:19 +0100 Subject: vo_gpu: improve tone mapping desaturation Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve. --- DOCS/interface-changes.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'DOCS/interface-changes.rst') diff --git a/DOCS/interface-changes.rst b/DOCS/interface-changes.rst index cbc9af18f8..7e723b9dbe 100644 --- a/DOCS/interface-changes.rst +++ b/DOCS/interface-changes.rst @@ -47,6 +47,10 @@ Interface changes - support for `--spirv-compiler=nvidia` has been removed, leaving `shaderc` as the only option. The `--spirv-compiler` option itself has been marked as deprecated, and may be removed in the future. + - split up `--tone-mapping-desaturate`` into strength + exponent, instead of + only using a single value (which previously just controlled the exponent). + The strength now linearly blends between the linear and nonlinear tone + mapped versions of a color. --- mpv 0.29.0 --- - drop --opensles-sample-rate, as --audio-samplerate should be used if desired - drop deprecated --videotoolbox-format, --ff-aid, --ff-vid, --ff-sid, -- cgit v1.2.3 From 6179dcbb798aa9e3501af82ae46975e881d80626 Mon Sep 17 00:00:00 2001 From: Niklas Haas Date: Tue, 1 Jan 2019 07:30:00 +0100 Subject: vo_gpu: redesign peak detection algorithm The previous approach of using an FIR with tunable hard threshold for scene changes had several problems: - the FIR involved annoying hard-coded buffer sizes, high VRAM usage, and the FIR sum was prone to numerical overflow which limited the number of frames we could average over. We also totally redesign the scene change detection. - the hard scene change detection was prone to both false positives and false negatives, each with their own (annoying) issues. Scrap this entirely and switch to a dual approach of using a simple single-pole IIR low pass filter to smooth out noise, while using a softer scene change curve (with tunable low and high thresholds), based on `smoothstep`. The IIR filter is extremely simple in its implementation and has an arbitrarily user-tunable cutoff frequency, while the smoothstep-based scene change curve provides a good, tunable tradeoff between adaptation speed and stability - without exhibiting either of the traditional issues associated with the hard cutoff. Another way to think about the new options is that the "low threshold" provides a margin of error within which we don't care about small fluctuations in the scene (which will therefore be smoothed out by the IIR filter). --- DOCS/interface-changes.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'DOCS/interface-changes.rst') diff --git a/DOCS/interface-changes.rst b/DOCS/interface-changes.rst index 7e723b9dbe..ce7e33176a 100644 --- a/DOCS/interface-changes.rst +++ b/DOCS/interface-changes.rst @@ -51,6 +51,7 @@ Interface changes only using a single value (which previously just controlled the exponent). The strength now linearly blends between the linear and nonlinear tone mapped versions of a color. + - add --hdr-peak-decay-rate and --hdr-scene-threshold-low/high --- mpv 0.29.0 --- - drop --opensles-sample-rate, as --audio-samplerate should be used if desired - drop deprecated --videotoolbox-format, --ff-aid, --ff-vid, --ff-sid, -- cgit v1.2.3 From 12e58ff8a65c537a222a3fb954f88d98a3a5bfd2 Mon Sep 17 00:00:00 2001 From: Niklas Haas Date: Wed, 2 Jan 2019 03:03:38 +0100 Subject: vo_gpu: allow boosting dark scenes when tone mapping In theory our "eye adaptation" algorithm works in both ways, both darkening bright scenes and brightening dark scenes. But I've always just prevented the latter with a hard clamp, since I wanted to avoid blowing up dark scenes into looking funny (and full of noise). But allowing a tiny bit of over-exposure might be a good thing. I won't change the default just yet (better let users test), but a moderate value of 1.2 might be better than the current 1.0 limit. Needs testing especially on dark scenes. --- DOCS/interface-changes.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'DOCS/interface-changes.rst') diff --git a/DOCS/interface-changes.rst b/DOCS/interface-changes.rst index ce7e33176a..2fd30628d8 100644 --- a/DOCS/interface-changes.rst +++ b/DOCS/interface-changes.rst @@ -52,6 +52,7 @@ Interface changes The strength now linearly blends between the linear and nonlinear tone mapped versions of a color. - add --hdr-peak-decay-rate and --hdr-scene-threshold-low/high + - add --tone-mapping-max-boost --- mpv 0.29.0 --- - drop --opensles-sample-rate, as --audio-samplerate should be used if desired - drop deprecated --videotoolbox-format, --ff-aid, --ff-vid, --ff-sid, -- cgit v1.2.3