Support forum for DG Tools

Posted: **Sun Mar 18, 2018 8:45 am**

I never saw it, just got a sample from

Posted: **Sun Mar 18, 2018 10:14 am**

Both of your screenshots come out as 8 bit, so HDR data not coming thru?

Posted: **Sun Mar 18, 2018 10:21 am**

You're right that I had said the first was P016 2020. I have fixed that. Thanks for pointing it out.

The first is rendering HDR as SDR without the tonemapping. It shows what you get with a naive conversion. The difference is the whole reason for tonemapping.

Posted: **Sun Mar 18, 2018 10:40 am**

The tonemapping one looks pretty good
When you wish, I can do comparison testing, UHD disks come with a BD version, so I can do HDR to HDR>SDR to SDR tests

Posted: **Sun Mar 18, 2018 10:52 am**

Cool, I'll definitely take you up on that when things are out of the oven.

Posted: **Mon Mar 19, 2018 10:41 am**

Discovering lots of things...

Most importantly, the internal Avisynth+ conversions are completely unsuitable for this, and pinterf has confirmed that. He recommended using the z.lib stuff. I converted to that and the results are now much better (gonca had supplied some disappointing test results with the internal conversions). Unfortunately, the z.lib stuff is dreadfully slow. I've inquired about it and I hope something can be done, but if not we have to accept that Avisynth+ is basically dead for this kind of work. There's no point to CUDA-accelerate the tone mapping if the conversions are the bottleneck. Let's see...

Current script:

Code: Select all

loadplugin("avsresize.dll")
dgsource("D:\Don\Programming\C++\Vapoursynth filters\Skeleton\Vapoursynth Test\THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
dgtonemap()
z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

Note to gonca, don't try to run this as it needs a new dgtonemap.dll.

Posted: **Mon Mar 19, 2018 11:51 am**

admin wrote: ↑
Mon Mar 19, 2018 10:41 am
gonca had supplied some disappointing test results with the internal resizing

So sorry to have been a Cassandra (read: prophet of doom) in the feature request thread, where I asked for CUDA resizing

Posted: **Mon Mar 19, 2018 12:12 pm**

Don't be sorry; that's weak.

It's not about resizing (I edited my post, thanks for pointing it out); it's about format conversions.

Posted: **Tue Mar 20, 2018 2:53 am**

admin wrote: ↑
Sun Mar 18, 2018 8:33 am
Before (converted without tonemapping) and after (with tonemapping) screenshots follow.

Nice.

Posted: **Tue Mar 20, 2018 5:33 am**

hydra3333 wrote: ↑
Tue Mar 20, 2018 2:53 am
Nice.

The first images I had up were not so great, because the Avisynth+ core colorspace conversions are not up to the job. But the images I replaced them with in the post are made with the avsresize (z.lib) conversions. They mimic the Vapoursynth core conversions but are very slow.

Posted: **Tue Mar 20, 2018 1:06 pm**

As Guest 2 suggests, it's time to port zimg to CUDA. It's not about Vapoursynth versus Avisynth+: CUDASynth.

Posted: **Tue Mar 20, 2018 3:25 pm**

But the images I replaced them with

They look good,great improvement with your new approach

Posted: **Wed Mar 21, 2018 7:34 am**

admin wrote: ↑
Tue Mar 20, 2018 1:06 pm
As Guest 2 suggests, it's time to port zimg to CUDA. It's not about Vapoursynth versus Avisynth+: CUDASynth.

Posted: **Wed Mar 21, 2018 11:48 am**

I have to say I'm really pleased to see all this going on.

The most intensive testing I've seen so far.

I should really upgrade my graphics card.

Posted: **Wed Mar 21, 2018 12:35 pm**

1050 Ti would be a good affordable step up.

Or wait for Volta. gonca and me, we like to waste our money to be on the bleeding edge. Gotta spend it all before I die.

Posted: **Wed Mar 21, 2018 3:18 pm**

Shiny new toys, never a waste
Besides, if I leave it behind someone else will just waste it on different shiny new toys

Posted: **Thu Mar 22, 2018 7:18 am**

Here's a release of the initial software version of the DGTonemap filter. The distribution includes a help file with full instructions and a sample script. Your testing and suggestions will be appreciated. This is the starting point for everything.

http://rationalqm.us/DGTonemap.rar

I thought the COPYING file from zimg was funny. ??? is a four-letter expletive beginning with the letter F. Here it is:

Code: Select all

            DO WHAT THE ??? YOU WANT TO PUBLIC LICENSE
                    Version 2, December 2004

 Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>

 Everyone is permitted to copy and distribute verbatim or modified
 copies of this license document, and changing it is allowed as long
 as the name is changed.

            DO WHAT THE ??? YOU WANT TO PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  0. You just DO WHAT THE ??? YOU WANT TO.

Posted: **Thu Mar 22, 2018 8:41 am**

Thank you.

loadplugin("dgdecodenv.dll")
loadplugin("DGTonemap.dll")
loadplugin("avsresize.dll")
SetFilterMTMode("z_ConvertFormat", MT_MULTI_INSTANCE) # May not be needed.
dgsource("THE GREAT WALL.dgi",fulldepth=true)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
dgtonemap(white=0.7)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(2)

I know we ought not mention the vs word a lot ... but is there a vapoursynth equivalent script (eg I have never seen nor used "avsresize" before ... and I no longer have avisynth installed) ?

Posted: **Thu Mar 22, 2018 11:26 am**

I have no problem with the VS word or discussing it.

It's not simple because Avisynth doesn't know RGBS and Vapoursynth doesn't know RGBPS. I am working on making a dual Vapoursynth/Avisynth version of both DGDecodeNV and DGTonemap. May be a while.

The reason for this partial step was to get some kind of HDR->SDR for Avisynth.

Posted: **Thu Mar 22, 2018 5:50 pm**

I thought the COPYING file from zimg was funny. ??? is a four-letter expletive beginning with the letter F. Here it is:

"Fudge" is actually 5 letters

Speed
Prefetch(2) gives me really low speeds, maybe in neighborhood pf 17 FPS
Prefetch(8) gives me in the neighborhood of about 47 FPS
but this is a hardware specific item, user must find his own sweet spot
Note... Prefetch(12) is actually slightly faster but it appears to be hitting the point of diminishing returns, 1 FPS faster at a cost of 30% more CPU usage
I realize, unless I am wrong (known to happen quite a lot), that is an intermediate step until porting to CUDA

Now, the good stuff
The image is great, color appears to be spot on or very, very close.
It is a dash bright, but on this sample it actually looks better than the original sdr sample
When I get a chance I will run bigger samples so a more complete picture can be obeserved, if so desired

Looking awesome :bow:

Before I forget
hdr to sdr

sdr

Posted: **Thu Mar 22, 2018 5:58 pm**

Thanks, gonca. Your fps values are what? Playing in VirtualDub2? I don't get how you can have 47fps when I get only 21fps.

Posted: **Thu Mar 22, 2018 5:59 pm**

Apoogies, that is encoding speed with NVEncC

Posted: **Thu Mar 22, 2018 6:04 pm**

Ah, OK. Thanks for the clarification. I will try with AVSMeter64 right now just for fun.

EDIT: AVSMeter64 30fps at prefetch(8). Can you try that?

Posted: **Thu Mar 22, 2018 6:12 pm**

The script with prefetch(8) plays in real-time (23.976) in MPC-HC x64 (delivering YV12). So I guess VirtualDub2 has lots of display overhead.

Posted: **Thu Mar 22, 2018 6:19 pm**

I get 54.33 FPS

Frames processed: 1449 (0 - 1448)
FPS (min | max | average): 14.12 | 198.0 | 54.33
Memory usage (phys | virt): 2365 | 3100 MiB
Thread count: 35
CPU usage (average): 50%

Time (elapsed): 00:00:26.671

[Script]
LoadPlugin("C:\Program Files (Portable)\dgdecnv\x64 Binaries\DGDecodeNV.dll")
LoadPlugin("C:\Program Files (Portable)\AVS Templates\DGTonemap\x64\DGTonemap.dll")
LoadPlugin("C:\Program Files (Portable)\AVS Templates\avsresize\x64\Release\avsresize.dll")
SetFilterMTMode("z_ConvertFormat", MT_MULTI_INSTANCE) # May not be needed.
DGSource("D:\#test\#hdr\THE GREAT WALL.dgi", fieldop=0, fulldepth=True)
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")
dgtonemap(white=0.7)
z_ConvertFormat(pixel_type="YV12",colorspace_op="rgb:linear:2020:l=>709:709:709:l",dither_type="ordered")
prefetch(8)

My point with NVEncC is that on the fly transcoding for streaming can be done

Support forum for DG Tools

HDR -> SDR conversion

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV

Re: HDR -> SDR tonemapping for DGDecodeNV