HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
DAE avatar
Beta
Posts: 10
Joined: Tue Jul 10, 2018 7:54 am

Re: HDR -> SDR tonemapping

Post by Beta »

admin wrote:
Tue Jul 10, 2018 10:08 am
Looks like an AVSPMOD issue (AVSPMOD not using Avisynth+?). Try to open your script in VirtualDub2 and report the result. Note that these filters require Avisynth+.
Thank You!!

I forgot that avisynth+ has two versions!!

We need for this:

https://github.com/pinterf/AviSynthPlus/releases

Now its all fine!!

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

Re: HDR -> SDR tonemapping

Post by admin »

Following is my latest result for mobius applied to the lightness rather than individual color channels (frame 2467 of the sample). Specifically, using this script:

dghdrtosdr(light=200,tm="mobius",trans=0.3,peak=2.1)

Even at fairly bright light=200 there is better detail than in the madVR result, and at the same time there is no severe artifacting or hue shifting. I'm pretty happy with this. One interesting thing is that as you raise the peak past 2.1 more strong whites coming in causes the compression to increase and hue changes start to appear. I don't see a need for higher peaks but I will investigate if it is possible to include them without hue shifts, possibly by going to a more constant hue color space like ICtCp.

https://www.dolby.com/us/en/technologie ... -paper.pdf

What do y'all think of this result? If you like it I'll make a release.

latest.jpg
User avatar
gonca
Curly Approved/Moose Approved
Posts: 956
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca »

+1
Like
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Surely you count for more than 1? ;)

I tested it on the previous problematic stream (the one with the heater bars that disappeared). The bars remain intact with all light levels. I also tried it on the The Great Wall scene with the riders kicking up dust in the sun and it gives way better detail in the clouds to the left of the riders than anything before. So it's looking good. I have one little thing to fix up and then I'll give a release. Still 110 fps with my i7-7700K + 1080 Ti.
User avatar
gonca
Curly Approved/Moose Approved
Posts: 956
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca »

"The color contouring" issue seems to be gone, which was the problem so it looks good
Me, I am just 1
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Beta wrote:
Tue Jul 10, 2018 11:29 am
Thank You!!
You're welcome, Beta, and welcome to the forum! Look out for the next release, it will handle highlights way better.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

gonca wrote:
Tue Jul 10, 2018 3:33 pm
Me, I am just 1
I count you double. Get over it. :twisted:
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

OK, I fixed the last little wrinkle and all the previous streams look great, IMHO.

Now, as things are looking so good with mobius, and as mobius has simple and easy-to-understand parameters, I want to ditch hable. Hable has a boatload of non-intuitive parameters and I never did figure out how to set it up right. So I give y'all an opportunity to object before I remove it. If you can make a strong case for it maybe I'll leave it there. I'm going to decide later tonight.

Another thing I noticed (and which is described in the literature) is that the approach I have taken can produce highly saturated colors that can sometimes look like too much. The sat parameter is there so you can desaturate the result. My question is should I leave the default sat at 1.0, or reduce it to (say) 0.8?
User avatar
gonca
Curly Approved/Moose Approved
Posts: 956
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping

Post by gonca »

I would say, go for one approach and ditch Hable
The saturation thingy, drop it to 0.8 and then adjust the default, if needed, in the future based on feedback
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

Ideally saturation should only be adjusted for around highlights that cause these very saturated colors, as overall the default saturation is good.
I don't think anyone cares for Hable anymore :salute:
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

admin wrote:
Tue Jul 10, 2018 2:00 pm
What do y'all think of this result? If you like it I'll make a release.
I think it looks really good. But, please allow me to be a bit nitpicking :)

There seems to be little artifact exists along the contour if you look closely (literally). Well, either that, or the saturation makes me think it's artifact? Anw, I don't think anyone would notice during normal playback.

Thanks a lot for your hard work. :salute: :salute:
Screenshot_2018-07-10 latest jpg (JPEG Image, 960 × 540 pixels) - Scaled (98%).png
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

Yes, I noticed it too. I agree it's probably not noticeable but I may know the cause so why not try to fix it. I'm still just clipping R/G/B values that end up negative after 2020->709. I need to tonemap them as I do for values > 1.0. I'll see if I can mitigate it.

Good eyes! :wow:
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

OK, I did some more deep looking. The clipping of R/G/B values < 0 is relatively insignificant. I'm thinking the real problem is that RGB space is not constant hue and saturation for brightness changes. So, for example, if we take an RGB value and reduce its brightness by multipying all the channels by (say) 0.5, there is a subtle hue and saturation change. So in a real image where in gamut colors of a given hue and saturation can be right next to out of gamut ones with the same hue and saturation (one is just brighter), if we scale down the out of gamut one then now we can see blocking because the hues and saturations are now different when they should have stayed the same. Bottom line, we can't do lightness compression in RGB space. I hoped to get away with it, but it is now apparent that it was too cheap. :cry:

Next step, try a more hue/saturation-linear space like xyY, CIELAB, or ICtCp.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

Darn. That's unfortunate. :? :shock:
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

After sleeping on it I'm not convinced by my own explanation. Those blocks are much bigger than a pixel so something other than what I suggested must be causing it. Investigations continue today after I take care of renols's issue with DGDecNV.
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

No rush, hehe. Btw, I thought you were going to say "... after the World cup match." :D
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I'll be cheering for Croatia. You?
DAE avatar
dmcs
Posts: 36
Joined: Sat Oct 21, 2017 9:40 pm

Re: HDR -> SDR tonemapping

Post by dmcs »

I'm neutral. :)
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I definitely now understand why the blocking is occurring. It is, after all, the clipping of values below 0 for the R, G, and/or B channels. I traced the detailed processing for two pixels, one each side of a block boundary. The original YUV420P16 values are close enough that we would expect the output pixels also to be close in YV12 values. But one of the pixels obtained a negative R value after 2020->709 (so it's out of gamut) while the other did not (all others were nonzero). Then when clipped and converted the final Y,U,V values were:

pixel 1: 142,102,36
pixel 2: 158,95,60

These differences are easily visible. For another pair in the same vicinity but without a block boundary between them, the resulting values are close and so no boundary becomes visible.

So, without a doubt, I have to do something more intelligent than clipping values that are below 0. One option is to iteratively reduce the saturation of the pixel by a small amount until it is back in range.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping

Post by admin »

I decided to release 1.5 with the improvement of highlight handling and the removal of hable. The artifacting for very bright highlights is not solved as I cannot find a way to salvage the simple matrix conversion of 2020 to 709. Nevertheless, it is not so perceptible (especially at HD resolution) and affects only very bright highlights.

My plan now is to ditch the simple matrix conversion and do full proper gamut mapping. I'm going to generate 2D lightness/chroma gamut maps for 709 for each hue (sampled at probably one degree around the hue cylinder). Then I will use these to compress out-of-gamut colors onto the gamut boundary. These gamut maps will be pre-generated and stored in the executable for high performance. Given the maps, there are of course many ways to use them and I will test different options. This approach will eliminate the artifacting as clipping of RGB values below 0 will not apply.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR tonemapping

Post by Narkyy »

:hat:
There seems to be some issues with the update :(

v1.4
Image

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

Re: HDR -> SDR conversion

Post by admin »

C'mon Narkyy, I asked you before to explain and not just say "some issues". :evil:

And you know I need the script and a source sample to do anything.
DAE avatar
Narkyy
Posts: 51
Joined: Thu May 25, 2017 11:51 pm

Re: HDR -> SDR conversion

Post by Narkyy »

My bad, I thought it was obvious, the lighting is all weird on the window side.
The plain white looks like saturation was applied to it and luminance dropped completely.

Image

Sample: https://mega.nz/#!sVtAnAIQ!lOOwvKGOWy-l ... Y9LyzWQmLk
Script
FFVideoSource("sample.mkv", colorspace="YUV420P10")
ConvertBits(16).DGHDRtoSDR(impl="255", light=150, peak=2)
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin »

Thanks. Will look into it.

EDIT: 1.5 temporarily withdrawn.
User avatar
admin
Site Admin
Posts: 4449
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin »

I've redesigned my gamut mapping and tonemapping. Here is what I am getting for the problematic Narkyy scene with dghdrtosdr(light=150). This is using simple Reinhard tonemapping. I may bring back Mobius but it is currently not behaving as expected. The result looks good to me. Highlights are handled well and artifacting is gone. I have to regression test it on all my other HDR streams.

EDIT: The new method does not require the sat=0.8 tweak but I posted this shot before realizing that and default 0.8 was used. So it may look a bit desaturated.

narkyy.jpg
Post Reply