Print

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

[haasn]

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

Playing around with the above idea made me settle on something like this, the basic idea is to try and always present a sigmoid-like shape with contrast close to 1, but to slowly approximate a pqlinear function as the knee point moves outside the 'valid' knee point range. (The spline contrast parameter can still be used to control how strongly we should adapt the slope towards the linear slope)

I'll try implementing it in libplacebo next and throw it at some scenes.

[haasn]

Well, theory is theory and practice is practice. I don't like it - the attempt to make it try and preserve brightness even for seemingly well-behaved scenes basically always backfires - it blows out scenes that we handled much better before.

I think it's better to always adapt the brightness range, and maybe just change the way we tune the slope.

[mattkhan]

Well, theory is theory and practice is practice. I don't like it - the attempt to make it try and preserve brightness even for seemingly well-behaved scenes basically always backfires - it blows out scenes that we handled much better before.

I think it's better to always adapt the brightness range, and maybe just change the way we tune the slope.

what are the capabilities of the display you are testing on? it would be interesting to know that to be able to try to guess what you're seeing from the curve alone.

for example, if I use my display capabilities and compare your nu curve vs existing then I'd guess the new one would be darker overall but you might get increased contrast in bright areas. Might be interesting to see a pic comparing a scene or two run through each.

do you have a standard set of scenes you use as a test pack?

[mattkhan]

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?

@haasn hendrik mentions this comes from libplacebo, can you add this pls?

[haasn]

what are the capabilities of the display you are testing on? it would be interesting to know that to be able to try to guess what you're seeing from the curve alone.

for example, if I use my display capabilities and compare your nu curve vs existing then I'd guess the new one would be darker overall but you might get increased contrast in bright areas. Might be interesting to see a pic comparing a scene or two run through each.

I'm just testing the out-of-the-box default tone-mapping to 1000:1 SDR display.

do you have a standard set of scenes you use as a test pack?

Yeah, I'll try and publish it online actually as I'm finding it hard to synchronize across machines.

Anyway, I gave the dynamic adaptation strength a few more thoughts and came up with something like this: https://www.desmos.com/calculator/tyv2elsdao
After implementing it, it does significantly improve visual appearance in my books. (See attached before/after images)

[haasn]

I tuned it a bit more and pushed my changes here: https://code.videolan.org/videolan/libplacebo/-/merge_requests/551
This significantly improves a number of problematic scenes in S&M, and also increases consistency between different versions of it (1k nits and 10k nits)

On a side note, I noticed that for some reason, the S&M 4000 nits sample seems to be mastered very differently from the 1k and 10k nits samples. The snow horses scene, for example, is a lot brighter - brighter even than the 10k nits sample. This seems to be present in the source, not introduced by tone-mapping, since it's visible even when doing a linear pq stretch.

[FenceMan]

This looks like another pretty significant improvement, can't wait to see the end result.  Based on that comparison it looks really good.

[haasn]

do you have a standard set of scenes you use as a test pack?

Pushed my test pack to https://github.com/haasn/hdr-tests

[haasn]

@haasn hendrik mentions this comes from libplacebo, can you add this pls?

Sure. Pushed to https://code.videolan.org/videolan/libplacebo/-/merge_requests/553

[haasn]

New spline tone mapping (right) even seems to outperform HDR10+ OOTF (ST2094-40, left) on some scenes, but worse on others..

[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)

going back to this problem, I still can't get the measured output to look much like the tone mapping function

to recap my process

* create a png encoding in 1% steps from 0-100% where 100% is rescaled based on the max nits (so multiply by ~0.7518 for 1000 nits)
* encode that as an mkv using ffmpeg / x265
* play the mkv in JRVR
* take a screenshot, save to png
* extract the rgb value of each column in the png (using imagemagick output as a %age)
* calculate the luminence of that, apply the appropriate gamma function, convert to nits based on my specified max output (100 nits) then convert that to pq
* plot this vs the theoretical pq input values (aka 0 to ~0.7518 in equal steps)

I removed my 3dlut to take that out of the equation and plotted it against the reference as per your desmos link, it gives me the attached (ref is the tone mapping curve, none is my measured output)

I think my parsing of my png is accurate as I don't see that flat top (clipping) in it which you'd expect if the tone mapping curve were applied

I think it means either the measured average is not what I expect or I'm missing something else

in this case, it says it's tonemapping 1020->100 which must be the peak, it's a even grey scale should average should be 510? measured behaviour is more like the curve you get from an average ~120 (not exactly the same but pretty close)

[haasn]

Can you post your file?

[mattkhan]

Can you post your file?

which one?

speaking of missing something made me remember you posted this previously

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

so actually the mean is invariably going to be invariably really low isn't it?

for example, the mean of a 0-1000 nits pattern should be 500 nits but converted to PQ and back again, it's ~24.8 nits

i.e.

Code: [Select]

eotf_ST2084(eotf_inverse_ST2084(1000) / 2)
(I use https://colour.readthedocs.io/en/develop/generated/colour.eotf.html for the conversions)

and actually this does have much the same shape with my measurement (not a perfect fit but the slopes are v similar)

[Hendrik]

It sounds like you are thinking of the median, not the mean. The mean would be higher, because on a linear brightness plot of 0-1000 nits, the vast majority of the area has high PQ values.

eg.

Code: [Select]

import colour

accum = 0
for nit in range(1,1000):
    accum += colour.models.eotf_inverse_ST2084(nit)

print(colour.models.eotf_ST2084(accum / 1000))
==> 375.1

Its not quite 500, but far from 24.8

I'll be adding the output from the peak detect to the OSD in a future update, need to roll new libplacebo binaries again.

[mattkhan]

that is where I started from, i.e.

compute the ADL of the scene
observe that the resulting tone mapping curve behaves much like clipping
assume that might be the reason for apparent clipping in bright scene (S&M horse)
try to measure that directly using a gamma ramp

and that's the point at which measured reality does not appear to match expectation as I don't see or measure a curve that looks like that

so then next steps where

and the only reason I have thought of that is because it appears to fit what I measure, i.e.

find the value for Savg that produces the actual shape
look for a rationale for libplacebo using that value

and that bought me to a linear PQ ramp

Code: [Select]

z = eotf_inverse_ST2084(1000)
v = np.arange(0, z+0.0001, z / 100)
v_avg = np.mean(v)
f'mean: {v_avg:.6g} nits: {eotf_ST2084(v_avg):.3g}'

==> mean: 0.375914 nits: 24.8

which is what you get if you were to measure the input pixel values themselves, take the mean of those and then convert the resulting value to PQ

[mattkhan]

you may recall that, for a 1000nits peak, I found madvr and jrvr to measure v similarly so I added the ShowHdrMode folder to madvr to get more OSD info and that prints the frame FALL for us

madvr computes it as 50.252 nits with a fall stdev of 31.98

50 is actually a closer match at the top end vs my previous eyeballed value of 25

[mattkhan]

decided to look at libplacebo code for this and I think it measures luminance via this shader

Code: [Select]

    // Measure luminance as N-bit PQ
    GLSL("float luma = dot("$", color.rgb);             \n"
         "luma *= %f;                                   \n"
         "luma = pow(clamp(luma, 0.0, 1.0), %f);        \n"
         "luma = (%f + %f * luma) / (1.0 + %f * luma);  \n"
         "luma = pow(luma, %f);                         \n"
         "uint y_pq = uint(%d.0 * luma);                \n",
         sh_luma_coeffs(sh, &csp.hdr.prim),
         PL_COLOR_SDR_WHITE / 10000.0,
         PQ_M1, PQ_C1, PQ_C2, PQ_C3, PQ_M2,
         PQ_MAX);

I found a few sources online for a pq2linear function (referenced via some madvr thread on avs & github) - https://github.com/HDRWCG/HDRStaticMetadata/blob/master/hdrgenerator.cpp#L56 - which calculates the luminance of a pixel and then raises to the power of 1.0/78.84375 , can't find any explanation of where that value comes from though.

[Hendrik]

You can lookup the official PQ formula in the BT.2100 spec, which is where these magic numbers are documented: (well, not quite their origin, but at least their authority)
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf (Table 4)

The peak detect shader implements the inverse PQ EOTF, eg. linear light to PQ, the code you linked does PQ to linear light.
The image gets decoded from PQ to linear light before any further processing is done on it, so these shaders don't run on a PQ input.

[mattkhan]

Ah somehow I missed that m2 was 78.84375

Moderately sure my code is doing the same operations then, will add a fall calc to check what comes out

[haasn]

decided to look at libplacebo code for this and I think it measures luminance via this shader

Code: [Select]

    // Measure luminance as N-bit PQ
    GLSL("float luma = dot("$", color.rgb);             \n"
         "luma *= %f;                                   \n"
         "luma = pow(clamp(luma, 0.0, 1.0), %f);        \n"
         "luma = (%f + %f * luma) / (1.0 + %f * luma);  \n"
         "luma = pow(luma, %f);                         \n"
         "uint y_pq = uint(%d.0 * luma);                \n",
         sh_luma_coeffs(sh, &csp.hdr.prim),
         PL_COLOR_SDR_WHITE / 10000.0,
         PQ_M1, PQ_C1, PQ_C2, PQ_C3, PQ_M2,
         PQ_MAX);

I found a few sources online for a pq2linear function (referenced via some madvr thread on avs & github) - https://github.com/HDRWCG/HDRStaticMetadata/blob/master/hdrgenerator.cpp#L56 - which calculates the luminance of a pixel and then raises to the power of 1.0/78.84375 , can't find any explanation of where that value comes from though.

Looking at this code again makes me suddenly question whether the luma coefficients we use are wrong. Shouldn't we use the encoding space coefficients, rather than the mastering display coefficients? I think this is a bug, and may result in slightly wrong values of calculated luminance.

[haasn]

Looking at this code again makes me suddenly question whether the luma coefficients we use are wrong. Shouldn't we use the encoding space coefficients, rather than the mastering display coefficients? I think this is a bug, and may result in slightly wrong values of calculated luminance.

Yeah, I'm pretty sure it was a bug. Fortunately, the fixed values are barely different in most scenes.

[haasn]

which one?

This one:

* create a png encoding in 1% steps from 0-100% where 100% is rescaled based on the max nits (so multiply by ~0.7518 for 1000 nits)
* encode that as an mkv using ffmpeg / x265
* play the mkv in JRVR

[mattkhan]

This one:

generated using https://github.com/3ll3d00d/jrmc-utils/blob/master/greyscale/greyscale.py

encoded using ffmpeg as per the params listed here https://github.com/3ll3d00d/jrmc-utils/blob/4ecbf85003e4c20161299c10ed98f2118d148234/greyscale/greyscale.py#L68

[mattkhan]

based on those links, it seems the MaxFALL of my greyscale ramp is ~144

given each column is a solid block then it is equivalent to a single row containing 1 pixel of each level

Code: [Select]

np.mean(eotf_ST2084(np.arange(0, n1000 + n1000 / 100, n1000 / 100)))
==> 144.22975018386427

the tone mapping curve definitely does not match my measurements when Savg = 144 though (the slope at the top end has already started to flatten)

[mattkhan]

so actually the mean is invariably going to be invariably really low isn't it?

for example, the mean of a 0-1000 nits pattern should be 500 nits but converted to PQ and back again, it's ~24.8 nits

i.e.

Code: [Select]

eotf_ST2084(eotf_inverse_ST2084(1000) / 2)
(I use https://colour.readthedocs.io/en/develop/generated/colour.eotf.html for the conversions)

and actually this does have much the same shape with my measurement (not a perfect fit but the slopes are v similar)

I built plplay and ran it on that file, libplacebo does indeed produce a number that looks much like the calculation I performed above (see attached).

it seems unusual to me at least (doesn't mean it's bad/wrong of course), well below that produced by either a FALL calc or an ADL like calculation for this pattern. I will have to try some different scenes to see if that is representative.

[mattkhan]

wrote a little script to calculate fall/max in a few different ways

https://github.com/3ll3d00d/jrmc-utils/blob/master/maxfall/calc.ipynb

APL seems correct
FALL I'm less certain of how to turn into nits, e.g. if I know it says it's a maxcll=1000 file then how to account for that given a screenshot is going to contain full range (0-255) rgb values?

Generally can't reproduce the libplacebo avg at all but can see, from plplay, it's consistently below anything that seems to be generally used (APL or FALL based calcs) or seen in madvr. 

One question, I think black bars are included in the calculation. Are bars removed before it reaches the renderer (i.e. the cropped image is sent for rendering) or after? it seems relevant as that means the detected avg/peak will change and hence the tone mapping curve applied will also change.

[haasn]

Your plplay screenshot shows 37.83% APL, 25.51 nits. Your ipynb calculates 37.558% APL, 24.7286 nits. Isn't that basically a near-exact match?

One thing to consider is that plplay, at least as of current git master, will exclude solid black pixels from consideration. This avoids black bars messing things up too much (though pixels that are not perfectly 0 will still be counted, e.g. odd pixels with a value of 1 or 2, in practice this accounts for maybe a few percent of a typical black bar). It also means that in your grayscale ramp, the '0' column is not included in the max.

Indeed, if you bias the measured value up by a factor of 100/99 you get pq_eotf(n1000 / 2 * 100/99) = 25.906252786101845 nits, almost exactly what libplacebo measures. (The discrepancy can be explained by encoding noise)

[mattkhan]

Your plplay screenshot shows 37.83% APL, 25.51 nits. Your ipynb calculates 37.558% APL, 24.7286 nits. Isn't that basically a near-exact match?

it's a close match for the greyscale ramp yes

I can't get what seems a good match for real content though, I can add a filter to remove the bottom end to see if it improves that

ultimately if your curve is tuned to your numbers then i doubt it really matters what the absolute numbers are, it just means that the curve shape is different to what was expected when I started delving into this. Nevertheless I think it should be possible to independently verify this and it's mildly frustrating that I'm unable to do so hence why I keep scratching away at that itch

[haasn]

Something else to keep in mind for the peak estimation is that our "99.995%" is only an approximation value. We group the histogram into a small (64) number of buckets. So likely, all of the values from the top 99% and upwards fall into the same bucket - we don't have the histogram resolution to discriminate between them exactly. So we estimate, by assuming those values are evenly spread inside that bucket and then chopping off where the 99.995% percentile value would be under that assumption.

Also, it's very possible that the peak detection value is off by a small margin of error because of oversampling at the edge of the video. Peak detection runs on a 16x16 block size so we need to pad the image to be a multiple of 16x16. As far as I can tell, this is currently done by hard-clamping to the video, resulting in the same row of pixels basically getting duplicated. There might be a way for me to fix this, but I'm not sure. (Maybe we should at least switch to using mirroring instead of clamping, to avoid a single bright highlight becoming disproportionately dominant?)

P.s., made some more improvements to peak detection, in particular with regards to scene changes: https://code.videolan.org/videolan/libplacebo/-/merge_requests/559

[mattkhan]

am I right in thinking your Savg is calculated via the same 64 bin histogram based mechanism?
how do you pick the bin edges in this case? is it a linear stride from min to max?

one problem with reproducing this is knowing how to correctly scale RGB values of  screenshot back into PQ (i.e. if I take a screenshot then max value is always 255 which then implies 10k nits but what's the correct max value in this case? rescale down to the stated MaxCLL or leave it as is?). How does this actually work in the real content stream? e.g. if maxcll is 1000 then the decoded values can still imply a 10000 peak? i.e. if it actually keeps to 1000 then the peak value is ~0.75 (relatively speaking)?

regardless, I applied this technique and see v minor differences on the 99.95% value, slightly bigger but still relatively small differences on the avg value (vs an accurate percentile/mean) but these values are still way off what plplay reports (albeit see above point about how to scale a png of a tonemapped image to get back to a sane pq value, perhaps that's an intractable problem with a hdr rendering? )

[Hendrik]

The Average PQ brightness is calculated with a straight forward artihmetic mean (add them all up, divide by count), the histogram bins are not used here. Although it does use the same 16x16 blocks the compute shader runs on.

PQ is an absolute scale, it always goes from 0 to 10000, metadata is just a hint to help the software/screen, it does not impact the coding of the values. So any given PQ value is always the same brightness. So yes, a 1000 nits image would have a peak of ~0.75 in PQ, and you can certainly have pixel that exceed MaxCLL.

[haasn]

Incidentally, I noticed some other inconsistencies in the peak detection the other day, where a static frame was showing changing peak detect values over time (which should be impossible). I was planning to look into some potential bugs here.

[mattkhan]

Also, it's very possible that the peak detection value is off by a small margin of error because of oversampling at the edge of the video. Peak detection runs on a 16x16 block size so we need to pad the image to be a multiple of 16x16.

how do you analyse a 16x16 block? is it the average luminance of the pixels within the block?

for example, if I look at your orientexpress.hevc file, there are 2 {255,255,255} pixels (see attached for location). Your peak detect definitely doesn't see these so I would think that means they are either not in the source (see my last comment about how to get a passthrough) or averaged away by the use of a 16x16 block.

As far as I can tell, this is currently done by hard-clamping to the video, resulting in the same row of pixels basically getting duplicated. There might be a way for me to fix this, but I'm not sure. (Maybe we should at least switch to using mirroring instead of clamping, to avoid a single bright highlight becoming disproportionately dominant?)

given we're talking about a few pixels at the border (and for standard resolutions, I think it means we're talking about the top/bottom only), would cropping make more sense?

PQ is an absolute scale, it always goes from 0 to 10000, metadata is just a hint to help the software/screen, it does not impact the coding of the values. So any given PQ value is always the same brightness. So yes, a 1000 nits image would have a peak of ~0.75 in PQ, and you can certainly have pixel that exceed MaxCLL.

if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?

[Hendrik]

if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?

You also want to output in PQ - without windows knowing its PQ and converting to SDR for you. Assuming you want to screenshot it for analysis. Or maybe using ffmpeg with vf_libplacebo might be the way to go here to make straight up images in the specification you want.
Any SDR output will clip the content thats above the SDR brightness (unless tone mapping has reduced it below already). I suppose you could set the SDR brightness at 10000 nits, but the gamma encoding is terrible for such a huge brightness range and you would lose a lot of detail.

[mattkhan]

You also want to output in PQ - without windows knowing its PQ and converting to SDR for you.

thanks, I hadn't thought of that. It removes that scaling problem completely & using vf_libplacebo would also make a lot of sense as it get a bit tedious pulling out screenshots manually

[mattkhan]

so I wonder what turns those pixels in my previous pic into 100% white? in PQ, those same pixels are ~60% grey which is similar to neighbouring pixels but when rendered to either bt2020 or 709, just those 2 pixels turn in 100%

[haasn]

Incidentally, I noticed some other inconsistencies in the peak detection the other day, where a static frame was showing changing peak detect values over time (which should be impossible). I was planning to look into some potential bugs here.

Okay, I figured out what was causing this - debanding being enabled. If I disable debanding, I always measure the exact values. But with debanding adding some amounts of noise and grain, the values fluctuate from frame to frame. This is expected, I guess, so no cause for alarm here.

[haasn]

So, here is the result of my experimentation on orientexpress.hevc. In all cases, I am testing with plplay defaults and HDR peak detection enabled. I kept the peak percentile at 100.0%, to make sure we get only exact (not approximated) values.

Measured values:
- Max: 291.00 cd/mē (61.86% PQ)
- Avg: 4.34 cd/mē (23.80% PQ)
- (99.995% estimate: 263.55 cd/mē (60.81% PQ))

I then took the image and passed it through a grayscale operator using ImageMagick for analysis. For lack of anything better, I used the Rec709Luminance option, even though this is not entirely accurate (wrong gamma, wrong matrix coefficients on the BT.2020 image). So it should be taken only with a grain of salt. They are also only accurate to 8 bits (I disabled dithering to get consistent values), so there is about ~10 nits of rounding error towards the top end. Regardless, here are the measured values:

BT.2020 PQ input file:
  Channel statistics:
    Pixels: 2674210
    Gray:
      min: 11  (0.0431373)
      max: 158 (0.619608)
      mean: 60.9368 (0.238968)
      median: 45 (0.176471)
      standard deviation: 39.9296 (0.156587)
      kurtosis: -0.991433
      skewness: 0.709792
      entropy: 0.93231

So the true maximum as measured by this method is 61.96% PQ. Slightly higher than what libplacebo was measuring, but given the inaccuracies inherent in the IM method, alongside the 8 bit rounding, the libplacebo result is more likely to be accurate. The mean as estimated by this process is 23.89% PQ, again matching (if slightly too high) what libplacebo measures.

Gamut mapped BT.709, output in PQ:
  Channel statistics:
    Pixels: 2674210
    Gray:
      min: 10  (0.0392157)
      max: 158 (0.619608)
      mean: 60.8102 (0.238471)
      median: 45 (0.176471)
      standard deviation: 39.9282 (0.156581)
      kurtosis: -0.986014
      skewness: 0.71678
      entropy: 0.930441

After gamut mapping from BT.2020 to BT.709 we see that the max is still 61.96% and the mean is 23.84%. This is now a bit closer to the libplacebo measured values, probably because now we're using the correct matrix coefficients for the grayscale operator (BT.709) - even if the gamma is still wrong.

Tone mapped to SDR BT.2020, output in PQ:
  Channel statistics:
    Pixels: 2674210
    Gray:
      min: 10  (0.0392157)
      max: 148 (0.580392)
      mean: 58.6171 (0.229871)
      median: 44 (0.172549)
      standard deviation: 38.0244 (0.149115)
      kurtosis: -1.04137
      skewness: 0.679
      entropy: 0.933258

The max has been reduced to 58.0392% PQ, or about 202.42 nits. This tracks well onto the 203 nits target. The new frame average brightness is 22.9871%, or 3.85 nits (down from 4.34 nits). This steps seems to be working as intended.

Gamut mapped SDR BT.709, output in PQ:
  Channel statistics:
    Pixels: 2674210
    Gray:
      min: 10  (0.0392157)
      max: 146 (0.572549)
      mean: 58.5102 (0.229452)
      median: 44 (0.172549)
      standard deviation: 38.0216 (0.149104)
      kurtosis: -1.03707
      skewness: 0.684922
      entropy: 0.935584

After gamut mapping to BT.709 it appears the maximum has dropped down to 57.25% PQ, or 187.76 nits. This is substantially lower than 203 nits, but was evidently introduced as part of the headroom needed for perceptual gamut mapping. (In terms of 8 bit PQ values it is only lower by 2, so it's probably also distorted by rounding error) The frame average remains almost unchanged at around 22.94% PQ, or 3.83 nits.

Final SDR output:
  Channel statistics:
    Pixels: 2674210
    Gray:
      min: 4  (0.0156863)
      max: 248 (0.972549)
      mean: 59.4856 (0.233277)
      median: 28 (0.109804)
      standard deviation: 60.3931 (0.236836)
      kurtosis: -0.468588
      skewness: 1.03268
      entropy: 0.868375

And in full color RGB:

  Channel statistics:
    Pixels: 2674210
    Red:
      min: 6  (0.0235294)
      max: 255 (1)
      mean: 67.0188 (0.262819)
      median: 37 (0.145098)
      standard deviation: 59.135 (0.231902)
      kurtosis: -0.525254
      skewness: 0.924761
      entropy: 0.884698
    Green:
      min: 3  (0.0117647)
      max: 255 (1)
      mean: 56.4452 (0.221354)
      median: 22 (0.0862745)
      standard deviation: 61.4242 (0.240879)
      kurtosis: -0.463476
      skewness: 1.0606
      entropy: 0.849128
    Blue:
      min: 0  (0)
      max: 240 (0.941176)
      mean: 55.7532 (0.21864)
      median: 21 (0.0823529)
      standard deviation: 62.118 (0.2436)
      kurtosis: -0.118993
      skewness: 1.2104
      entropy: 0.819895
  Image statistics:
    Overall:
      min: 0  (0)
      max: 255 (1)
      mean: 59.739 (0.234271)
      median: 26.6667 (0.104575)
      standard deviation: 60.8924 (0.238794)
      kurtosis: -0.404202
      skewness: 1.05152
      entropy: 0.85124

So the final SDR output perfectly spans the pixel range 0-255, with the average pixel being 59.739 (or about 23.42% of the available value range, which is exactly what we'd expect given the input scene distribution).

[haasn]

how do you analyse a 16x16 block? is it the average luminance of the pixels within the block?

for example, if I look at your orientexpress.hevc file, there are 2 {255,255,255} pixels (see attached for location). Your peak detect definitely doesn't see these so I would think that means they are either not in the source (see my last comment about how to get a passthrough) or averaged away by the use of a 16x16 block.
given we're talking about a few pixels at the border (and for standard resolutions, I think it means we're talking about the top/bottom only), would cropping make more sense?
if I take a UHD source, disable tonemapping and make it output as BT2020, is this equivalent to a passthrough of the source content?

I cannot reproduce this with my methodology, and I see no (255,255,255) pixels anywhere either in the source nor in the tone-mapped result. As for your question, we measure maximum and average separately:

PQ_Y = Input luminance in 14-bit PQ
Block_Avg := Sum(PQ_Y) / Block_Size
Block_Max := Max(PQ_Y)

Global_Avg := Sum(Block_Avg) / Num_Blocks
Global_Max = Max(Block_Max)

[mattkhan]

All I did was play it with plplay with default settings and then took a screen capture of the active window, results in 2 white pixels here.

[Hendrik]

The changes to libplacebo talked about here over the last page and a half will be available to JRVR in 31.0.60. And the average and peak brightness levels will now be shown on the OSD.

[mattkhan]

sounds good, any plans to expose further tunable parameters to influence the tone mapping?

[Hendrik]

There will be an advanced option to let you tweak every libplacebo option by referring to it by name (not in yet, need to restructure how we set all the libplacebo settings). If one option proves to be particularly meaningful, it might get a UI option later.

[mattkhan]

Great, will test later on

[Hendrik]

Build 61 should have the advanced options interface, which is essentially just a textbox on our end.
Multiple options are delimited with commas, (semi)colons or whitespace.

There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/

You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants

These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.

[FenceMan]

Build 61 should have the advanced options interface, which is essentially just a textbox on our end.

There is a documentation page for libplacebo here which documents these:
https://libplacebo.org/options/

You are likely going to be interested in Tone-mapping constants:
https://libplacebo.org/options/#tone-mapping-constants

These settings are applied after all ours, so it should allow overriding almost everything, with only a few tiny exceptions that are re-set based on each input frame.

How does the new Hermite downscaling option compare to using SSIM external shader?

[Hendrik]

Hermite is a high-performance option with decent quality, its not a top quality option, but it's fast, and better then bilinear in quality.

But this is not a tone mapping question, please use the other thread for generic inquiries.

[Drybonz]

Most everything in this thread is beyond my pay grade... but I do have a problem that if I activate the HDR and HDR tone mapping options for many of my 4k videos they basically go black... too dark to watch.  I've tried adjusting the Windows HDR calibration and playing with settings in JRVR.

My question is... for those of us that don't really follow what's going on in this thread, where should we be setting our HDR options to avoid this ultra dark?  Thanks, in advance, for your help.

[mattkhan]

I think there is a bug in here as there is some extremely obvious/distracting brightness flickering in at least one scene from the S&M disk (the one shown in the attached pic)

as it rotates, the petals visibly flickering in brightness

[mattkhan]

see attached

NB: this is a video using simplescreenrecorder of my windows HTPC playing this back viewed via KRDC so no clue what that does to the colours, I'm just trying to demonstrate the flickering here