Page 41 of 49

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
Screenshot_2018-07-10 latest jpg (JPEG Image, 960 × 540 pixels) - Scaled (98%).png (467.63 KiB) Viewed 261 times

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.

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 6:54 am
by dmcs
No rush, hehe. Btw, I thought you were going to say "... after the World cup match." :D

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 8:50 am
by admin
I'll be cheering for Croatia. You?

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 9:21 am
by dmcs
I'm neutral. :)

Re: HDR -> SDR tonemapping

Posted: Wed Jul 11, 2018 1:52 pm
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.

Re: HDR -> SDR tonemapping

Posted: Fri Jul 13, 2018 11:04 am
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.