[INFO] Another Tonemapping Discussion. (FFmpeg)

[DevSker]

"Converting primaries to bt709 before tonemapping is incompatible with a tonemap desaturation value of other than 0, it clips pixels to black that have colors outside the bt709 colorspace." I've tested that statement and could reproduce the problem.
Also, is it possible to change the "npl" value? Seems like it's 100, but using higher values can give you better results.

About the black pixels:
Using "zscale=t=linear:npl=100,format=gbrpf32le,zscale=p=bt709,tonemap=tonemap=mobius:desat=1,zscale=t=bt709:m=bt709:r=tv,format=yuv420p"
Instead of something like "zscale=t=linear:npl=100,format=gbrpf32le,tonemap=tonemap=mobius:desat=1,zscale=p=bt709:t=bt709:m=bt709:r=tv,format=yuv420p"
Had this issue:

(https://cdn.discordapp.com/attachments/4...desat1.mp4)

About npl:
As you can see on the samples below, npl=100 is just too bright and can make some details almost disappear. Parameters used: ffmpeg -i HDRSample.webm -vf zscale=t=linear:npl=(>=100),format=gbrpf32le,tonemap=tonemap=mobius:desat=0,zscale=p=bt709:t=bt709:m=bt709:r=tv,format=yuv420p -c:v libx264 -preset veryslow -crf 18 output.mp4

npl=100 -> https://cdn.discordapp.com/attachments/4...desat0.mp4
npl=200 -> https://cdn.discordapp.com/attachments/9...desat0.mp4
npl=500 -> https://cdn.discordapp.com/attachments/4...desat0.mp4
npl=1000 -> https://cdn.discordapp.com/attachments/4...desat0.mp4

Sample -> https://cdn.discordapp.com/attachments/9...ample.webm

[Selur]

Hybrid will only add a conversion to bt709 if the user told it to.
If ffmpeg has a bug which causes it to have problems with this you need to report this to the ffmpeg developers not me.
Also it makes no sense to apply tone mapping on bt709 content. It's meant for HDR to SDR conversion,..
-> nothing I can do about that.

Regarding npl: will look at it after work, should be no big problem of adding it as an additional parameter.

Cu Selur

[DevSker]

I think you misunderstood me. The sample is HDR BT.2020, I've tonemaped it to SDR BT.709, but using zscale=p=bt709 before tonemap=tonemap=mobius caused such issue when using desaturation.
I have just tested it with Hybrid and the result was identical. Black pixels being clipped.

[Selur]

but using zscale=p=bt709 before tonemap=tonemap=mobius caused such issue.

Yes, but doing that makes no sense at all.
Tonemapping is not meant to be applied on bt709 content, it seems to me it's something like applying deinterlacing filters on progressive content and complaining that the quality got worse.
It's something that may make sense in some specific cases, but if you blindly do stuff you can have issues.

Cu Selur

[DevSker]

but using zscale=p=bt709 before tonemap=tonemap=mobius caused such issue.

Yes, but doing that makes no sense at all.
Tonemapping is not meant to be applied on bt709 content, it seems to me it's something like applying deinterlacing filters on progressive content and complaining that the quality got worse.
It's something that may make sense in some specific cases, but if you blindly do stuff you can have issues.

Cu Selur

But that's exactly the issue, Hybrid is using the FFmpeg parameters like that:
[...]zscale=p=bt709,tonemap=tonemap=mobius:desat=1,zscale=t=bt709:m=bt709:r=tv[...]
Instead of [...]tonemap=tonemap=mobius:desat=1,zscale=p=bt709:t=bt709:m=bt709:r=tv[...]

[Selur]

Will look at it after work.

[Selur]

Okay, Hybrid atm. uses:

zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv,zscale=t=linear:npl=<NPL>,format=gbrpf32le,zscale=p=<FORMAT>,tonemap=<METHOD>:desat=<DESAT>:peak=<PEAK>,zscale=t=<FORMAT>:r=<RANGE>

and it should be:

zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv,zscale=t=linear:npl=<NPL>,format=gbrpf32le,tonemap=<METHOD>:desat=<DESAT>:peak=<PEAK>,zscale=p=<FORMAT>:t=<FORMAT>:r=<RANGE>

correct?

Cu Selur

Ps.: send you a link to a new dev version

[DevSker]

Hello,
Yes, that's correct, thank you.