Can just leave it on histogram and not worry about it - they are just different approaches to work out what the max “brightness” would be for the frame to set in the DV side.
Here is my basic understanding:
MaxSCL is the maximum brightness of the scene/frame, similar to MaxCLL for the entire video content.
The histogram is “binning” the distribution of the brightness for the scene/frame, so the tone-mapping distribution.
@quitevoid would know the specific details behind each one and why they exist, I just ported them over.
When @doppingkoala is happy with a new approach can add that also, and then have more choice lol
It also says the values should be 0.00000 and 0.00255 respectively, which isn’t the case from the data I have seen.
Do you know what the values are actually are present in the data represent? As the numerical values clearly do not match 5% and 10% values for the CDF.
It’s fine to use the max in the histogram.
5% and 10% are actually DistributionY99 and DistributionY100nit, respectively.
DistributionY99 is essentially 99.99% percentile, so it’s an extra data point higher than 99.98% (histogram99).
The DistributionY99 value is the maximum value of 99YF values with in a scene. The 99YF value is derived
as a value below which 99.99% of the linearized luminance values for each frame fall.
DistributionY100nit:
The DistributionY100nit value is an average value of DPY100F values with in a scene. DPY100F SHALL be
derived as a percentage, between 0 and 100, of accumulated number of pixels below and equal to
100nits in luminance for each frame.
I guess DistributionY100nit should actually be ignored.
I’m not sure that’s typical data. The samples I have always have higher 99.99, as expected.
With histogram max you’d still end up using the 99.98% value here.
Odd. Over all the frames on the 10 movies provided earlier in this thread, I am only seeing the value higher for about 25% of the frames. There are even a small number of frames where the values is even below the 95% value.
I’m also seeing data where the distribution values are
0, 1508, 100, 0, 0, 0, 0, 74, 1574
Doesn’t this make conflicting information - or am I interpreting this incorrectly? i.e., isn’t this saying both that 100% of the pixels are below 100nits and also saying that the 99.98 percentile is at 157.4 nits?
Tnx, will not change it then.
Recently I got one HDR10+ movie and played it yesterday and I think that when using “Dynamic HDR10+ to DV Profile 8.1 conversion” (the only way to display it on LG Oled) I noticed that it also slightly changes subtitle brightness from scene to scene, or am I imagining it?
Nothing that needs any attention, just mentioning it…
It is a general DV tv-led issue not specific to this conversion case, with tv-led the display is sent the whole image including at that point the subtitles baked into the image, it then tone maps the whole image including those baked in subtitles.
This on-the-whole went unnoticed when the UI (and hence subtitle) brightness was at 100%, and started to be noticeable when bringing down the UI brightness (GUI luminance), which when further being tone mapped at the TV side can become quite dull and the variability is more noticeable in this lower brightness range.
Here is more discussion I had on that earlier if interested:
It was on my list of enhancements when I had the ambitious goal that could make this the best DV device for tv-led.
Would have gone something like.
First step put the GUI luminance control under keyboard / remote control - so could adjust to find a sensible balance on the fly.(you can bring up the UI now when playing and adjust on the fly so quite doable just need to marry that control with keyboard I guess)
Extract a brightness level from the RPU and apply that in-reverse to the GUI luminance control to reverse some of the effect of the tone-mapping (maybe need some manual adjustment to dial in per display) - Say some of the effect as likely still want the subtitles to tone down in dark scenes - but not to the extent it is distracting.
Change is in the calculation of the avg_pq. Essentially convert the different values of the CDF from nits to PQ, and then approximate average pq from those converted points. Improves over the original method as, due to the nonlinearity of the nits to pq calculation, the average nits converted to pq does not equal the average pq.
I’ll have a look into it but it shouldn’t be hardcoded like this.
Checking for 5/10% isn’t reliable since they’re always there, maybe it could be done by checking 5% is higher than 99% and 10% <= 100.
lol