HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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
Posts: 4551
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. ;)
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

In order: peak=3, HDRTools tonemap
Regarding dmcs' issue, I guess peak=2 would fix the overblown highlight. That's usually a value that works well.

I just derailed from the initial problem with the "contouring" issue, sorry for that.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Narkyy wrote:
Sun Jul 08, 2018 11:37 am
In order: peak=3, HDRTools tonemap
Regarding dmcs' issue, I guess peak=2 would fix the overblown highlight. That's usually a value that works well.

I just derailed from the initial problem with the "contouring" issue, sorry for that.
I still don't get it. Can you give the script for each screenshot.

I'm not conceding that my rendering is "overblown". How do you define that and how do you determine if something is overblown?

I do prefer to stick with one sample until we reach some closure and not confuse it with others.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

I'm guessing he's comparing with the SDR version (from a SDR mastered Bluray).
The center of the highlight (luma around 235) is wider with default settings, so "overblown".
Either that or 235 is too high? I don't know.
Mobius' peak setting does help because it doesn't affect the overall brightness, just highlights.


SDR
Image


DGHDRtoSDR(impl="255", tm="mobius", light=160)
1.png

DGHDRtoSDR(impl="255", tm="mobius", light=160, peak=2.0)
2.png
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

light = 160 is way too low, in my opinion. Don't blame me for blown out areas with that light setting.

I'm going to wait for dmcs to tell me what he thinks is wrong and why. I do not see anything wrong with my rendering (light = 500 + default mobius).

Here is the HDR screenshot naively sharpened:

hdr.jpg
The contours are there in the source. I'm not interested in duplicating some random SDR conversion of which we know nothing. I only want my rendering to be decent across all scenes and videos.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

Hi,
I hope a 3 minute sample would suffice. Let me know.

Code: Select all

https://mega.nz/#!oYNFQaTS!fruexcgJYX_BtlfXzTnDEhjgibgdHoqhT0762v_l7Kg
I think I've jumped into the "overblown" conclusion too early. My apology. Here are some screenshots that I took, using Mobius, with light=250 and 500 respectively (other parameters are set at default) and madVR.

In order: HDR no tonemapping -- light=250 -- light=500 -- madVR

Image Image Image Image

Image Image Image Image

At light=500, the scene with the turntable looks fine, smooth transition from the brightest center outwards. But then the other scene looks really dark.

For light=250, the results are reverse. In the scene with the turntable, there appears to be a teal blocky boundary (aliasing artifact?) along the contour of the brightest area.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

3 minutes is great, dmcs. Thanks for the sample. Investigating...

Maybe we need something like madVR's adaptive light setting.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

@dmcs

Can you tell me how that bigger sample came to be? Is it from a UHD bluray? How was it processed? If it is from a UHD bluray, it would be much better for me to get the m2ts file. One problem with the mkv is that we don't know for sure all the metadata is being preserved.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Bingo! Pretty sure I've found the problem. I was clipping the out-of-gamut RGB before applying the tonemapping. Duh. Of course we should do it after, because the tonemapping is going to pull lots of super-bright pixels into gamut. After changing this I get good results even with light as bright as light=100. By good I mean the bright blob at frame 2676 does not expand and completely lose its detail. The mobius settings for it are trans=0.8, peak=5.0. They won't help you though until I release the fixed version. I will do that after a little more experimentation.

I said this in reply to Narkyy:

"light = 160 is way too low, in my opinion. Don't blame me for blown out areas with that light setting."

Eating humble pie as Narkyy was right to choose that light level. We can go even brighter without blowing out the highlights with the change described above.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

admin wrote:
Mon Jul 09, 2018 9:45 am
@dmcs

Can you tell me how that bigger sample came to be? Is it from a UHD bluray? How was it processed? If it is from a UHD bluray, it would be much better for me to get the m2ts file. One problem with the mkv is that we don't know for sure all the metadata is being preserved.
Yeah, I used MKVToolNix to trim the file from the UHD remux. The mediainfo from the m2ts file and the mkv one are identical.

m2ts: https://p.teknik.io/Me5TA
mkv: https://p.teknik.io/LU6MD

And boy, am I glad to hear you're figuring things out. :D :D

Edit: The only metadata missing from mkv is the Dolby Vision. It's not supported by matroska yet.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Now I've figured out the cause of the blockiness compared to the original and madVR. I was always clipping R/G/B < 0.0 to 0.0. I need to tonemap them back into 709 range also instead of just clipping them.

@dmcs

Is this sample known to be Dolby Vision?
Post Reply