HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
dennis
Moose Approved
Posts: 35
Joined: Mon Mar 26, 2018 6:00 am

Re: HDR -> SDR conversion

Post by dennis » Wed Oct 17, 2018 1:43 pm

@admin
HDR2SDR I don't know that plugin.
Sorry, I meant DGHDRtoSDR.dll v.DGHDRtoSDR_1.10.rar
As to
@dennis
Are you going to ignore my request for your source file, etc.?
I'm missing something.
Nevertheless, my source is Gladiator 2000 Extended 2160p UHD BluRay REMUX HDR HEVC DTS-X-EPSiLON.
Do you want a 10/20 sec cut from it or what?

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Wed Oct 17, 2018 1:59 pm

Please give me the cut that you made, you know, the one you say has 240 frames but for which DGSource() says 236.

You say DGHDRtoSDR is not working properly, so please give me the source file (if different from the one above), and the exact Avisynth script that you used. I expect the issue is related to your other tools and process, as DGHDRtoSDR cannot create non-existing frames. It simply returns frames requested by the application that is processing the Avisynth script.

dennis
Moose Approved
Posts: 35
Joined: Mon Mar 26, 2018 6:00 am

Re: HDR -> SDR conversion

Post by dennis » Wed Oct 17, 2018 3:45 pm

As to the
DGHDRtoSDR plugin doesn't work properly
I found some ambiguities, at least for me and I had a successful run with this plugin.
Here is a brief summary from the run.

Code: Select all

>avs2yuv64 -depth 10 -raw DGHDRtoSDR.avs - | x265-64bit-8bit-2018-10-08 - --input-depth 8 --input-res 1920x1080 --input-csp "i420" ... color1.hevc
yuv  [info]: 1920x1080 fps 24000/1001 i420p8 unknown frame count
raw  [info]: output file: color1.hevc
x265 [info]: HEVC encoder version 2.8+74-fd517ae68f93
...
x265 [info]: tools: deblock sao
avisynth 16-bit hack enabled
DGHDRtoSDR.avs: 960x1080, YV12, 10-bits, progressive, 24000/1001 fps, 236 frames
x265 [info]:...
...
encoded 236 frames in 287.14s (0.82 fps), 57349.70 kb/s, Avg QP:16.25

Code: Select all

DGHDRtoSDR.avs
loadplugin("C:\Programs\AviSynth+\plugins64+\dgdecodenv.dll")
loadplugin("C:\Programs\AviSynth+\plugins64+\dghdrtosdr.dll")
DGSource("F:\Gladiator.copy\Gladiator10sec.dgi",fulldepth=true)
DGHDRtoSDR()
ConvertBits(8)
Spline36Resize(1920,1080)
prefetch(6)
Here is a link to Google drive where I've uploaded my test source - Gladiator10sec.hevc
https://drive.google.com/drive/folders/ ... p=sharing
Didn't see download option though. Maybe, it is a default.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Wed Oct 17, 2018 4:13 pm

Thank you for the source file. The index file sees 238 frame starts but playing the script in Vdub2 delivers only 237 (0-236). That is likely due to the way you have cut the file, i.e., not a clean cut at the end. So I don't see any problem. I won't speculate on what your avs2yuv64 and 16-bit hack stuff may be doing, and I do not provide support for them.

You haven't shown any issue with DGHDRtoSDR. Your ConvertBits(8) call is not needed as DGHDRtoSDR delivers 8-bit by default. Also, if you resize in DGSource() it will run much faster. Or resize your way but before the DGHDRtoSDR call.

Bottom line: no problems found.

User avatar
hydra3333
Moose Approved
Posts: 206
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: HDR -> SDR conversion

Post by hydra3333 » Thu Oct 18, 2018 12:59 am

hydra3333 wrote:
Fri Oct 05, 2018 7:38 pm
Just a note about the .rar file not opening in 7zip commandline,

Per http://forum.???.org/showthread.php?p=1 ... ost1853939 when I try to manually use standalone z7ip to even list the rar file, it fails.

Would it be possible to consider using .zip or something ?
admin wrote:
Fri Oct 05, 2018 8:30 pm
I'll look into it tomorrow. Thanks for pointing it out. I used to always use ZIP but then I saw lots of people using RAR.
Hello again.
Per this issue with vsrepo crashing https://github.com/vapoursynth/vsrepo/i ... -430883357 when looking for DGHDRtoSDR
  • would it be possible to consider using .zip or something ? :)
  • would it be possible to keep older versions of stuff online for a month or so to provide buffer time for vsrepo to catch up (I haven't looked into vsrepo's mechanism for keeping up to date with new versions, will do so shortly).
  • If a product is non-licensed, maybe could github and tagged releases be a possible alternative, since vsrepo seems to use those OK ?

dennis
Moose Approved
Posts: 35
Joined: Mon Mar 26, 2018 6:00 am

Re: HDR -> SDR conversion

Post by dennis » Thu Oct 18, 2018 2:43 am

admin wrote:
Wed Oct 17, 2018 4:13 pm
Thank you for the source file. The index file sees 238 frame starts but playing the script in Vdub2 delivers only 237 (0-236). That is likely due to the way you have cut the file, i.e., not a clean cut at the end. So I don't see any problem. I won't speculate on what your avs2yuv64 and 16-bit hack stuff may be doing, and I do not provide support for them.

You haven't shown any issue with DGHDRtoSDR. Your ConvertBits(8) call is not needed as DGHDRtoSDR delivers 8-bit by default. Also, if you resize in DGSource() it will run much faster. Or resize your way but before the DGHDRtoSDR call.

Bottom line: no problems found.
Thank you very much for your help.
I would like to point out the John Hable's post at http://filmicworlds.com/blog/filmic-ton ... er-curves/.
His approach is to give more and easy control over the Filmic Tonemapping curves.
He says:
There are several specific issues I’m hoping to address from the Uncharted 2 curve:
(implemented in Hable tonemap operator)
Simple intuitive controls:
Direct control over dynamic range:
Well behaved curves:
Controls in engine:
Fast, closed form: The curve should be simple and fast to evaluate.
Lerpable parameters:Simple inverse:
Convolve with output gamma:
Code on Github: Makes integration simple.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Thu Oct 18, 2018 9:37 am

Anyone working on HDR to SDR already is familiar with the Hable stuff. It's all subjective, and personally I have no interest in a "filmic look" or "crisper blacks".

Dion
Posts: 23
Joined: Sun Dec 04, 2016 1:30 am

Re: HDR -> SDR conversion

Post by Dion » Sat Oct 20, 2018 5:41 pm

Question about this new setting..
hue=10.0 Hue adjustment used to correct hue shift due to the gamut mapping.
Values above 0.0 shift toward red. Values below 0.0 shift toward green. The
default value is 10.0.
Shouldn't it default to 0? Just wondering this change is all.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Sat Oct 20, 2018 7:22 pm

The gamut mapping was creating a small noticable green bias for some streams; the default hue setting corrects for that. You can set it to 0 if you prefer.

Dion
Posts: 23
Joined: Sun Dec 04, 2016 1:30 am

Re: HDR -> SDR conversion

Post by Dion » Sat Oct 20, 2018 9:20 pm

admin wrote:
Sat Oct 20, 2018 7:22 pm
The gamut mapping was creating a small noticable green bias for some streams; the default hue setting corrects for that. You can set it to 0 if you prefer.
Alright. Yes I do prefer zero.

Seems like the versions before 1.11 has "0" as the default even tho there is no hue option.. Just have to remember to add the hue line to scripts now. :D

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Sun Oct 21, 2018 8:45 am

Maybe 10 is a bit too strong. I'll reduce it in the next version.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Sun Oct 21, 2018 11:06 am

I slipstreamed 1.11 to reduce default hue to 5. Hopefully, you can live with that. I do think this hue correction is a good thing. If you can show otherwise, please do.

sv503
Posts: 1
Joined: Thu Jan 31, 2019 2:34 am

Re: HDR -> SDR conversion

Post by sv503 » Thu Jan 31, 2019 6:53 am

Hi, Donald!
Please give recommendations, how to select the parameter "Prefetch"? What does this parameter affect? Thank's.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Thu Jan 31, 2019 11:21 am

It's an Avisynth+ thing that you can google. There are so many variables affecting it that your best bet is to use Avsmeter to time your script and empirically determine the best value. For some scripts, any prefetch reduces performance.

Keyser78
Posts: 8
Joined: Thu Feb 07, 2019 2:33 am

Re: HDR -> SDR conversion

Post by Keyser78 » Thu Feb 07, 2019 2:41 am

Hello :-) Which version of Dgsource (dgdecnv) has parameter "fulldepth"? I use 2053, checked others :-( There's no in manual either.

gonca
Moose Approved/Curly Approved
Posts: 911
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR conversion

Post by gonca » Thu Feb 07, 2019 5:48 am

All versions of DGDecodeNV, for the last great while at least, have the fulldepth instruction
From the manual
fulldepth: true/false (default: false)

When fulldepth=true and the encoded video is HEVC 10-bit or 12-bit, then DGSource() delivers 16-bit data to Avisynth with the unused lower bits zeroed. The reported pixel format is CS_YUV420P16. If either of the two conditions are not met, then DGSource() delivers 8-bit YV12 or I420 data, as determined by the i420 parameter. When fulldepth=false and the video is HEVC 10-bit or 12-bit, then the video is dithered down to 8-bit for delivery. If you need a reduced color space (less than 16 bits) for your high-bit-depth processing, you can use ConvertBits() as needed after your DGSource() call.

Keyser78
Posts: 8
Joined: Thu Feb 07, 2019 2:33 am

Re: HDR -> SDR conversion

Post by Keyser78 » Thu Feb 07, 2019 7:57 am

I try to use it in Avspmod 2.5.1 and get a script error: dgsource does not have a named argument "fulldepth". :-(

User avatar
DJATOM
Moose Approved
Posts: 72
Joined: Fri Oct 16, 2015 6:14 pm

Re: HDR -> SDR conversion

Post by DJATOM » Thu Feb 07, 2019 8:04 am

Your version is too old, update dgdecodenv.dll.
RTX 2070 | Ryzen R9 3900X (no OC) | 64 GB RAM

Keyser78
Posts: 8
Joined: Thu Feb 07, 2019 2:33 am

Re: HDR -> SDR conversion

Post by Keyser78 » Thu Feb 07, 2019 8:50 am

Thanks! I've been using first 2053 version :facepalm: Now it works great.

Dion
Posts: 23
Joined: Sun Dec 04, 2016 1:30 am

Re: HDR -> SDR conversion

Post by Dion » Mon Jun 17, 2019 3:42 pm

Dion wrote:
Thu Sep 13, 2018 1:00 am
Have you ever considered making an HDR to SDR app for the Nvidia Shield? It has an Nvidia GPU in it and one thing it lacks is an HDR to SDR app that can hook onto Plex or Kodi or some other popular video apps.

Could even charge for it an probably make some decent bank. :D
https://nvidianews.nvidia.com/news/nvid ... rcomputing

Maybe useful for this? I'm not a dev so maybe you could comment.

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Mon Jun 17, 2019 8:32 pm

Thanks for the suggestions, guys. I need to make a DGHDRtoSDR() update and then I can look at this stuff.

Do you feel GOOOD? Say YEAH! Wheee.

User avatar
zys4416
Posts: 9
Joined: Fri Jul 29, 2011 9:04 pm

Re: HDR -> SDR conversion

Post by zys4416 » Fri Aug 30, 2019 3:17 am

great filter!
i'm very looking forward to the HLG2SDR function.

User avatar
tormento
Moose Approved
Posts: 341
Joined: Mon Sep 20, 2010 2:18 pm

Re: HDR -> SDR conversion

Post by tormento » Fri Aug 30, 2019 5:19 am

admin wrote:
Mon Jun 17, 2019 8:32 pm
Do you feel GOOOD? Say YEAH! Wheee.
YEAH! :lol:

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Fri Aug 30, 2019 8:21 am

zys4416 wrote:
Fri Aug 30, 2019 3:17 am
i'm very looking forward to the HLG2SDR function.
I didn't make one because of the supposed backwards compatibility of HLG. Can you further justify your request?

User avatar
admin
Site Admin
Posts: 4415
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR conversion

Post by admin » Fri Aug 30, 2019 8:23 am

tormento wrote:
Fri Aug 30, 2019 5:19 am
YEAH! :lol:
Better late than never!

Post Reply