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! Looking forward to your results.

112 fps! It's that beast of a CPU you have weighing in again. ;) What was your prefetch value?
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

prefetch(16)
Still seem to be getting a HTTP error
I'll use my account for file sharing
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Wanna trade CPUs? I'll throw in a PS2 mouse. 8-)

I don't know about the HTTP error. I was able to attach an image to DJ's post. Are there any error details?
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

The mouse makes it tempting. :scratch:
How much cheese does it eat? ;)
By the way, you would have to get a different motherboard

No error details, could be sheer size of the bitmaps, or some issue on my end
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Let us try with jpeg
Jpeg didn't work
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

No problem, we'll swap mobos too. I'll toss in my GT 8600. Great card!

How big are the files you are trying to attach?
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

GTX 9800
Hope you meant 980
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Actually I meant GT 8600. Good to go? :twisted:

Board has no limits on file size, but PHP config also has limits. I don't know what they are. :|
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Back to business

HDRtoSDR 1-1
Image
SDR 1-1
Image

HDRtoSDR 1-2
Image

SDR 1-2
Image

HDRtoSDR 2-1
Image

SDR 2-1
Image

HDRtoSDR 2-2
Image

SDR 2-2
Image

If more tests are wanted I will do them shortly
Bitrates of original HDR videos are between 37 and 70 Mb/s
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

The sdr bmp are 5.93 MB
The HDRtoSDR bmp are 23.7
probably a file size limit
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Yes, probably a limit. I'll do some tests and see if I can mitgate it.

Thanks for the test images. Great selection of light and dark scenes. I'll digest these before asking for more. I really appreciate the work y'all put in on testing.

Things I am doing:

1. Disengage equalization in flat areas. I'll calculate the variance in the window and if it is below a certain amount then don't do equalization. Or fade it out based on variance. This should avoid banding and noise amplification with equal > 0.

2. Look at DJ's issue with the flowers. I'm still not quite sure what the problem is but DJ is sending me samples. There could be an issue with the 2020->709 gamut mapping for some colors but it looks good to me. We'll see.

3. Port equalization to CUDA. I'm looking at a sliding window version of equalization because it is easier to port to CUDA. The current approach has fixed LUTs per window and interpolates neighboring LUTs to avoid blocking.

4. The Reinhard mode can be improved. Also Hable can be added.

5. Vapoursynth native version.

Here's a little secret. In the DLL is a filter called WinHisto(strength, xwindow, ywindow) that is a port of my WinHisto VirtualDub filter. Look here for usage (maximum intensity option is removed):

http://rationalqm.us/winhistogram.html

Be careful, though, it currently does not like to receive a clip cropped by Avisynth+ (have to code pitches properly; not an issue in VirtualDub filters :facepalm: ) The avisynth equalization filter from vcmohan shows terrible blocking on the window boundaries. WinHisto avoids it by interpolating LUTs as described above.
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Can we access the WinHisto settings directly in HDRtoSDR
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

WinHisto() is included so you can run it standalone. If you are talking about the equalizer in the tonemapping, you can already set the strength; that is called equal. But the window sizes are fixed at xwindow=128 and ywindow=135. These have to evenly divide into 3840x2160 and the size seems to be a sweet spot for tonemapping.
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

So no cropping allowed in DGIndexNV unless the result is divisible, evenly, by 128 x 135
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

No, only Avisynth+ cropping is relevant.

But anyway, it's totally unrealistic that you would crop down to 3840x2160. Those dimensions are required by DGHDRtoSDR.

Don't worry too much about this because I will code it for proper pitch handling.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I completed some experiments with tempering the equalization based on the window variance of the histogram. Also tried using the interquartile range. Neither was useful for identifying flat areas, and in retrospect it's not surprising because what is needed is a measure of the spatial detail, and that is not encoded in the histogram. So my next attempt will be to develop a measure based on the spatial fourier transform of the window. If y'all have any ideas about this please post.

Another thing I will try is to use the anti-banding from my global histogram equalization virtualdub filter. If we can't find a solution we'll have to abandon the equalization idea, which would be a shame because it is really good at bringing out the detail in the crushed areas produced by the 2020->709 gamma transform and tonemapping.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Looks like the spatial fourier transform is what we need. Here's the transform of a flat area taken from the banded example submitted earlier in the thread:

test2.raw.mag.bmp
And here is a detailed area (sorry didn't get the same window size but it doesn't matter):

test4.raw.mag.bmp
So I can just check the brightness of a doughnut area around the origin. The hole in the doughnut excludes the effect of the overall brightness of the area. The outside margin of the donut excludes high-frequency noise. This will give me a good measure of the window detail that I can use to grade the amount of equalization: less in undetailed windows.

Fortunately, we have this:

https://developer.nvidia.com/cufft
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

As a Canadian I must say, reading your post about the doughnuts made me hungry :lol:
Just kidding
Looks like you are making significant progress :salute:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Canadians eat a lot of doughnuts? :?

Doughnuts in real life are no good, unless you want to be fat and sick. Low carb/sugar, high fat is the way to go.

I think the fourier transform idea is going to really make histogram equalization a much more useful thing, and not just for tonemapping.
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

Sounds like you have ideas for the Fast Fourier Transform
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

@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
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

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

Re: HDR -> SDR tonemapping

Post by admin »

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

test2.mag.bmp
test4.mag.bmp
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
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

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.
DAE avatar
Guest

Re: HDR -> SDR tonemapping

Post by Guest »

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