HDR -> SDR conversion
Re: HDR -> SDR tonemapping for DGDecodeNV
I never saw it, just got a sample from
Re: HDR -> SDR tonemapping for DGDecodeNV
Both of your screenshots come out as 8 bit, so HDR data not coming thru?
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
Cool, I'll definitely take you up on that when things are out of the oven.
Re: HDR -> SDR tonemapping for DGDecodeNV
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:
Note to gonca, don't try to run this as it needs a new dgtonemap.dll.
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)
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
As Guest 2 suggests, it's time to port zimg to CUDA. It's not about Vapoursynth versus Avisynth+: CUDASynth.
Re: HDR -> SDR tonemapping for DGDecodeNV
They look good,great improvement with your new approachBut the images I replaced them with
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
The most intensive testing I've seen so far.
I should really upgrade my graphics card.
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
Shiny new toys, never a waste
Besides, if I leave it behind someone else will just waste it on different shiny new toys
Besides, if I leave it behind someone else will just waste it on different shiny new toys
Re: HDR -> SDR tonemapping for DGDecodeNV
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:
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
Thank you.
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) ?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 really do like it here.
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
"Fudge" is actually 5 lettersI thought the COPYING file from zimg was funny. ??? is a four-letter expletive beginning with the letter F. Here it is:
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
Before I forget
hdr to sdr
sdr
Re: HDR -> SDR tonemapping for DGDecodeNV
Thanks, gonca. Your fps values are what? Playing in VirtualDub2? I don't get how you can have 47fps when I get only 21fps.
Re: HDR -> SDR tonemapping for DGDecodeNV
Apoogies, that is encoding speed with NVEncC
Re: HDR -> SDR tonemapping for DGDecodeNV
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?
EDIT: AVSMeter64 30fps at prefetch(8). Can you try that?
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
I get 54.33 FPS
My point with NVEncC is that on the fly transcoding for streaming can be doneFrames 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)