Page 16 of 24

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 2:16 pm
by admin
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.

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 3:07 pm
by Narkyy
Yes sorry, there's mostly visible blocking around vivid/deep colors.

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 3:38 pm
by admin
Got it, thanks. Keep that sample, I'm going to ask you for it later. ;)

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 4:24 pm
by admin
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.

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 4:35 pm
by Guest
Sounds like you are just flying thru it now

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 4:43 pm
by admin
It's working in my head. :lol:

Actually, I tested that one frame by just multiplying the RGB by 0.2 for the whole frame (because the largest RGB component is ~5.0) and the bright area looks great with no blocking or hue shift and more detail than madVR. So when I put the proper nonlinear function in place everything should look great. However, many a drop is spilt twixt cup and mouth. Or:

But, Mousie, thou art no thy lane,
In proving foresight may be vain;
The best laid schemes o' Mice an' Men,
Gang aft agley,
An' lea'e us nought but grief an' pain,
For promis'd joy!

-- "To A Mouse" by Robert Burns

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 5:37 pm
by Guest
So, what you are so eloquently saying is that poop happens

Re: HDR -> SDR tonemapping

Posted: Mon Jul 09, 2018 8:56 pm
by admin
Or, maybe, don't count the chickens before they hatch.

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 8:00 am
by Beta
Hi guys!

Is anyone here who can help to me fix this issue?
The source is HEVC
Thank You!

Image

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 10:08 am
by admin
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+.

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 11:29 am
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

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 2:00 pm
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

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 3:00 pm
by Guest
+1
Like

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 3:29 pm
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.

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 3:33 pm
by Guest
"The color contouring" issue seems to be gone, which was the problem so it looks good
Me, I am just 1

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 3:35 pm
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.

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 3:36 pm
by admin
gonca wrote:
Tue Jul 10, 2018 3:33 pm
Me, I am just 1
I count you double. Get over it. :twisted:

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 4:13 pm
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?

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 4:46 pm
by Guest
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

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 5:54 pm
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:

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 7:47 pm
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

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 9:16 pm
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:

Re: HDR -> SDR tonemapping

Posted: Tue Jul 10, 2018 11:36 pm
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.

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 12:54 am
by dmcs
Darn. That's unfortunate. :? :shock:

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 6:45 am
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.