Help in Coding: "Dynamic Contrast" option for projector home theaters

[stonix015]

Hey dear guys, i will put this here, because i think that it belongs to libplacebo and not to mpv (as the gpu-next mode mostly uses libplacebo features)
Maybe someone can help me:

Situation
On a home theater with a projector setup, there are some kind of 2 different contrasts which decide about the image quality:

1. One is the static on-off contrast, which can reach very high values (100'000:1 with some JVC, at least 10'000:1 with some Epson/Sony projectors. PLUS the additional dynamic IRIS contrast)
2. One is the optics / room / chess-field response of the system, for which even 200:1 would be a great value to aim for (regarding not only the room response, but also the optics response of the device)

This results in a visibly degradation of details on my JVC beamer in bright scenes: In dark areas, loads of details are flattened out.
Setting the "target-contrast" option to 1'000 or lower values helps this out.
On the other hand setting this value also results in a horrible black level in dark scenes, horror movies, and so on. For those, i'd rather chose a value in between of 20'000 to 50'000.

Idea
What i now want to code is some kind of an option like a dynamic display-blacklevel that depends on the in-picture (picture by picture, like in the hdr-peak-detect feature) max-luma.
Something like: dst.min_luma = src.max_luma / 1000

I have found out so far, that the gpu-next mappings are all sourced in the libplacebo package.
What i tried out was:
libplacebo / src / tone_mapping.c : L558 in the function static void spline(float *lut, const struct pl_tone_map_params *params)
new_output_min = params->input_max / 1000;
and for the rest of the function changing all params->output_min to new_output_min
This resulted in loads of compiling errors and i recognized that i didnt even understand the complexity of the code. (Which values are contained by these variables? values from 0 to 1.0 as floats? or values from -0.5f to 0.5f with an offset?

Is anyone here with a bigger insight of the source code, who can help me out?
I think it SHOULD be a simple job when knowing where to put this "feature".
But i do not have any clue where....

Very much greetings,
Lukas

[haasn]

Edit: Fixed version:

diff --git a/src/shaders/colorspace.c b/src/shaders/colorspace.c
index 7d1927dd..3a033640 100644
--- a/src/shaders/colorspace.c
+++ b/src/shaders/colorspace.c
@@ -1682,6 +1682,12 @@ void pl_shader_color_map_ex(pl_shader sh, const struct pl_color_map_params *para
         tone.output_max = PL_MIN(tone.output_max, tone.input_max);
     }
 
+    const float max_contrast = 1000;
+    const float src_nits = pl_hdr_rescale(tone.input_scaling, PL_HDR_NITS, tone.input_max);
+    const float min_black = pl_hdr_rescale(PL_HDR_NITS, tone.input_scaling,
+                                           src_nits / max_contrast);
+    tone.output_min = PL_MAX(tone.output_min, min_black);
+
     const int *lut3d_size_def = pl_color_map_default_params.lut3d_size;
     struct pl_gamut_map_params gamut = {
         .function        = PL_DEF(params->gamut_mapping, &pl_gamut_map_clip),

Try something like this?

diff --git a/src/shaders/colorspace.c b/src/shaders/colorspace.c
index 7d1927dd..5e200f35 100644
--- a/src/shaders/colorspace.c
+++ b/src/shaders/colorspace.c
@@ -1682,6 +1682,10 @@ void pl_shader_color_map_ex(pl_shader sh, const struct pl_color_map_params *para
         tone.output_max = PL_MIN(tone.output_max, tone.input_max);
     }
 
+    const float max_contrast = 1000;
+    const float min_black    = tone.input_max / max_contrast;
+    tone.output_min = PL_MAX(tone.output_min, min_black);
+
     const int *lut3d_size_def = pl_color_map_default_params.lut3d_size;
     struct pl_gamut_map_params gamut = {
         .function        = PL_DEF(params->gamut_mapping, &pl_gamut_map_clip),

If it turns out to be useful, we could easily add this feature, as a sort of dynamic contrast limiter.

[haasn]

Oh, this doesn't quite work, because these numbers are in PQ scale. Let me fix it.

[stonix015]

I have made a small adaption, the whole if function looks like that now:

if (!params->inverse_tone_mapping) {
        // Never exceed the source unless requested / White Level Adaption
        tone.output_max = PL_MIN(tone.output_max, tone.input_max);

        //Adaptions on Black Level
        float divider = tone.input_max / tone.output_max;   // If the HDR content is brighter than the spec. display brightness, the whole picture will be scaled down to the display, therefore the input_avg has to be scaled to an "output_avg"
        const float output_avg = tone.input_avg / divider;  // Calculation of output_avg
        const float dst_nits = pl_hdr_rescale(tone.input_scaling, PL_HDR_NITS, output_avg);

        const float max_contrast = 150;
        const float min_black = pl_hdr_rescale(PL_HDR_NITS, tone.input_scaling, dst_nits / max_contrast);
        tone.output_min = tone.output_min + min_black;
 }

This adapts to the fact that HDR content can be much brighter than the display and will, in that case, be scaled down to the SDR display.
In this case, the input_avg is not sufficient and in extreme cases can even be above the max output-level.
We need some kind of an "output-avg". This function is a bit fishy, but for now it does the job. Maybe there is a more elegant / exact solution.

Greetings,
Lukas!

[haasn]

I think we should probably do this handling inside the function that also computes the target knee, since that one is pretty smart about the expected output signal level.

[stonix015]

Hey again,

I am still developing here. Your Tips helped me alot to understand how your Code works. The abstraction layer with the PL_* functions and the variables params->* and tone.* were basically what was missing to me before.

Blah Blah Blah
I tested it yesterday and found out, that the projector itself has a really strong non-linear behavior.
Scenes with an average of 0,1cd/m2 were already problematic, and i had to raise the black level in mpv to additional 0,1cd/m2.
Scenes with an average of 20cd/m2 still demanded for around 0,15cd/m2 raise.
But Scenes with an average of 0,01cd/m2 (which are btw still very visible for the human eye) should remain on the original black level without adaptions.

This led me into concepting a non-linear adaptive filter. Starting with a max_contrast=1 @ 0cd/m2 and ending with a max_contrast=100 @ 20cd/m2.
I think that this is so sloppy that it shouldn't be implemented as a commercial filter :(
It is just highly adapted to my situation. Additionally i tested some settings of the projector, and it also has a Gamma-setting "A" beyond the "normal" setting, which adapts to a better toning in dark areas. This setting helped me a lot here. I am still testing and thinking and developing. And don't forget of the non-enjoyable movie-evenings, in which i'm just permanently fooling around with the settings.

In the end:
Maybe we should develop the feature as mentioned in your first answer:

• static max_contrast
• setable as a parameter in the .conf
• using the input_avg
• implemented in the target-knee section

Iit should help someone out there in this world wide web. It still helped a lot on bright scenes. It's not yet as if it didn't do anything ;-)

[haasn]

Rather than basing it off the source peak, it might make more sense to base it off either the source average, source median, or some histogram value (e.g. 10%). If you want to try with the source average, just swap out tone.input_max for tone.input_avg in the above diff.

For the median/histogram, we already have measurements in place for this but it's a bit annoying to plumb the relevant values out to this call site. At best I can recommend to play with the existing percentile setting to see what works best.

[stonix015]

I will try everything out of this code! This REALLY helps me a lot, this is so much farer away for me from knowing nothing, like before.

The rest should be some simple maths tricks / or playing around.

[stonix015]

MAN !!! THIS WORKS!!!!

i am so close to tears right now :D this is so fascinating, it is unbelievable to see this thing doing its job.

really really really really thank you! So much!

[stonix015]

clearly i have used the avg-option but not the max-version ...... As you stated: This makes more sense as it is the energy of light emitted to the room and therefore backthrown onto the picture.
Ive used a value of around "100" for that, as, to be honest, this is a realistic value in a realistic scenario. And i do not think that i am bigger than 70:1 in my setting and my living room.

[haasn]

So, do you think we should wrap this up as a new feature and have it default to 100:1?

[stonix015]

From my side, why not. (I do not know how your policies are, regarding jamming the software with too much functionality)

I have encountered a small problem: As the feature kicks in and changes the contrast, mpv gets very very laggy under openGL, with frame drops (every 2nd frame will be dropped, and also even worse than that).

The frame timings are just like without the feature. And the maths cannot be the problem (because even if the feature does not kick in due to PL_MIN(tone.output_min,black_min), the mpv runs flawlessy).
With vulkan under wayland it runs flawless.

[stonix015]

The other question would be if it might be senseful to use a variable in mpv, which can be set. Some kind of "dynamic room response contrast", which defaults to "inf" and then deactivates this feature. This might be the easiest way.