Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

Not sure what to make of this, do I have a setting wrong somewhere?

certainly a big difference there

the madvr one is really dark and comes out of black extremely slowly
jrvr is faster to come out of black, shows more even spacing but is squashed at the top and doesn't quite get as bright

they surely don't have the same gamma targets do they?

[Hendrik]

Your AVS709 pattern with madVR doesn't even have a black background, its just grey. That doesn't seem right.

[FenceMan]

certainly a big difference there

the madvr one is really dark and comes out of black extremely slowly
jrvr is faster to come out of black, shows more even spacing but is squashed at the top and doesn't quite get as bright

they surely don't have the same gamma targets do they?

I am using the same 3dlut profile but JRVR is set to bt.1886 and MadVR is set to 2.2 (think it has to be).

Thats why I provided the source so others can try.

[mattkhan]

mine (using my current HDR settings in madvr and jrvr) comes out like https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=edc50f14-3e69-11ee-b5bd-6595d9b17862

I wrote a quick little script to pull out the RGB values from each bar and diff them which gives the following

(step is the change in the avg rgb level from one bar to the next for each renderer, delta is the difference between the avg for each renderer on the same bar)

Code: [Select]

$ ~/bin/get_colours.sh /media/home-media/greyscale_madvr.png /media/home-media/greyscale_jrvr.png                                                                                                                   
patch  | madvr       | avg | step | jrvr        | avg | step | delta
1      | 0,0,0       | 0   | 0    | 1,1,1       | 1   | 1    | -1
2      | 4,4,4       | 4   | 4    | 9,9,9       | 9   | 8    | -5
3      | 14,14,14    | 14  | 10   | 23,23,22    | 22  | 13   | -8
4      | 27,27,26    | 26  | 12   | 40,41,40    | 40  | 18   | -14
5      | 45,46,45    | 45  | 19   | 68,67,66    | 67  | 27   | -22
6      | 73,74,72    | 73  | 28   | 103,105,101 | 103 | 36   | -30
7      | 114,115,114 | 114 | 41   | 147,148,144 | 146 | 43   | -32
8      | 158,160,158 | 158 | 44   | 185,184,182 | 183 | 37   | -25
9      | 199,201,198 | 199 | 41   | 209,215,210 | 211 | 28   | -12
10     | 230,233,229 | 230 | 31   | 231,237,232 | 233 | 22   | -3
11     | 250,254,249 | 251 | 21   | 249,250,245 | 248 | 15   | 3 

which makes it easy to see that madvr is generally darker until the top end, that jrvr doesn't get so bright and that the steps are much closer together at the top

Code: [Select]

#!/bin/bash
MID=175
y=540

printf "%-6s | %-11s | %-3s | %-4s | %-11s | %-3s | %-4s | %-3s\n" "patch" "madvr" "avg" "step" "jrvr" "avg" "step" "delta"
for v in {0..10}
do
    x=$((MID + $((349 * v))))
    crop="1x1+${x}+${y}"
    madvr_rgb=$(convert $1 -crop "1x1+${x}+${y}" -format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-)
    jrvr_rgb=$(convert $2 -crop "1x1+${x}+${y}" -format '%[fx:int(255*r+.5)],%[fx:int(255*g+.5)],%[fx:int(255*b+.5)]' info:-)
   
    IFS=',' read -r -a madvr_vals <<< "${madvr_rgb}"
    IFS=',' read -r -a jrvr_vals <<< "${jrvr_rgb}"
    madvr_step=
    jrvr_step=
    prev_m=
    prev_j=
    if [[ ${v} -gt 0 ]]
    then
        prev_m=${madvr_avg}
        prev_j=${jrvr_avg}
    fi
    madvr_avg=$(((madvr_vals[0] + madvr_vals[1] + madvr_vals[2]) / 3))
    jrvr_avg=$(((jrvr_vals[0] + jrvr_vals[1] + jrvr_vals[2]) / 3))
           
    delta=$((madvr_avg - jrvr_avg))
    madvr_step=$((madvr_avg - prev_m))
    jrvr_step=$((jrvr_avg - prev_j))

    printf "%-6s | %-11s | %-3s | %-4s | %-11s | %-3s | %-4s | %-3s" $((v+1)) ${madvr_rgb} ${madvr_avg} ${madvr_step} ${jrvr_rgb} ${jrvr_avg} ${jrvr_step} ${delta}
    echo ${out}
done


[mattkhan]

same output for your files

Code: [Select]

~/bin/get_colours.sh MadVRGrey.png JRVRGrey.png                                                                                                                                                                     
patch  | madvr       | avg | step | jrvr        | avg | step | delta
1      | 6,5,3       | 4   | 4    | 1,2,0       | 1   | 1    | 3 
2      | 11,10,9     | 10  | 6    | 20,20,17    | 19  | 18   | -9
3      | 18,18,17    | 17  | 7    | 34,35,34    | 34  | 15   | -17
4      | 29,28,28    | 28  | 11   | 56,54,53    | 54  | 20   | -26
5      | 44,44,43    | 43  | 15   | 80,78,78    | 78  | 24   | -35
6      | 68,65,65    | 66  | 23   | 110,113,112 | 111 | 33   | -45
7      | 97,97,97    | 97  | 31   | 150,150,148 | 149 | 38   | -52
8      | 141,140,141 | 140 | 43   | 186,182,182 | 183 | 34   | -43
9      | 196,195,196 | 195 | 55   | 215,210,210 | 211 | 28   | -16
10     | 235,235,235 | 235 | 40   | 236,231,232 | 233 | 22   | 2 
11     | 255,255,255 | 255 | 20   | 248,250,250 | 249 | 16   | 6 

yours shows a much bigger difference between the two

[mattkhan]

posting the numbers just to quantify the comparison between them, not exactly sure (certainly at this time of morning!) how to relate that to what the correct values should be for a given gamma

[mattkhan]

in visual form, straight line is the input (equally spaced bars), blue is madvr, red is jrvr, green is just straight line with a 2.2 gamma (was seeing if it approximated that)

[Hendrik]

As far as I know, madVR tonemaps to 2.2 gamma, while we by default use BT.1886. You can swap to 2.2 by setting that on the calibration page, if you want a comparison. This would get it closer, I believe.

As for bright sections being blown out, this pattern doesn't really demonstrate that.
What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.

If you can post a sample that demonstrates that problem it might be helpful. Real content is fine too, test samples only go so far.

[mattkhan]

If you can post a sample that demonstrates that problem it might be helpful. Real content is fine too, test samples only go so far.

already posted here - https://yabb.jriver.com/interact/index.php/topic,136378.msg947320.html#msg947320

As far as I know, madVR tonemaps to 2.2 gamma, while we by default use BT.1886. You can swap to 2.2 by setting that on the calibration page, if you want a comparison. This would get it closer, I believe.

personally I'm not trying to get closer to madvr as such, I'm just using it as something to compare to

As for bright sections being blown out, this pattern doesn't really demonstrate that.

it's an attempt to quantify what is seen in the above, the steps are probably a bit too far apart to really examine this aspect (probably need to do the top x 10% in 1% steps or something like that) it but it does hint at the problem in that the steps are closer together at the top end in jrvr and there is an S shaped curve. That certainly seems like white crush like behaviour to me.

What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.

mine is set to 100nit target already, spline contrast is not making an obvious difference to the top end for me. If I get time, I could measure that pattern with different spline contrast values to see what difference it makes though I guess that curve is in the code somewhere so could be seen somehow?

[FenceMan]

in visual form, straight line is the input (equally spaced bars), blue is madvr, red is jrvr, green is just straight line with a 2.2 gamma (was seeing if it approximated that)

Amazing work thanks.  So you are seeing the difference but for whatever reason mine is more drastic?  This might finally quantify what I keep saying - MadVR looks dull to me compared to JRVR so maybe it is but also I am doing something to make it worse than it actually is?

[FenceMan]

Here is what I get if I take my 3dlut out of the equation and set both JRVR and MadVR to 2.2 gamma -

https://cdn.knightlab.com/libs/juxtapose/latest/embed/index.html?uid=eceeb59e-3e7e-11ee-b5bd-6595d9b17862

[mattkhan]

Amazing work thanks.  So you are seeing the difference but for whatever reason mine is more drastic?  This might finally quantify what I keep saying - MadVR looks dull to me compared to JRVR so maybe it is but also I am doing something to make it worse than it actually is?

what are your settings in each?

[mattkhan]

What I would recommend to try with tonemapping to a low target like 100 nits, set the tone mapping algorithm to Spline and try different ranges of Spline Contrast, to tune the behavior of bright and dark sections to your preference.

I don't think this is a solution as spline is described as a "Perceptually linear single-pivot polynomial" which you can see in this chart, in this case I made a new test pattern with 1% steps and then plotted the average rgb value at each point for a number of different spline values. I gather the knee point is configurable in PQ space but don't know how that translates here directly except that we can clearly see the pivot is at the 50% grey point. No smoothing in this so the curves are a little wobbly but I don't think that changes the point being made.

It means changing this value affects both top and low end in exactly the same way which, I would guess, is not going to be a good trade.

in addition, spline 1.5 looks like it's too high a value to be safely allowed given how hard it clips.

it might be interesting to look at the average level of that horse shot later to see where it falls on the curve.

[mattkhan]

what value does jrvr set for that knee point? can it be made user configurable?

[mattkhan]

for comparison, sdr added

[haasn]

what value does jrvr set for that knee point? can it be made user configurable?

I was planning on making it more user-tunable, yes. The value is chosen by complicated algorithm taking into account both the input and output brightness range and scene average luminance. I can explain it in more detail tomorrow, I threw it together in half a day. Improvements definitely are possible.

[haasn]

Btw, for tuning tone-mapping curves I definitely recommend looking at libplacebo's own LUT visualization graph. I don't know if JRVR exposes it anywhere (though iirc it should be on the overlay somewhere, or something?)

It will show you the tone mapping step exclusively (in PQ-PQ space)

[mattkhan]

there's the attached but I have no idea how to read it, is that what you mean?

[haasn]

Yeah, that's the one. What this graph is showing is that it's (on this scene) just doing a perceptually linear (PQ space) stretch, to from the source luminance to the (slightly lower) target luminance.

Regions in deep blue in the graph are where the output image is darker than the input image. (The slice of the gamut mapping 3DLUT in the background can be ignored). (The big blue bar at the top shows the portion of PQ space that the input image is not using, and hence does not need to be tone-mapped; the red bar below it shows the portion of PQ space that the source uses but which is unavailable for output)

[FenceMan]

This is not scientific at all but I have watched probably 10 full length films since build 43 was posted and everything looks amazing.

I am sure there are more improvements to be made but this is really in a good place right now.

[mattkhan]

Yeah, that's the one. What this graph is showing is that it's (on this scene) just doing a perceptually linear (PQ space) stretch, to from the source luminance to the (slightly lower) target luminance.

does the rectangular block show the 0-10000 nits range in absolute terms? the red block seems to be it seems to be ~13% of the total height so that equates to 13% of 10k or some other value? given the target nits in this example is 100 then that's basically invisible on such a view but if I had a higher target then I might be able to distinguish it?

is the perceptually linear stretch show by the straight diagonal line or something else?

[haasn]

does the rectangular block show the 0-10000 nits range in absolute terms? the red block seems to be it seems to be ~13% of the total height so that equates to 13% of 10k or some other value? given the target nits in this example is 100 then that's basically invisible on such a view but if I had a higher target then I might be able to distinguish it?

is the perceptually linear stretch show by the straight diagonal line or something else?

The graph is in PQ space. So it shows all PQ codepoints (from 0 to 1023), not nits levels. It's perceptually linear because the diagonal line is straight, yeah. (The gray line is the neutral axis, i.e. what you get from "clip" tone mapping)

[Hendrik]

The graph is in PQ, not in nits. Its a non-linear distribution, on a 0-1 scale, RGB 100% White is at around 0.58 (203 nits), from a quick test 100 nits is at around 0.51. PQ in on the X axis (horizontal), PQ out on the Y axis (vertical).

Decoding guide (including what haasn said):
- The blue area on top is unused brightness, as the source was not that bright
- The red area on top is brightness the source used, but the target does not have (what needs to be tone mapped)
- The main diagonal line goes from the origin to the top right corner of the used source brightness (from bottom left to the right border, where the red and blue areas meet)
- The second curve is from the origin to the bottom of the red area - the tone mapping curve. The area between the main diagonal and the tone mapping curve is colored to indicate the change to the image in that area, blue when it gets darker, green when it gets brighter.
- The vertical white line is the average brightness of the image right now.

The leaf in the background is a visualization of the gamut mapping and can be ignored for this purpose.

[mattkhan]

The graph is in PQ space. So it shows all PQ codepoints (from 0 to 1023), not nits levels. It's perceptually linear because the diagonal line is straight, yeah. (The gray line is the neutral axis, i.e. what you get from "clip" tone mapping)

right ok thanks for explaining (and +1 to Hendrik for further clarification)

does the existing option (that isn't accessible in jrvr but is in mpv) for moving the knee basically move the inflection point up/down the (what appears to be a sigmoid) curve or is it doing something more complex/dynamic than that?

[Hendrik]

Which parameter is that? As far as I can see there is only one parameter for tone mapping functions, and for spline thats the one I exposed in the settings.

[mattkhan]

Mpv docs describe it as

Specifies the knee point (in PQ space). Defaults to 0.30.

Is that what you call spline contrast? The effect didn't really look like moving a knee to me hence I supposed it was something else

[Hendrik]

That is the option JRVR exposes. The description is probably just incorrect/outdated, it happens when stuff needs to be adapted in so many spots. The default is 0.50 even in the code, and it controls the slope more.

[FenceMan]

That is the option JRVR exposes. The description is probably just incorrect/outdated, it happens when stuff needs to be adapted in so many spots. The default is 0.50 even in the code, and it controls the slope more.

The Spline contrast adjustment seems to be disabled if auto-select tone mapping is chosen, is that intentional?  So we cannot adjust the knee point and have it set to auto-select?

[Hendrik]

That is correct. The parameter can only be changed with a specific algorithm selected.

[haasn]

So, the way the algorithm currently works, at a high level, is this:

Let SrcAvgPQ be the source average level (in PQ), SrcMinPQ and SrcMaxPQ (resp DstMinPQ and DstMaxPQ) be the source minimum and maximum PQ level.

Then,
SrcRange := SrcMaxPQ - SrcMinPQ
DstRange := DstMaxPQ - DstMinPQ
SrcKneeMinimum := Mix( SrcMinPQ, SrcMaxPQ, 0.1 )
SrcKneeMaximum := Mix( SrcMinPQ, SrcMaxPQ, 0.8 )
DstKneeMinimum := Mix( DstMinPQ, DstMaxPQ, 0.1 )
DstKneeMaximum := Mix( DstMinPQ, DstMaxPQ, 0.8 )

SrcKnee := Clamp( SrcAvgPQ, SrcKneeMinimum, SrcKneeMaximum )
KneeRescaled := (SrcKnee - SrcMinPQ) * DstRange / SrcRange + DstMinPQ
KneeAdapted := Mix( SrcKnee, KneeRescaled, AdaptionStrength )
DstKnee := Clamp( KneeAdapted, DstKneeMinimum, DstKneeMaximum )

The resulting SrcKnee and DstKnee values give the knee point - meaning an input value of SrcKnee will get mapped exactly onto DstKnee, with every value in between being smoothly interpolated. The spline slope contrast effectively determines the steepness of the curve at this knee point.

The adaptation strength (for KneeAdapted) is currently hard-coded as 0.7, alongside the knee minimum/maximum at 0.1 and 0.8 of the respective range. The spline function slope tuning is even more ad-hoc and involves two more magic parameters that I don't have time to get into atm. It's all pretty hacky and thrown together in the span of a few hours of testing.

I'd be very welcome to improvements for how to pick a better knee point / scene average brightness target.

[haasn]

The Spline contrast adjustment seems to be disabled if auto-select tone mapping is chosen, is that intentional?  So we cannot adjust the knee point and have it set to auto-select?

This will be fixed by https://code.videolan.org/videolan/libplacebo/-/merge_requests/546 which will also make all of the other magic constants tunable. (such as the adaptation strength)

[mattkhan]

I'd be very welcome to improvements for how to pick a better knee point / scene average brightness target.

I know I'm not competent to be able to advise on that I can only suggest that given that, in terms of what is in the output image, the current parameter appears to affect the low and top end symmetrically then I'd look at ways to tune those independently and/or move the inflection point.

is there some reason that it needs to be symmetrical in the way it is atm?

[haasn]

is there some reason that it needs to be symmetrical in the way it is atm?

Not really, it's just a consequence of how the curve was formulated. For 'spline' we fit a 2nd order polynomial below the knee point and a 3rd order polynomial above the knee point. The only other constraint is that the slope at the knee point should be continuous. But apart from that, the value we pick for that slope is arbitrary (hence why you can tune it).

This gives you the sort of 'sigmoid' style shape we observe, where increasing slope increases the curvature at both the top and bottom end. If you increase curvature of only one, you make the function first order discontinuous at the knee point.

[haasn]

I created a simulation of the tone mapping code on desmos for those of you who are curious to play around with it:

https://www.desmos.com/calculator/fiydys777e

The parameters are all at the top, SMin/SAvg/SMax and DMin/DMax are PQ luminance levels (not nits!), the defaults are set to 0-1000 nit source range and SDR output (with 1000:1 contrast). KAdaptation is the knee point adaptation strength, KMin and KMax are the knee point clamps, SContrast is the spline contrast and TStrength/TOffset are the slope tuning strength/offsets.

The dotted black line is the 1:1 (neutral) axis, the dotted orange line is the pre-tuning knee point slope, and the dotted red line is the post-tuning knee point slope (the one that is actually used). You can see here quite clearly the effect of raising slope contrast has - since it changes the slope *at* the knee point, it affects the curve both below and above it.

Hopefully this graph should make more intuitive sense than previous algorithm. I'm still looking for ways to improve it.

[mattkhan]

Thanks, that's really useful, will play with it a bit.

Smin/avg/max is driven, in reality, by the measured contents of the current scene?

[mattkhan]

changing s_contrast produces a visually subtle effect in the curve in the pq space and yet my measurements of the actual output showed a v pronounced impact on an obviously sigmoid curve hence it's a bit difficult to relate the sim with reality.

to try to address this, I tried to convert this to nits via the ST2084 eotf thinking it might resemble my measured output but it's not remotely the same so obviously I got that wrong. What transformation is required to then render this in the output space? I guess it could be what i put on the x axis (which is my chart is essentially the input level from 0-100% in 1% steps) but I guess that's what your x axis is also?

I put the corresponding code in a notebook to illustrate -> https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk?usp=sharing

pic attached of my output

[mattkhan]

I redid my previous test with a pattern that has 100 steps from 0 to ~1000nits (the previous one was full range so 10k nits) & then revisited that Spears&Munsil horse pic to check what the debug OSD and can see that it sees that scene as ~850 nits

my analysis for this case shows no real difference in a greyscale curve between the two renderers. I don't know what, if anything, that tells us but thought I'd share it anyway.

[TheShoe]

This is not scientific at all but I have watched probably 10 full length films since build 43 was posted and everything looks amazing.

I am sure there are more improvements to be made but this is really in a good place right now.

+1

Fascinating thread and well beyond my understanding of these things at this point.  I notice a marked improvement with JRVR in recent releases and my family, who generally cares little for the finer details in their video, has pointed out that recently, everything we watch (we use Mediacenter every day, multiple devices/TVs) looks better than it ever has.

The Dune 4K now sits "unused".  no point any longer.

Keep going...

[haasn]

Smin/avg/max is driven, in reality, by the measured contents of the current scene?

Yes, exactly.

changing s_contrast produces a visually subtle effect in the curve in the pq space and yet my measurements of the actual output showed a v pronounced impact on an obviously sigmoid curve hence it's a bit difficult to relate the sim with reality.

Could this sigmoid curve come from your display device calibration, or a difference in the configuration? e.g. if you configure libplacebo to use BT.1886 gamma handling while your display is actually calibrated to gamma 2.2..

to try to address this, I tried to convert this to nits via the ST2084 eotf thinking it might resemble my measured output but it's not remotely the same so obviously I got that wrong. What transformation is required to then render this in the output space? I guess it could be what i put on the x axis (which is my chart is essentially the input level from 0-100% in 1% steps) but I guess that's what your x axis is also?

There should be no further transformation needed, out nits (from the tone-mapper) is out nits (on the display). Well, the gamut mapper may also mess things up further but on a grayscale pattern this shouldn't matter. The only additional source if discrepancy could be if your calibration is not ideal or if JRVR is misconfigured.

I put the corresponding code in a notebook to illustrate -> https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk?usp=sharing

I put also the corresponding PQ transformation into the desmos graph: https://www.desmos.com/calculator/gp1ocbnjgm

[mattkhan]

Could this sigmoid curve come from your display device calibration, or a difference in the configuration? e.g. if you configure libplacebo to use BT.1886 gamma handling while your display is actually calibrated to gamma 2.2..

to the best of my knowledge of how madvr + jrvr work, they are configured in the same way. In this case, for HDR, it's a 2.2 gamma to be sent to the display & it's a dci-p3 d65 gamut.

[mattkhan]

I put also the corresponding PQ transformation into the desmos graph: https://www.desmos.com/calculator/gp1ocbnjgm

thanks so this is the same as what I had in https://colab.research.google.com/drive/1ewuJB0reuRdJ1ziYkmQRsSULwpS7XkCk#scrollTo=t8mO_zGdOWnx&line=6&uniqifier=1

my attempt to measure exactly what the rendering was doing was quite simple

1) generate a greyscale ramp as a series of vertical columns (of a given width in pixels) going from 0-100% in 1% steps where 100% scaled so that 100% is inverse eotf(target max nits). This is written as a 16bit png and then encoded using ffmpeg/x265 with the relevant params to make it hdr.
2) play this in JRVR
3) take a full screen screenshot, save as png
4) use imagemagick to grab a single pixel from each column and output as -format '%[fx:r],%[fx:g],%[fx:b]' (i.e. the rgb values of that pixel in the range 0-1)

it means I have both input and values in the range 0-1 in 0.01 steps which I then want to use to correlate

to turn this into nits...

I'd think the input is just multiply by the peak nits of the scene
for the output, it needs to be scaled to the output peak nits (100 in my case) but what else? presumably there's a transformation based on the specified gamma so should I apply the inverse gamma? if I do that, the shape does look correct but not sure if that is some coincidence

[haasn]

for the output, it needs to be scaled to the output peak nits (100 in my case) but what else? presumably there's a transformation based on the specified gamma so should I apply the inverse gamma? if I do that, the shape does look correct but not sure if that is some coincidence

Yes, exactly. If the output is set to gamma 2.2, then libplacebo applies an inverse gamma 2.2 function before outputting to the display. So to recover raw nits from the output you should apply a gamma 2.2 function to the measured pixel values. (Or set output gamma to linear, if you're capturing in 16-bit precision)

Though I personally think it makes more sense to look at PQ-PQ graphs rather than nits-nits graphs, since the former is effectively perceptually linear, i.e. it maps how we actually perceive the scene. (Or look at the nits-nits graph on a log-log scale)

[mattkhan]

Yes, exactly. If the output is set to gamma 2.2, then libplacebo applies an inverse gamma 2.2 function before outputting to the display. So to recover raw nits from the output you should apply a gamma 2.2 function to the measured pixel values. (Or set output gamma to linear, if you're capturing in 16-bit precision)

Though I personally think it makes more sense to look at PQ-PQ graphs rather than nits-nits graphs, since the former is effectively perceptually linear, i.e. it maps how we actually perceive the scene. (Or look at the nits-nits graph on a log-log scale)

thanks, I think I have a working comparison now

I ran the model for various different peak nits & spline contrast values. It seems to show 2 things:

1) spline contrast has a really minimal impact until you get to really bright scenes which I would think implies it's not really that useful a parameter to be able to tune?
2) there's a blatantly obvious discontinuity (curve abruptly changes direction) at low peak nits (visible at 50, really blatant at 20 and 10)

looking more closely at your desmos sim, I think the upper knee section of the curve is broken for the case where Smax < Dmax

given it's dynamically calculating this curve based on scene brightness, isn't that a potentially significant bug for dark scenes on a projector? wouldn't it significantly elevate the level of slightly brighter parts of a dark scene? and given that loads of movie content is at low ADL then I'd guess that is a material bug? unless there's something else in the actual code which clamps something to avoid this?

[haasn]

looking more closely at your desmos sim, I think the upper knee section of the curve is broken for the case where Smax < Dmax

Note that normally Dmax is clamped to Smax (unless you enabled inverse tone mapping). That said, it definitely seems like we calculate the knee here poorly.

Edit: On second thought, I'm not actually sure if this is unintended. Keep in mind that for inverse tone mapping we want to mostly keep the content the same but strongly boost upper highlights. So an unnatural-looking curve here isn't too far off the mark. You can 'fix' it by raising the knee point adaptation strength.

[mattkhan]

Note that normally Dmax is clamped to Smax (unless you enabled inverse tone mapping). That said, it definitely seems like we calculate the knee here poorly.

Edit: On second thought, I'm not actually sure if this is unintended. Keep in mind that for inverse tone mapping we want to mostly keep the content the same but strongly boost upper highlights. So an unnatural-looking curve here isn't too far off the mark. You can 'fix' it by raising the knee point adaptation strength.

why is it desirable to strongly boost highlights in a dark scene? I appreciate you can't leave it all untouched as then you'll get some discontinuities when the content goes above that limit but wouldn't you want to leave content that fits within some portion of the specified target output level untouched?

or is that what you mean by saying Dmax is clamped to Smax?

what is Smax in practice btw? equivalent of MaxFALL or MaxCLL or something else?

[haasn]

Smax is typically the 99.95% percentile value of PQ(Y). Savg is the mean of PQ(Y).

why is it desirable to strongly boost highlights in a dark scene?

Well, it's the point of having the option, I guess. Inverse tone mapping is off by default, mind. To be honest I never really tested inverse tone mapping all that much as I only have OLED screens that can barely go above normal SDR brightness levels.

[mattkhan]

Smax is typically the 99.95% percentile value of PQ(Y). Savg is the mean of PQ(Y).

the behaviour of this curve is significantly driven by (Smax - Savg) but the JRVR only shows one number so it's really hard to relate what we see in a given scene to what the curve is doing at that point

is that displayed value Smax or Savg?
can the missing numbers be added to the OSD pls?

[mattkhan]

I think Kadaptation is the variable that would be most useful to expose (in JRVR) given it basically controls how much you reduce output at the low end in order to make room for a smoother transition to the upper end.

Clearly it would need testing and I could be a million miles off until I am able to do that but, intuitively, I'm not really too sure why it's a good thing for that value to be much beyond 0 and for Scontrast to be similarly close to 0

Some other observations

* increasing contrast ratio (i.e. reducing Dmin) has the side effect of moving the knee down (in output terms), Kadaptation has to be reduced in order to put that back to the same position (so that's another reason to expose Kadaptation albeit perhaps that offset should be adjusted automatically?)
* as the distance between the black level (Dmin) and the knee level reduces, the impact of Scontrast increases as long as Dmin is above zero
* high Scontrast values can produce a really badly behaved curve if the scene values are sufficiently extreme (high peak, low avg) => I think it's another argument in favour of Scontrast being limited to 1 as opposed to the current 1.5

I wonder whether it's feasible to drive Kadaptation from Smax-Savg? it seems like if Savg were low then you might like a reduced Kadaptation as it implies there are relatively few pixels with highlights so letting them blow out might be visually not so harmful (hence preserving more output for low levels) whereas when Savg is high then you may want Kadaptation to reduce as that means many more pixels are brighter and so giving relatively more space for mid level output would help preserve detail.

[mattkhan]

going back to my greyscale ramp, I guess it's an unusually high ADL scene but perhaps it makes a good example of the curve behaves in this case on a projector

with spline 0.5 + low black floor + 100 target peak nits = spline05_greyscale.png
* pretty much a straight line to the knee then pretty much crush the top end

in this sort of scene, seems like you'd want to push the knee down to a lower level (reduced kmax to 0.5) and bring the knee closer to the no compression curve (reduced kadaptation to 0.3) = spline_adapted_greyscale.png
* arguably gives better progress out of black while giving a bit more chance for highlight detail to be retained

the horse scene from Spears & Munsil is actually even higher ADL than this (~55-60% with average signal level ~75%) so I am inclined to think the behaviour of the current spline curve does explain the perception of crushed highlight detail

I think it comes back to the idea that you need vary those, currently static, variables based on the scene content and then work out how to smoothly transition between them on scene cuts to avoid artifacts.

[haasn]

Intuitively, it seems that for well-behaved input scenes (Savg <= Kmax*Dmax) we want to make Dknee=Sknee=Savg with M=1, while for sufficiently bright input scenes (Savg >= Kmax*Dmax) we want to cap Dknee at Kmax*Dmax. And combine this with a sufficiently low value of Kmax. This would allow well-behaved input scenes to mostly pass untouched while scenes that are unreasonably bright get their brightness dropped. However, I am a bit worried about making a hard `max()` here, so maybe a powermean with sufficiently high power would be better.

I'll try implementing something like this and see what happens, maybe.