HDR -> SDR tonemapping

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

Re: HDR -> SDR tonemapping

Post by admin » Tue May 15, 2018 8:49 pm

@dmcs

I appreciate the humor of the post you made, but in the current PC climate it could get us in trouble, so forgive me for deleting it.

User avatar
admin
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Tue May 15, 2018 8:50 pm

gonca wrote:
Tue May 15, 2018 4:04 pm
Sounds like you have ideas for the Fast Fourier Transform
This is CUDA land. Slow does not exist here. ;)

User avatar
admin
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Thu May 17, 2018 1:48 pm

I've got the cuFFT working. Here are pictures for flat and detailed windows:

test2.mag.bmp
test2.mag.bmp (50.68 KiB) Viewed 162 times
test4.mag.bmp
test4.mag.bmp (50.68 KiB) Viewed 162 times
While it is certainly usable to distinguish flat areas, the FFT magnitude plot differs from the one I get with a brute force fourier transform (C code, not FFT). The CUDA one seems compressed along the X axis. I want to look at that before trying to use this for the mitigation of equalization.

User avatar
admin
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Fri May 18, 2018 8:52 am

I found and fixed the pitch bug I had that was making skinny FFT plots. Now I will develop the metric based on the doughnut idea. After that will integrate it into the equalization code to make the strength of the equalization a function of the amount of detail in the area. Looking good so far.

gonca
Distinguished Member
Distinguished Member
Posts: 515
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca » Fri May 18, 2018 8:59 am

Man, you are fast and good at coding
Well done :salute:

User avatar
admin
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Fri May 18, 2018 9:54 am

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.bmp (50.68 KiB) Viewed 132 times
test2.mag.bmp
test2.mag.bmp (50.68 KiB) Viewed 132 times

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

test4.bmp
test4.bmp (50.68 KiB) Viewed 132 times
test4.mag.bmp
test4.mag.bmp (50.68 KiB) Viewed 132 times

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
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Sat May 19, 2018 7:00 pm

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!

gonca
Distinguished Member
Distinguished Member
Posts: 515
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca » Sat May 19, 2018 7:53 pm

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
Site Admin
Posts: 3669
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin » Mon May 21, 2018 12:56 pm

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

Narkyy
Posts: 19
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy » Mon May 21, 2018 4:13 pm

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.

Post Reply