HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Thanks, gonca. It's not so much about the coding as it is the debugging. I have always been a kick-ass debugger, all modesty aside. It's easy to crank out code; making it actually work right is the challenge. But I am a good coder too. ;)

I completed the metric (but my doughnut is a square one, hehe). Here it is in action. First the flat window (the first image is the input image and the second is the fourier transform image):

test2.bmp
test2.mag.bmp

The detail metric for the flat window is 0.055790. And now the detailed window:

test4.bmp
test4.mag.bmp

The detail metric for the detailed window is 0.903815. This gives a ratio of about 16:1 for the two metrics.

The metric is normalized for overall brightness of the window. It's clear that this metric effectively distinguishes flat areas from detailed areas.

Next step: integrate this metric into DGHDRtoSDR and use it to modulate the equalization.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I implemented batched FFT for all the windows in the frame with one execute call. This improved performance as expected. But more importantly, I experimented with the FFTW library and discovered that for my transform size (128 x 135 real-to-complex), multithreaded FFTW is about twice as fast as cuFFT! The reason of course is (yet again) the overhead of transferring data to/from the GPU. Using FFTW will also allow me to overlap the GPU activities and the CPU activities (kernel execution is asynchronous), whereas if I used cuFFT, everything would be running serially on the GPU.

So finally now I am ready to start integrating this metric into DGHDRtoSDR and to see if the banding due to equalization can be avoided. I'm really learning a lot!
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

It is, after all, the Fastest Fourier Transform in the West
Good to know you are still learning, good to keep the brain cells active and alive
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Unfortunately, the FFT-based idea to salvage equalization is not working out, for two main reasons. First, the metric does not reliably distinguish flat areas in real video full frames. There is simply two much variance for it to make a clean cut. Second, equalization itself changes the overall brightness of the window, which produces a horrid effect in the full frame when not all windows are equalized. So for now I am removing this functionality. I doubt that it can be salvaged.

Here is DGHDRtoSDR 1.1:

* Equalization mechanism removed.

* Reinhard replaced with gamma. I find it works better.

* You can now crop and resize before calling DGHDRtoSDR().

* See the user manual for details and examples.

http://rationalqm.us/misc/DGHDRtoSDR_1.1.rar
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Thanks for the update :hat:

I've tried the new gamma tonemap and noticed that the midtones are lacking in brightness.
However default is much better than Hable for the highlights.
Some comparisons and respective settings:

SDR Image

dghdrtosdr(impl="255",light=47,gamma=0.38) Image

DGHable(exposure=1.0, w=2.5) Image

Odd values for Hable but they're what I find work well when the highlights are not bright enough at default.
Reinhard (other than bad highlights) behaved similarly as Gamma does, but Hable has that extra 'w' parameter that makes the difference.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Try gamma of 0.40 to 0.42 and report back. Thank you.

gamma= 0.42 is the theoretically correct value. I set a lower one to bring out some black detail but probably set too low.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

admin wrote:
Mon May 21, 2018 4:53 pm
Try gamma of 0.40 to 0.42 and report back. Thank you.

gamma= 4.2 is the theoretically correct value. I set a lower one to bring out some black detail but probably set too low.
Typo, I guess?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

For sure. Corrected, thank you. :salute:
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Here's the same frame, gamma at 0.40 and 0.42
It does improve the contrast, though still dim in terms of brightness where light shines.
However the Hable method often results in some scenes brighter than SDR, so it might work better in places.

If I increase light, it only makes the paper overblown and loses detail there (which is already happening at 0.47)

dghdrtosdr(impl="255",light=47,gamma=0.40) Image
dghdrtosdr(impl="255",light=47,gamma=0.42) Image
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Honestly, I cannot see the things you claim to see and they seem highly subjective to me in any case. So I'll just add Hable as an option and declare mission accomplished.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Yes sorry it is subjective, otherwise the tonemap is great :salute:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I added Hable:

http://rationalqm.us/misc/DGHDRtoSDR_1.2.rar

Please read the instructions carefully as parameters have changed.
If you'd like to argue for any different Hable default values just speak up.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

I've got this weird green thing when using Hable in the latest DGHDRtoSDR_1.2.
hable_065806.png
Gamma mode:
gamma_065806.png
My code for Hable mode:

Code: Select all

DGSource("source.dgi", fulldepth=true)
Crop(0, 280, -0, -280).Spline36Resize(1920, 800)
DGHDRtoSDR(impl="255", light=35, tm="hable")
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Set up some samples for version 1.1, but I was a little late, updates are fast.
So here are some images for 1.2
Script is

Code: Select all

LoadPlugin("C:/Program Files (Portable)/dgdecnv/x64 Binaries/DGDecodeNV.dll")
DGSource("D:\#test\#hdr\hdr 1.dgi", fieldop=0, fulldepth=True)
LoadPlugin("C:/Program Files (Portable)/AVS Templates/DGHDRtoSDR_1.2/x64/DGHDRtoSDR.dll")
DGHDRtoSDR(impl="255",tm="gamma",light=40,gamma=0.40)
prefetch(16)
Images are resized to 1280x720 at 8 bits
HDRtoSDR 1-1
hdrtosdr 1-1.bmp
SDR 1-1
sdr 1-1.bmp
HDRtoSDR 1-2
hdrtosdr 1-2.bmp
SDR 1-2
sdr 1-2.bmp
HDRtoSDR 1-3
hdrtosdr 1-3.bmp
SDR 1-3
sdr 1-3.bmp
More samples can be quickly obtained if needed/desired
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

dmcs wrote:
Tue May 22, 2018 3:54 pm
I've got this weird green thing when using Hable in the latest DGHDRtoSDR_1.2.
That's weird. Can I get your unprocessed source sample that produces this? I can't make it happen with my samples. Thank you.

EDIT: OK, I have a sample that shows it. It would still be great to get yours. It doesn't fail with impl="sw" for me, BTW. Investigating...
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Thanks for the testing, gonca!
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

For comparison
Speed of script is over 128 FPS
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

admin wrote:
Tue May 22, 2018 4:09 pm
Thanks for the testing, gonca!
The results with gamma look very good to me, might need a dash higher brightness.
But to be honest, no one approach with one set of default settings will be perfect for every source.
Right now we have gamma, Hable, and if the "old" plugin works, Reinhart
It takes very little time to create a script, and index a movie in order to load it into VDub
Then we can adjust settings, or approach, quickly until we get our desired results.
After all, a lot of this is subjective
Set it up to get the results you like
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

dmcs wrote:
Tue May 22, 2018 3:54 pm
I've got this weird green thing when using Hable in the latest DGHDRtoSDR_1.2.
Please re-download and test again. Should be fixed.

Thanks for pointing this out. :salute:
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

admin wrote:
Tue May 22, 2018 4:30 pm
Please re-download and test again. Should be fixed.

Thanks for pointing this out. :salute:
Yay!!! So, may I ask what was that? :)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I forgot to clip the RGB to >= 0 after the Hable step.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Can the Hable parameters be changed with the new plugin? I'm not sure if I missed something in the readme or not.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Yes. Use parameters exp, a, b, c, d, e, f, and white.

The document mentions w but it should be white. I'll fix that now.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Ah yeah, I should've tried more than just w :)
Thanks!
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Had some time so I ran another test
Same settings and conditions as before

HDRtoSDR2-1
hdrtosdr 2-1.bmp
SDR 2-1
sdr 2-1.bmp
HDRtoSDR 2-2
hdrtosdr 2-2.bmp
SDR 2-2
sdr 2-2.bmp
HDRtoSDR 2-3
hdrtosdr 2-3.bmp
SDR 2-3
sdr 2-3.bmp
Post Reply