HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs » Tue Jun 19, 2018 9:39 pm

In the manual of the version 1.4 says that the "gamma" parameter has a default value of 1.42. Could this be a typo?

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Tue Jun 19, 2018 11:32 pm

dmcs wrote:
Tue Jun 19, 2018 9:39 pm
In the manual of the version 1.4 says that the "gamma" parameter has a default value of 1.42. Could this be a typo?
Yes it's still following previous versions with default at 0.42

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

Re: HDR -> SDR tonemapping

Post by admin » Wed Jun 20, 2018 6:20 am

dmcs wrote:
Tue Jun 19, 2018 9:39 pm
In the manual of the version 1.4 says that the "gamma" parameter has a default value of 1.42. Could this be a typo?
More like a brain fart. Why do I keep doing this? :?

Updated online. Thanks for pointing it out.

dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs » Mon Jul 02, 2018 5:55 pm

Hi,
I am having an issue with highlight being overblown in this particular scene.
If I set light=500, it seems to alleviate the problem, although not entirely. However, every thing else will be too dark. And adjusting gamma brings back the issue.

HDR No tonemapping
Image

Mobius, light=160
Image

Mobius, light=250
Image

Mobius, light=500
Image

SDR
Image

Sample:
https://mega.nz/#!8IggFAqb!LOTOfwBozW-E ... LF5Z-VaeHU

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 02, 2018 10:05 pm

I'll investigate. Thank you for the report and the sample, dmcs.

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

Re: HDR -> SDR tonemapping

Post by admin » Fri Jul 06, 2018 2:08 pm

@dmcs

Your SDR screenshot appears to have some heavy tonemapping that I cannot obtain from the algorithms I have tried. Maybe it is just lower gamma for the scene. It also probably uses a compression gamut mapping rather than a clipping one, see below.

I have double checked my gamut mapping. It is standard 2020->709 with clipping. In say frame 24 of your sample, the only clipped colors are in the middle of the bright area. So that SDR shot appears to be made with compression gamut mapping together with gamma reduction.

Lowering gamma does help with DGHDRtoSDR to restore the darks for that scene, but I assume when you say "brings back the issue", you mean the clipping of the bright spot, such that it shows a clear outline of a brighter area. Is that correct? If so, I can implement a compression style gamut mapping. I believe madVR moved from clipping to compression after similar observations. My simple idea is to convert to Lab and then compress the L before converting back to linear RGB with 709 coefficients. But there are many ways to go.

https://pdfs.semanticscholar.org/fd0d/4 ... 194c01.pdf

I'll drop madshi a line to ask what he is doing in this regard. How does madVR do with this scene?

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Fri Jul 06, 2018 6:11 pm

Old versions of madVR used to have a similar issue, fixed a while ago though.
Took a screenshot from v.0.92.14 but madshi has been working on proper colors in highlights in the last few test builds, still waiting on a final decision.

There's definitely some desaturation happening, in the past you could adjust % brightness & saturation.
Hopefully these help

madvr.png
madvr.png (1.83 MiB) Viewed 707 times
madvr2.png
madvr2.png (1.63 MiB) Viewed 705 times
madvr3.png
madvr3.png (1.82 MiB) Viewed 705 times
DGHDRtoSDR looks closest to color corrected, though with blocking.

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

Re: HDR -> SDR tonemapping

Post by admin » Fri Jul 06, 2018 8:59 pm

Super helpful, Narkyy, thank you! I've dropped a line to madshi. Hopefully he can share some insights. Meanwhile I am implementing a "hue/lightness-preserving chroma mapping" algorithm in CIELAB (not the lightness mapping I suggested in my previous post). There are hundreds of ways to go with this. :wow:

If you look carefully at the original HDR version, you can see there is a subtle contour in the bright area, but it is greatly amplified by clipping.

The problem with hue preservation is that CIELAB is not a perfect perceptually linear space. But nobody knows a perfect perceptually linear space, so we are in the realm of heuristics and time-complexity tradeoffs. I'm hopeful we can find a reasonable algorithm that works well for most scenes, and whose performance dominates when parallelized with CUDA.

dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs » Sat Jul 07, 2018 7:43 am

admin wrote:
Fri Jul 06, 2018 2:08 pm
Lowering gamma does help with DGHDRtoSDR to restore the darks for that scene, but I assume when you say "brings back the issue", you mean the clipping of the bright spot, such that it shows a clear outline of a brighter area. Is that correct? If so, I can implement a compression style gamut mapping. I believe madVR moved from clipping to compression after similar observations. My simple idea is to convert to Lab and then compress the L before converting back to linear RGB with 709 coefficients. But there are many ways to go.
Yes. That was what I meant. Can't thank you enough for your time & the work you've done. :salute: :salute:

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

Re: HDR -> SDR tonemapping

Post by admin » Sat Jul 07, 2018 12:00 pm

You're welcome. We'll get this sorted out.

Post Reply