HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

I never saw it, just got a sample from :scratch:
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

Both of your screenshots come out as 8 bit, so HDR data not coming thru?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

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
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

Cool, I'll definitely take you up on that when things are out of the oven.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest 2 »

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 ;)
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
User avatar
hydra3333
Posts: 394
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by hydra3333 »

admin wrote:
Sun Mar 18, 2018 8:33 am
Before (converted without tonemapping) and after (with tonemapping) screenshots follow.
Nice.
I really do like it here.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

But the images I replaced them with
They look good,great improvement with your new approach :D
DAE avatar
Guest 2
Posts: 903
Joined: Mon Sep 20, 2010 2:18 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest 2 »

:bravo:
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.
DAE avatar
sparktank
Posts: 64
Joined: Thu Mar 28, 2013 5:24 pm
Location: Gotham City

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by sparktank »

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.
Nvidia GeForce GT 1030 | GPU Caps Viewer
Windows 10 Annversary (x64) | ASVPlus_x64
Region A/R1
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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. :lol:
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

Shiny new toys, never a waste
Besides, if I leave it behind someone else will just waste it on different shiny new toys
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
User avatar
hydra3333
Posts: 394
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by hydra3333 »

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) ?
I really do like it here.
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

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: :bravo: :D

Before I forget
hdr to sdr
Image
sdr
Image
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

Apoogies, that is encoding speed with NVEncC
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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?
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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.
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

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
Post Reply