HDR -> SDR conversion

These CUDA filters are packaged into DGDecodeNV, which is part of DGDecNV.
gonca
Moose Approved/Curly Approved
Posts: 907
Joined: Sun Apr 08, 2012 6:12 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Sun Mar 11, 2018 3:31 pm

Okay. I have the clips ready
original and messed up mastering display data (badly)
Interesting point, when you trim with MKVToolNix you lose the metadata, don't know if it affected the video.
Computer busy right now, will compare as soon as I can
Note
Changing from sdr>hdr>sdr resizes all open folders, just like changing resolution

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Sun Mar 11, 2018 4:26 pm

Changed the meta data and got a green screen
messed up colors

Code: Select all

Mastering display color primaries        : R: x=0.080000 y=0.020000, G: x=0.100000 y=0.700000, B: x=0.010000 y=0.010000, White point: x=0.012700 y=0.009000
Mastering display luminance              : min: 0.1000 cd/m2, max: 1.0000 cd/m2
Maximum Content Light Level              : 1000 cd/m2
Maximum Frame-Average Light Level        : 50 cd/m2
original colors

Code: Select all

Mastering display color primaries        : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance              : min: 0.0050 cd/m2, max: 4000.0000 cd/m2
Maximum Content Light Level              : 456 cd/m2
Maximum Frame-Average Light Level        : 151 cd/m2

jpsdr
Moose Approved
Posts: 182
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr » Sun Mar 11, 2018 5:20 pm

Thanks. Very interesting result, this experiment confirm my thoughts, that the display device needs these metadata to properly display HDR content. I'm still having trouble with what kolak said that device use high complex method algorith just to display HDR.
And for now, i can't get rid of the idea that HDR -> SDR could easely be done using these metadata, and that display device use simple direct formula, with these metadata, and not high complex algorithm involving the whole frame analysis.
But, stil unable to link these metadata with the informations in the REC.2100. Don't see where they fits in the formula... :scratch:

jpsdr
Moose Approved
Posts: 182
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr » Mon Mar 12, 2018 4:15 am

Ok, got a very interesting answer and information about HDR. I had no idea it was in a such mess state... :wow:
Seeing this, i gave up the idea of trying to do an HDR to SDR convertion.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sat Mar 17, 2018 9:55 am

It's ugly for now but I have at least a working process for HDR->SDR based on the existing Vapoursynth solution. It's ugly because of the color space conversions I had to do in Avisynth+ to be able to pass planar float RGB to my filter dgtonemap(). So, guys, help me out. It should be possible to at least combine the conversions down from 4 to 2 but for the life of me I cannot figure out what is actually possible in Avisynth+, due to the spotty documentation. Here is the ugliness (although the resulting video looks great with the Reinhard tonemapping):

Code: Select all

loadplugin("dgdecodenv.dll")
loadplugin("dgtonemap.dll")
dgsource("THE GREAT WALL.dgi",fulldepth=true)

# Converting YUV420P16 to planar float RGB.
converttoplanarrgb(matrix="rec709")
converttofloat(bits=32)

dgtonemap()

# Converting from planar float RGB to YV12,
converttoyv12()
convertbits(8) # Strange but if this is omitted, P016 is delivered!

prefetch(4)

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Sat Mar 17, 2018 10:47 am

I did some googling and found nothing for avs+
Mind you, I am not that experienced with what you are trying to accomplish
Maybe others can help out more
Here is the ugliness (although the resulting

Code: Select all

video looks great
with the Reinhard tonemapping):
This is a good starting point

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sat Mar 17, 2018 11:31 am

I'll talk to pinterf about it.

Working directly in RGBP16 may be possible.

Ideally, I would like the filter to accept YUV420P16 but return YV12P8. But the Avisynth framework does not seem to support this for external filters.

Got a lot of research to do on Avisynth+ capabilities, the actual tonemapping part is the easy part. :o

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sun Mar 18, 2018 8:10 am

I have it working in RGBP16 so the script now looks like this:

Code: Select all

dgsource("THE GREAT WALL.dgi",fulldepth=true)
converttoplanarrgb(matrix="rec709")
dgtonemap(white=0.25) # arbitrary units, don't try to make sense of it
converttoyv12()
convertbits(8) # include to deliver 8-bit, exclude for 16-bit
Now I'll move it to the GPU. Probably the conversions to/from RGB can be done there too, eliminating the conversions in the script.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sun Mar 18, 2018 8:33 am

Before (converted without tonemapping) and after (with tonemapping) screenshots follow. As I mentioned, now that the infrastructure is in place, the tonemapping algorithm can be experimented with to find what we like best. This is basic Reinhard global with no attempt to tweak the white point (I just chose one that seemed OK).

Image

Image

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Sun Mar 18, 2018 8:39 am

:hat:
Edit
I liked that movie

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sun Mar 18, 2018 8:45 am

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

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Sun Mar 18, 2018 10:14 am

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

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » 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.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » 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

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Sun Mar 18, 2018 10:52 am

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

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » 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.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by tormento » 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 ;)

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » 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.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by hydra3333 » 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.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » 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.

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » Tue Mar 20, 2018 1:06 pm

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

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by gonca » Tue Mar 20, 2018 3:25 pm

But the images I replaced them with
They look good,great improvement with your new approach :D

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by tormento » Wed Mar 21, 2018 7:34 am

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

sparktank
Moose Approved
Posts: 64
Joined: Thu Mar 28, 2013 5:24 pm
Location: Gotham City

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by sparktank » 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.
Nvidia GeForce GT 1030 | GPU Caps Viewer
Windows 10 Annversary (x64) | ASVPlus_x64
Region A/R1

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin » 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. :lol:

Post Reply