Support forum for DG Tools

Posted: **Thu Apr 19, 2018 5:01 am**

Now, that is a great question, because if they are dithering down, then the "extra detail" I saw may be just dithering. I will check the Avisynth+ and Vapoursynth source code today.

Posted: **Thu Apr 19, 2018 5:08 am**

ConvertBits(8) just drops the Least significant bit, so you need to add dither=0 or 1, whatever method you want to use there.

Posted: **Thu Apr 19, 2018 5:09 am**

According to this link the default is to not add dither
http://avisynth.nl/index.php/ConvertBits

dither = -1

Posted: **Thu Apr 19, 2018 5:59 am**

You beat me to it, I was just looking over there. That's what we want, no dithering. Thanks, guys.

Posted: **Thu Apr 19, 2018 7:28 am**

DJATOM wrote: ↑
Thu Apr 19, 2018 4:42 am
Code: Select all
clip = core.resize.Point(clip, format=YUV420P16)

That doesn't convert to 10-bit. I think this is correct:

import vapoursynth as vs
core = vs.get_core()
...
clip = core.resize.Point(clip, format=vs.YUV420P10)
...

Posted: **Thu Apr 19, 2018 3:49 pm**

Code: Select all

clip = core.resize.Point(clip, format=vs.YUV420P10)

will convert to 10 bit, but do I need to use

Code: Select all

clip = core.resize.Point(clip, format=vs.YUV420P10, dither_type=none)

to ensure that no dither is used?

Posted: **Thu Apr 19, 2018 4:04 pm**

dither_type none is the default.

Posted: **Thu Apr 19, 2018 5:01 pm**

Thank you
I didn't see that mentioned in the docs I looked at,
at least not in a way that I understood

Posted: **Thu Apr 19, 2018 5:41 pm**

See HolyWu on June 28, 2017 at 12:55 in this thread:

http://www.vapoursynth.com/discussion/

Posted: **Thu Apr 19, 2018 5:49 pm**

Thanks

Posted: **Thu Apr 19, 2018 8:52 pm**

You are welcome. It's always my pleasure.

Posted: **Mon Apr 23, 2018 12:27 pm**

So, we have established that we need to do the 2020->709 conversion and the tonemapping all together on the GPU if we expect CUDA to give us good performance gains. So I have been researching how to do that. Here is my tentative plan for the 2020->709 part. If it pans out then tonemapping can be added. Please advise if I am planning anything stupid. I'm a bit of a dilettante in the colorimetry area, so...

Code: Select all

Convert HDR 10-bit in YUV420P16 to YV12

Step 1: Convert to P10.

Strip lower 6 bits (zeros)

Step 2: Convert to RGB

R = 1.164(Y-64) + 1.596(V-512)
G = 1.164(Y-64) - 0.813(V-512) - 0.392(U-512)
B = 1.164(Y-64) + 2.017(U-512)

Step 3: Linearize

R = R * R
G = G * G
B = B * B

Step 4: Map the gamut using inverse of rec 2087 matrix

R          1.6605  -0.5877  -0.0728     R
G      =  -0.1246   1.1330  -0.0084  *  G
B         -0.0182  -0.1006   1.1187     B
709                                     2020

Step 5: Gamma correct

R = sqrt(R)
G = sqrt(G)
B = sqrt(B)
clamp as needed

Step 6: Convert to 8-bit YUV

Y =  (0.257 * R) + (0.504 * G) + (0.098 * B) + 16
U = -(0.148 * R) - (0.291 * G) + (0.439 * B) + 128
V =  (0.439 * R) - (0.368 * G) - (0.071 * B) + 128

This can now be returned as YV12 for Avsynth+.

Posted: **Mon Apr 23, 2018 3:49 pm**

I am a complete rookie at the color thingy, but based on all the stuff I have read on the topic, before my eyes glazed over, your approach seems to be spot on from the format (2020 to 709) to the clamping of the levels to accommodate the 8 bit standard

Posted: **Mon Apr 23, 2018 5:01 pm**

OK, good to hear. Of course, there are a lot of ways to map the out-of-gamut values back into range, but it seemed sensible to me to just reverse what is given for 709->2020 in REC 2087.

https://www.itu.int/dms_pubrec/itu-r/re ... !PDF-E.pdf

Posted: **Mon Apr 23, 2018 5:23 pm**

It does appear to be a logical approach
If
A>black box >B
then
B> inverse black box >A
Only in this case the black box is a known algorithm

Posted: **Tue Apr 24, 2018 7:37 am**

Earlier I was a bit concerned about whether an external Avisynth+ filter could change the video format, e.g., from YUV420P16 to YV12. Then I realized that is exactly what z_ConvertFormat() does. So I tried it and it is actually quite easy. So I now have a filter that just converts YUV420P16 to YV12 by truncating the lower 8 bits and it works fine. Of course without proper gamut mapping and tone mapping it is washed out as expected. But this forms the basis for implementing the process I gave a few posts up. So, well on the way to nirvana!

Posted: **Tue Apr 24, 2018 10:50 pm**

admin wrote: ↑
Tue Apr 24, 2018 7:37 am
Earlier I was a bit concerned about whether an external Avisynth+ filter could change the video format, e.g., from YUV420P16 to YV12. Then I realized that is exactly what z_ConvertFormat() does. So I tried it and it is actually quite easy. So I now have a filter that just converts YUV420P16 to YV12 by truncating the lower 8 bits and it works fine. Of course without proper gamut mapping and tone mapping it is washed out as expected. But this forms the basis for implementing the process I gave a few posts up. So, well on the way to nirvana!

Good Avatar.

Posted: **Thu Apr 26, 2018 8:59 pm**

I have coded the proposed algorithm in a C-code filter, eliminating the calls to z_ConvertFormat() in the script. It works quite well. Surprisingly, the speed is almost identical to the existing DGTonemap(). It's surprising because z_ConvertFormat() is assembler optimized. But apparently that's canceled out by the fact that the script uses two z_ConvertFormat() calls. The image quality is comparable to what we have from the existing DGTonemap script. I expect to see a large speedup when implementing it in CUDA. Keep your fingers crossed.

Posted: **Tue May 08, 2018 2:15 pm**

I have tossed out Hable/Reinhard and rolled my own locally adaptive tonemapping operator. Below is an example. Note the lack of blowout in the clouds and retention of detail there. Also, detail is retained on the dark areas of the left-hand rider. Detail in the hills is brought out nicely. To me, it nicely conveys the 'wow' factor of the original HDR. It's computationally more intensive but I think it's worth it and CUDA should give acceptable frame rates.

Here is the process (all done in C code for now):

* Convert full-depth YUV to 32-bit float RGB.
* Normalize R, G, and B to [0.0,1.0].
* Linearize with ST.2084 EOTF.
* Map the gamut from 2020 to 709 using the inverse of REC.2087.
* Tonemap with locally adaptive algorithm.
* Compress to 709 gamma.
* Scale to 0-255 and convert to YV12.

Posted: **Tue May 08, 2018 3:25 pm**

Amazing... :bravo:

When do we get to try this ourselves

Posted: **Tue May 08, 2018 3:41 pm**

Thanks. I have to port it to CUDA to make it practical. Patience!

Posted: **Tue May 08, 2018 3:48 pm**

Looking very impressive

Posted: **Tue May 08, 2018 8:14 pm**

Does porting to CUDA imply that it'll be integrated with DGSource and the indexing? Or still a standalone plugin?
Wondering as I can't currently use the indexing for HEVC

Thanks for the hard work

Posted: **Tue May 08, 2018 8:48 pm**

Narkyy wrote: ↑
Tue May 08, 2018 8:14 pm
Does porting to CUDA imply that it'll be integrated with DGSource and the indexing? Or still a standalone plugin?
Wondering as I can't currently use the indexing for HEVC

Thanks for the hard work

You're welcome.

It'll probably be a standalone filter requiring YUV420P16. The utility filters currently in DGDecodeNV.dll can be used independently of DGSource() and indexing, BTW, so even if I integrated it you could still use it. Why can't you currently use indexing for HEVC? No suitable nVidia card?

Posted: **Tue May 08, 2018 9:28 pm**

Yep, and from past support emails from a while ago I couldn't get the 970 to work with DXVA + Win10 for HEVC.
That sounds good then

Support forum for DG Tools

HDR -> SDR conversion

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping

Re: HDR -> SDR tonemapping