To avoid triggering huge scene change detections when only a tiny part
of the image contains nonzero data, even though the average values may
jump around wildly in such a case.

Fixes: videolan/libplacebo#298

Force them to go through the normal update logic.

Slightly more convoluted than the previous approach but lets us know
exactly what percentage of the scene was actually black, which may come
in handy in the future.

This should not be silently ignored or re-tried later, since it's a
serious error.

Since 31082eee it's possible for frame_wg_count to not get
incremented, in particular, for all black WGs. This may lead to the
scenario where frame_wg_count is 0 for the frame/slice. Avoid false
positive on the allow_delayed check and also handle this case correctly
by introducing explicit `frame_ready` field which is set to 1 once per
compute shader invocation.

Fixes: 31082eee

Experimental testing on a variety of scenes revealed a value of 20.0 to
be more generally responsive, while still eliminating flicker. (Flicker
is still somewhat noticeable at 10, but 20 completely eliminates it)

Based on experimental testing on real content, I determined the "safe"
value for in-scene PQ fluctuation to be around 1%, with hard scene
changes being as low as 2% and generally above 2.5%-3%. So, set the
upper threshold to 3% to be on the safe side.

Fixes problems with sluggish reactions to scene changes in a number of
problematic scenes.

And leave a #define alias in its place. (Probably permanently, since we
can't put a deprecation warning on it...)

HDR10+ metadata is buggy enough in practice (and often just
auto-generated by stupid process), to make me prefer setting spline by
default.

Significantly improves peak detection result on frames containing many
black pixels (e.g. hardcoded black bars). In real content, truly black
pixels are incredibly rare, so this is pretty safe to do.

Only requires one extra group shared atomic and some once-per-WG code. I
briefly played with the idea of including this implicitly in the
histogram measurement, but it was more complicated to do so and limits
it to the case of histogram being enabled.

No need to repeat this boilerplate.

This needs to use the same luma coefficients as the RGB space of the
*encoding*, not the color volume (csp.hdr.prim).

It makes little sense for `preset=default` to override options that
conceptually exist outside the pl_options system, or are loaded via
special mechanism, such as hooks, info callback and custom LUT.

Fixes: https://github.com/mpv-player/mpv/issues/12278

But still prefer peak detection over dynamic per-scene HDR10+ metadata,
since the latter produces significantly worse results in practice.

The `spline` function has become good enough to outperform all of the
other tone-mapping functions in all of the listed cases. There is no
more need for this hacky auto-selection logic. Just pick spline in all
cases.

The sole exception is with the availability of HDR10+ dynamic metadata
(OOTF), which still outperforms spline as a result of the OOTF baking in
artistic intent.

Mirroring pl_get_detected_hdr_metadata. Heavily requested by users, to
be able to introspect current detected HDR peak and average.

This is the wrong layer to solve this problem, and in particular,
hard-coding SDR 1.0 here prevents tone-mapping e.g. 200 nits scene to
50 nits projector. No longer needed hack now that we clamp in the tone
mapper directly.

Do this before clamping output_max because pl_tone_map_params_infer can
change these parameters.

Moves this into the more appropriate plce.

To avoid trying to tone-map values significantly below SDR white, even
with inverse tone-mapping enabled. Avoids explosions on black frames
etc, and is a better work-around than the status quo.

Since I plan on making pl_tone_map_params_infer() clamp/change these.

With the new dynamic adaptation tuning, we don't need to set such
excessively high adaptation tuning values by default. Lower it to a much
lower value. Greatly increases consistency of tone-mapping when
comparing the same scene mastered at different nits levels.

Based on how close the target knee point is towards the 'extreme' values
(min/max knee), we raise the adaptation strength dynamically.
Significantly improves visual appearance of very bright/dark scenes,
especially the sulphur pools clip.

This does not change the calculated logic, it just makes the code flow
slightly easier to follow (especially in anticipation of upcoming
changes to the logic I intend to try/make).

Tradeoffs, tradeoffs. This makes some less extreme samples a bit easier
on the eyes and less "blown out" looking. Slightly regresses asuka, but
oh well.

See previous commit.

In retrospect I don't really care about advertising the 1e-6 safety
margin here, because it's already clamped inside fix_constants(). It
really just is there to avoid the functions from numerically exploding,
"conceptually" you should be able to set the absolute limits anyway.

Makes my life easier when adjusting these constants in the future
because it avoids duplicating this stupid implementation detail in 3
places.

This was not in nits scale.

Helps with preserving chromaticity in very challenging scenes.

See-Also: https://github.com/mpv-player/mpv/issues/12259

Significantly improves chromaticity retention in some problematic
scenes, without causing too much clipping.

Fixes: https://github.com/mpv-player/mpv/issues/12259

The intent of this test is to ensure that primaries map onto primaries,
which only makes sense when the saturation mapping strength is at 100%.
Force this for the sake of the test.

Allows scaling down the intensity of the saturation mapping step.

Static HDR10 metadata may lie about the actual luminance range of the
source. To be more conservative, use only the true max peak luminance
for this check. This will still disable peak detection if outputting to
full range PQ, or if using tuned HLG, but will enable peak detection
otherwise (for standard HDR content) - even if HDR10 metadata claims it
would not be needed.

Fixes: https://github.com/mpv-player/mpv/issues/12252

vec1 doesn't exist, need to use sh_float_type here.

Slight simplification, especially for upcoming fix.

This is not interesting to users or for debugging.

No need to print the nitty gritty details here at PL_DEBUG verbosity,
just print a condensed summary.

Since this happens at per-frame level in mpv. Not entirely happy with
this solution but it's better than spamming log. And in practice, we
know what options are being applied anyway, since mpv already logs
`--libplacebo-opts`.