HDR -> SDR conversion

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

Re: HDR -> SDR tonemapping

Post by admin » Sun Jul 08, 2018 10:13 am

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"?

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Sun Jul 08, 2018 10:19 am

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

Re: HDR -> SDR tonemapping

Post by admin » Sun Jul 08, 2018 10:23 am

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.

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Sun Jul 08, 2018 11:19 am

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
2.png (1.7 MiB) Viewed 2252 times
3.png
3.png (1.52 MiB) Viewed 2252 times

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

Re: HDR -> SDR tonemapping

Post by admin » Sun Jul 08, 2018 11:32 am

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. ;)

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

Re: HDR -> SDR tonemapping

Post by Narkyy » 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.

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

Re: HDR -> SDR tonemapping

Post by admin » Sun Jul 08, 2018 11:56 am

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.

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Sun Jul 08, 2018 12:15 pm

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
1.png (1.72 MiB) Viewed 2225 times

DGHDRtoSDR(impl="255", tm="mobius", light=160, peak=2.0)
2.png
2.png (1.72 MiB) Viewed 2225 times

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

Re: HDR -> SDR tonemapping

Post by admin » Sun Jul 08, 2018 12:46 pm

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
hdr.jpg (171.03 KiB) Viewed 2219 times
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.

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

Re: HDR -> SDR tonemapping

Post by dmcs » Sun Jul 08, 2018 8:54 pm

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 9:38 am

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

Maybe we need something like madVR's adaptive light setting.

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

Re: HDR -> SDR tonemapping

Post by admin » 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.

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 11:15 am

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.

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

Re: HDR -> SDR tonemapping

Post by dmcs » Mon Jul 09, 2018 11:43 am

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 12:32 pm

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?

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

Re: HDR -> SDR tonemapping

Post by dmcs » Mon Jul 09, 2018 12:47 pm

admin wrote:
Mon Jul 09, 2018 12:32 pm
@dmcs

Is this sample known to be Dolby Vision?
I'm not sure what you meant. m2ts has Dolby Vision metadata. mkv sample file doesn't.
Here's the full mediainfo of the m2ts file.

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 12:53 pm

Yes, I meant the m2ts. Thank you.

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 1:25 pm

Another cause of blockiness! I apply tonemapping individually to R, G, and B. This causes hue shifts depending on how the individual components are mapped. I have to apply it to the lightness L. So I am going to redesign everything to work in CIELAB space and apply tonemapping to the L of darks and lights to bring them into range of 709. If there are any out-of-gamut colors left then I'll decide what to do with them. If they are sparse I can just clip them. If not, maybe desaturate them. We'll see.

Finally thinking I might be understanding things. :lol:

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

Re: HDR -> SDR tonemapping

Post by dmcs » Mon Jul 09, 2018 1:34 pm

:salute: :salute:

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Mon Jul 09, 2018 1:44 pm

That would cause issues like this as well right? Not just in highlights

Image

Thank you for the hard work :hat:

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 2:16 pm

You're welcome. But please, whenever you say "issues like this" don't assume we know what you are talking about. Tell it in words too. I look at your last image and think "umm, OK, what issue?". Context is completely lacking.

I'll try to guess. You are thinking there are hue shifts there leading to a blocking effect. Hard to say without the source. But, yes, it can happen to any RGB color if the individual channels get different scalings from the tonemapping.

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

Re: HDR -> SDR tonemapping

Post by Narkyy » Mon Jul 09, 2018 3:07 pm

Yes sorry, there's mostly visible blocking around vivid/deep colors.

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 3:38 pm

Got it, thanks. Keep that sample, I'm going to ask you for it later. ;)

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

Re: HDR -> SDR tonemapping

Post by admin » Mon Jul 09, 2018 4:24 pm

Ha, I don't even have to go to CIELAB and back (which is expensive). I can do it directly in linear RGB space. Find the max of R, G, and B. Then tonemap that max one and apply the resulting scaling to all three. It's also faster than tonemapping all three individually, although for CUDA the actual kernel time is small compared to the frame transfer time, so it's a moot point.

gonca
Moose Approved/Curly Approved
Posts: 911
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca » Mon Jul 09, 2018 4:35 pm

Sounds like you are just flying thru it now

Post Reply