Tone-mapping in transcoding HDR for playback on SDR screens??

[sooty234 266]

It's being requested for the shield, too.

https://www.nvidia.com/en-us/geforce/forums/shield-tv/9/352176/dynamical-tone-mapping-of-bt2390-with-hermite-curv/

[vdatanet 1496]

13 minutes ago, sooty234 said:

Yeah, Reinhard is the simplest solution, but BT.2390 is the best, and is now industry standard.

 

The tonemap_opencl filter has some algorithms available:

Quote

tonemap

Set the tone map algorithm to use.

Possible values are:

none

Do not apply any tone map, only desaturate overbright pixels.

clip

Hard-clip any out-of-range values. Use it for perfect color accuracy for in-range values, while distorting out-of-range values.

linear

Stretch the entire reference gamut to a linear multiple of the display.

gamma

Fit a logarithmic transfer between the tone curves.

reinhard

Preserve overall image brightness with a simple curve, using nonlinear contrast, which results in flattening details and degrading color accuracy.

hable

Preserve both dark and bright details better than reinhard, at the cost of slightly darkening everything. Use it when detail preservation is more important than color and brightness accuracy.

mobius

Smoothly map out-of-range values, while retaining contrast and colors for in-range material as much as possible. Use it when color accuracy is more important than detail preservation.

Default is none.

 

 

[sooty234 266]

3 minutes ago, vdatanet said:

The tonemap_opencl filter has some algorithms available:

 

 

Yeah, they are just the standard stuff that ffmpeg has. I might have used mobius though, but reinhard is safe.

http://ffmpeg.org/ffmpeg-all.html#tonemap

[sooty234 266]

Here you can see the difference between reinhard and bt.2390

reinhard

 

bt.2390

 

You can see that the white point is higher, retaining more luminance. Also retaining more of the finer detail. You can see more grain in the wood of the violin.

 

[vick1982 15]

so still no HDR  tone mapping on emby ?  

all the things I read from developers on here in the past just veer off talking about quality not making much difference etc... like others have said its just about only needing to keep one file and it can be played on anything. To me it sounds as stupid as someone using windows media centre back in the day that can only play direct files to say there is no need to develop systems that can transcode... just watch your shit at home.

Edited January 1, 2021 by vick1982

[Luke 33666]

HDR Tone mapping when transcoding will be in Emby Server 4.6. Stay tuned to the beta channel over the next week if you'd like to help test.

[RDHoworth 6]

Hi,

has great news, and I will be happy to test.

Regards, Richard

[sooty234 266]

3 hours ago, Luke said:

HDR Tone mapping when transcoding will be in Emby Server 4.6. Stay tuned to the beta channel over the next week if you'd like to help test.

I'm going to be all over that!

[MilenPetrov 0]

version 4.6 no HDR tone mapping yet...

[PenkethBoy 2058]

because its not released yet!

[sooty234 266]

I'm not holding my breath....

[Carlo 4219]

Just be aware it takes a beefy CPU to do tone mapping while transcoding in real-time.

Even with tone mapping built in the vast majority of people will be better off with a normal 1080 version and a 4K version in a library only shared with people who can direct play it.

[sooty234 266]

You'll be surprised at how little tone mapping will add to the processing. All transcoding will be 1080, so it will actually be quite easy. I'll wager that a gen 6, 4 core i5 will do up to 3 consecutive transcodes, depending on the bandwidth it's transcoding down to. 1080 @ 10Mb/s should be easy enough.

[sooty234 266]

You guys can already get an idea of what it will be like. Just transcode a 4k 10bit SDR video. Tone mapping will be just a bit more than that.

[ebr 14051]

38 minutes ago, sooty234 said:

You'll be surprised at how little tone mapping will add to the processing. All transcoding will be 1080, so it will actually be quite easy. I'll wager that a gen 6, 4 core i5 will do up to 3 consecutive transcodes, depending on the bandwidth it's transcoding down to. 1080 @ 10Mb/s should be easy enough.

A lot of folks use machines less powerful than that but upon what are you basing these conclusions?

[sooty234 266]

2 minutes ago, ebr said:

A lot of folks use machines less powerful than that but upon what are you basing these conclusions?

Just try my last suggestion.

[sooty234 266]

@softworkz will tell you, reducing from 10bit to 8bit and applying debanding and dithering is the hardest part. Tone mapping is mostly about color accuracy. Of course it adds a bit of processing, but in downscaling with 10 to 8bit conversion is a sizeable render on its own. Adding the tone mapping into the mix doesn't require a lot of heavy lifting.

[ebr 14051]

4 minutes ago, sooty234 said:

reducing from 10bit to 8bit and applying debanding and dithering is the hardest part

But all of that has to be done as well to accomplish the final result.

[Carlo 4219]

Try it yourself. As an example if I run:

ffmpeg -i "F:\Movies\R\Rogue One A Star Wars Story (2016)\Rogue One A Star Wars Story (2016) - 4K.mp4" -vf zscale=transfer=linear,tonemap=mobius,zscale=transfer=bt709,format=yuv420p test.mkv

Not much going on here and look at the speed of 0.196x

 

[ebr 14051]

To be clear - we're going to make this work as best we possibly can but I think it is a bit optimistic to think it is going to be a piece of cake on a lot of hardware.  We'll see as the proof will be in the pudding.

[sooty234 266]

Oh I wasn't implying that the process is simple. Looking at the algorithms that haasn has written, it's very complicated. But my general point is that adding tone mapping to an already in place downscaling of 4k to 1080 and reduction of color from 10bit to 8bit shouldn't add a lot more processing.

[Carlo 4219]

Try running what I listed above on one of your HDR 4K files and see if you can get anywhere near a speed of 1x.  I can't on an i7.

In general a lot of people can't transcode a 4K file (tone mapping aside) near real time via CPU.  GPUs are game changers for transcoding power but tone mapping doesn't fit very well in that yet.

The command I used above is pretty basic to boot compared to what a typical transcode line will be when this tone mapping is added on top of what it already has to do.

If I resize first to 720 resolution with "-resize 1280x720" before the input "-i" I can double the speed but it's still to slow on my system for real-time use.

I'm sure there are some optimizations that could be done over these basic command lines but this gives you a good indication of how brutal this is with CPU only.  So a lot of systems may not be able to perform real-time HDR->SDR but could still use this in the background to convert files into other formats which is still a major gain in functionality.

As ebr mentioned the proof is in the pudding.

[sooty234 266]

34 minutes ago, cayars said:

Try it yourself. As an example if I run:

ffmpeg -i "F:\Movies\R\Rogue One A Star Wars Story (2016)\Rogue One A Star Wars Story (2016) - 4K.mp4" -vf zscale=transfer=linear,tonemap=mobius,zscale=transfer=bt709,format=yuv420p test.mkv

Not much going on here and look at the speed of 0.196x

 

I wish you'd at least try and think before you say something. You appear to be rendering to 4k x264. That's absolutely massive (and stupid). No downscaling. At 1080, there'll be 75% less data to render.

Please go away.

[sooty234 266]

Carlo, you're going to make me abuse you again... 

[Carlo 4219]

Did you notice the resize command I added?  Did you look at the resolution after it converts?

Do you understand what's being shown?

Edited January 18, 2021 by cayars