HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

You're right, there's a difference between none and mobius mostly only in highlights, mobius being much better at retaining detail and not overblowing the lighting.

However the colors are still off, and increasing saturation doesn't restore the reds.
I managed to get the old 1.2 version of the plugin and the colors are much better.

In order: none, mobius, old plugin
1.png
2.png
3.png
I don't really care about Hable either anymore, but I'm not sure it's a problem with Hable as it works properly on the old plugin.


Tested HDRTools with the different chromacity parameters
1 is Gx=0.265, Gy=0.690, Bx=0.150, By=0.060, Rx=0.680, Ry=0.320 (BT2100, from the github page)
2 is Gx=0.170, Gy=0.797, Bx=0.131, By=0.046, Rx=0.708, Ry=0.292 (BT2020, from the code)

4.png
5.png
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

That's great info, thanks. Can I get the source file to be able to investigate all this? Thank you.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Here's a small sample of the part
https://mega.nz/#!AVliwIqa!XSnOsoEAMGG8 ... R9hW8QvtYE

Script for HDRTools 0.1, it errors with the latest 0.2 for some reason.
ConvertYUVtoXYZ(Color=0,OutputMode=1, Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Rx=0.708,Ry=0.292,Wx=0.31271,Wy=0.32902)
ConvertXYZ_HDRtoSDR(MinMastering=1, MaxMastering=1000,Coeff_X=26, Coeff_Y=26, Coeff_Z=26)
ConvertXYZtoYUV(Color=2, OutputMode=2, pColor=0)
z_ConvertFormat(pixel_type="YV12")
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Great, thank you.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

@Narkyy

Please re-download version 1.4 as I have slipstreamed a fix for the colors issue. Looks good to me although, again, this may not be my final gamut mapping solution.

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

@douzi

For your stream with the blown-out heater set light=400-500 for good results with this new version. I am working on a heuristic to set light automatically based on the metadata and video content.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Re-download one more time. I had the old version up instead of the new one. It is updated now.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

It looks good now, pretty much the same colors as HDRTools :hat:
Also where has Mobius been all this time? It's amazing the control you can have over highlights, which Hable didn't have :bow:
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Thanks for the testing, Narkyy. The mobius concept comes from MPV with some of my own changes and implemented for CUDA of course. I like it because the parameters are simple and easy to understand, whereas Hable...oy. Maybe Hable can give similar results, but good luck finding the parameter combination.

HDRTools will be fixed shortly for the issue you mentioned, according to the author.
DAE avatar
Dion
Posts: 23
Joined: Sun Dec 04, 2016 12:30 am

Re: HDR -> SDR tonemapping

Post by Dion »

Was never a fan of Hable but I did like Reinhard but it had issues.. Looks like mobius solved alot of those issues.

The amount of work you put into this is incredible.. :bravo:
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Thanks, HDR to SDR is a niche area but I like showing off what CUDA can do.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

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?
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

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

Re: HDR -> SDR tonemapping

Post by admin »

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.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

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

Re: HDR -> SDR tonemapping

Post by admin »

I'll investigate. Thank you for the report and the sample, dmcs.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

@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?
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

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
madvr2.png
madvr3.png
DGHDRtoSDR looks closest to color corrected, though with blocking.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

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.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

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

Re: HDR -> SDR tonemapping

Post by admin »

You're welcome. We'll get this sorted out.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Narkyy wrote:
Fri Jul 06, 2018 6:11 pm
DGHDRtoSDR looks closest to color corrected, though with blocking.
What do you mean by "with blocking"?
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

I'm not sure if it's what you mean as clipping, but on the edges going from very bright light to green it looks like squares instead of a smooth transition/gradient.
Mostly noticeable at lower light like the light=160 screenshot, the one at 500 looks good.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

OK, thank you. We could call it contouring. The thing is, though, if you take the HDR screenshot and tweak levels (or brightness/contrast) on it, you can see these same contours. So what is so wrong about my rendering? And does it really make a big deal of difference for unusual scenes like this?

I tried gamut mapping it by compressing the saturation rather than just clipping the RGB and it made no noticeable difference. The clipped (out of gamut) area is actually a smaller ellipse within the bigger bright ellipse. This inner contour is not noticeable within the bigger bright ellipse (I see it only by changing out of gamut colors to full red), and so changes to its mapping won't affect the bigger bright contour. And that bright contour is present in the HDR as I said. I'm thinking for dmcs this may be more a matter of the lightness levels than contouring.

@dmcs

Can you please provide a bigger source video sample that includes extra "normal" scenes around the one you gave. I am trying to determine the correct light level to use. The metadata says light=1000 but that makes things too dark. I can give you my FTP details if needed.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

I guess it's the same issue as this post viewtopic.php?f=14&t=617&start=320#p8494
Looks good only at high nits, but increasing that affects the whole frame.
Another comparison with peak=3 and HDRTools

2.png
3.png

Though like said before HDRTools is more complicated to understand what's being done.

Also metadata from HDR streams usually only determines the peak nits the highlights should be clipped at, I think.
Which is why it looks too dark.
For example: Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
However there's also MaxFALL (Max Frame-Average Light Level) but it's not always specified in the stream metadata.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I really need a bigger source sample from dmcs. There's no way to make good decisions based on a few frames of a very unusual scene.

Your screenshots are not labeled so I cannot tell what they are (what is 2.png, what is 3.png?). That makes them useless. ;)
Post Reply