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 »

Thanks, will check them out today.
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

hydra3333
Until they are checked by a more knowledgeable person, try De-interlacing and check for repeat frames
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

For the UHD HDR file, the timecodes show that the frame rate varies only insignificantly around 29.97. That is, "VFR in name only".

Most likely you can treat it as CFR, i.e., just demux audio and video and remux them as CFR. Or process with Avisynth/Vapoursynth as if it is CFR. Test it on a longer stream watching audio sync throughout.

I seriously doubt a phone would create true VFR. VFR is used to combine segments with different frame rates, like film (23.976) and video (29.97), i.e., for hybrid video. This video is obviously not hybrid.

Here are the timecodes with the differences to the previous ones in [ ]. Apart from the very first, the codes vary only a little around 29.97 fps. FPS 29.97 would give a difference of ~33.4.

0 [0]
44.4 [44.4]
77.7222222222222 [33.7222222222222]
111.033333333333 [34.0333333333333]
144.322222222222 [33.3222222222222]
177.611111111111 [33.6111111111111]
210.922222222222 [33.9222222222222]
244.2 [34.2]
277.5 [33.5]
310.811111111111 [33.8111111111111]
344.111111111111 [34.1111111111111]
377.422222222222 [33.4222222222222]
410.722222222222 [33.7222222222222]
444.044444444444 [34.0444444444445]
477.344444444444 [33.3444444444444]
510.644444444444 [33.6444444444444]
543.955555555556 [33.9555555555555]
577.266666666667 [34.2666666666667]
610.566666666667 [33.5666666666667]
643.877777777778 [33.8777777777777]
677.177777777778 [34.1777777777778]
710.488888888889 [33.4888888888888]
743.8 [33.8000000000001]
777.1 [34.1]
810.422222222222 [33.4222222222222]
843.711111111111 [33.7111111111111]
877.022222222222 [34.0222222222222]
910.311111111111 [33.311111111111]
943.611111111111 [33.6111111111111]
976.922222222222 [33.9222222222222]
1010.23333333333 [34.2333333333333]
1043.54444444444 [33.5444444444445]
1076.85555555556 [33.8555555555554]
1110.15555555556 [34.1555555555556]
1143.46666666667 [33.4666666666667]
1176.77777777778 [33.7777777777776]
1210.07777777778 [34.0777777777778]
1243.37777777778 [33.3777777777777]
1276.68888888889 [33.6888888888891]
1310.02222222222 [34.0222222222221]
1343.31111111111 [33.3111111111111]
1376.63333333333 [33.6333333333334]
1409.92222222222 [33.9222222222222]
1443.22222222222 [34.2222222222222]
1476.53333333333 [33.5333333333333]
1509.84444444444 [33.8444444444444]
1543.14444444444 [34.1444444444444]
1576.44444444444 [33.4444444444446]
1609.75555555556 [33.7555555555557]
1643.06666666667 [34.0666666666666]
1676.37777777778 [33.3777777777777]
1709.68888888889 [33.6888888888889]
1743 [34]
1776.28888888889 [33.2888888888888]
1809.6 [33.6000000000001]
1842.91111111111 [33.9111111111113]
1876.21111111111 [34.211111111111]
1909.52222222222 [33.5222222222221]
1942.83333333333 [33.8333333333335]
1976.12222222222 [34.122222222222]
2009.43333333333 [33.4333333333334]
2042.75555555556 [33.7555555555555]
2076.06666666667 [34.0666666666666]
2109.35555555556 [33.3555555555558]
2142.66666666667 [33.6666666666665]
2175.96666666667 [33.9666666666667]
2209.27777777778 [34.2777777777778]
2242.58888888889 [33.588888888889]
2275.87777777778 [33.8777777777777]
2309.2 [34.2000000000003]
2342.5 [33.5]
2375.81111111111 [33.8111111111111]
2409.12222222222 [34.1222222222223]
2442.43333333333 [33.4333333333334]
2475.73333333333 [33.7333333333331]
2509.04444444444 [34.0444444444447]
2542.33333333333 [33.333333333333]
2575.66666666667 [33.666666666667]
2608.96666666667 [33.9666666666667]
2642.25555555556 [34.2555555555555]
2675.55555555556 [33.5555555555557]
2708.88888888889 [33.8888888888887]
2742.17777777778 [34.1777777777775]
2775.47777777778 [33.4777777777776]
2808.8 [33.8000000000002]
2842.08888888889 [34.088888888889]
2875.4 [33.4000000000001]
2908.72222222222 [33.7222222222226]
2942.02222222222 [34.0222222222219]
2975.33333333333 [33.3333333333335]
3008.62222222222 [33.6222222222223]
3041.94444444444 [33.9444444444443]
3075.23333333333 [34.2333333333331]
3108.55555555556 [33.5555555555557]
3141.85555555556 [33.8555555555554]
3175.15555555556 [34.1555555555556]
3208.47777777778 [33.4777777777781]
3241.78888888889 [33.7888888888888]
3275.07777777778 [34.0777777777776]
3308.37777777778 [33.3777777777777]
3341.73333333333 [33.7333333333336]
3375.06666666667 [34.0666666666666]
3408.3 [33.3000000000002]
3441.64444444444 [33.6444444444446]
3474.93333333333 [33.9333333333334]
3508.24444444444 [34.2444444444441]
3541.53333333333 [33.5333333333333]
3574.84444444444 [33.8444444444444]
3608.15555555556 [34.1555555555551]
3641.44444444444 [33.4444444444443]
3674.75555555556 [33.7555555555555]
3708.06666666667 [34.0666666666671]
3741.36666666667 [33.3666666666663]
3774.67777777778 [33.6777777777779]
3807.98888888889 [33.9888888888891]
3841.3 [34.2999999999997]
3874.58888888889 [33.588888888889]
3907.9 [33.9000000000001]
3941.21111111111 [34.2111111111112]
3974.53333333333 [33.5333333333333]
4007.83333333333 [33.833333333333]
4041.15555555556 [34.1555555555551]
4074.43333333333 [33.4333333333334]
4107.74444444444 [33.7444444444445]
4141.05555555556 [34.0555555555557]
4174.36666666667 [33.3666666666668]
4207.65555555556 [33.6555555555551]
4240.97777777778 [33.9777777777781]
4274.27777777778 [34.2777777777783]
4307.58888888889 [33.5888888888885]
4340.88888888889 [33.8888888888896]
4374.22222222222 [34.2222222222226]
4407.53333333333 [33.5333333333328]
4440.83333333333 [33.833333333333]
4474.14444444445 [34.1444444444451]
4507.44444444444 [33.4444444444443]
4540.76666666667 [33.7666666666664]
4574.07777777778 [34.0777777777785]
4607.37777777778 [33.3777777777777]
4640.67777777778 [33.677777777777]
4673.98888888889 [33.9888888888891]
4707.28888888889 [34.2888888888892]
4740.6 [33.5999999999995]
4773.9 [33.9000000000005]
4807.21111111111 [34.2111111111108]
4840.51111111111 [33.5111111111109]
4873.83333333333 [33.8333333333339]
4907.12222222222 [34.1222222222223]
4940.43333333333 [33.4333333333334]
4973.75555555556 [33.7555555555555]
5007.05555555556 [34.0555555555557]
5040.35555555555 [33.3555555555549]
5073.66666666667 [33.666666666667]
5107.02222222222 [34.0222222222228]
5140.26666666667 [33.2666666666664]
5173.57777777778 [33.5777777777785]
5206.92222222222 [33.9222222222224]
5240.18888888889 [34.1888888888889]
5273.5 [33.5]
5306.81111111111 [33.8111111111111]
5340.11111111111 [34.1111111111104]
5373.42222222222 [33.4222222222224]
5406.73333333333 [33.7333333333336]
5440.03333333333 [34.0333333333328]
5473.34444444444 [33.3444444444449]
5506.66666666667 [33.666666666667]
5539.94444444444 [33.9444444444443]
5573.25555555556 [34.2555555555555]
5606.58888888889 [33.5888888888894]
5639.86666666667 [33.8666666666668]
5673.17777777778 [34.1777777777779]
5706.54444444444 [33.5444444444447]
5739.78888888889 [33.7888888888883]
5773.11111111111 [34.1111111111113]
5806.41111111111 [33.4111111111115]
5839.72222222222 [33.7222222222217]
5873.02222222222 [34.0222222222228]
5906.34444444444 [33.3444444444449]
5939.63333333333 [33.6333333333332]
5972.93333333333 [33.9333333333334]
6006.23333333333 [34.2333333333336]
6039.56666666667 [33.5666666666666]
6072.85555555556 [33.8555555555558]
6106.17777777778 [34.1777777777779]
6139.46666666667 [33.4666666666662]
6172.78888888889 [33.7888888888892]
6206.08888888889 [34.0888888888894]
6239.43333333333 [33.4333333333334]
6272.72222222222 [33.7222222222217]
6306.02222222222 [34.0222222222228]
6339.31111111111 [33.3111111111111]
6372.61111111111 [33.6111111111113]
6405.93333333333 [33.9333333333334]
6439.23333333333 [34.2333333333336]
6472.53333333333 [33.5333333333338]
6505.85555555556 [33.8555555555558]
6539.14444444444 [34.1444444444442]
6572.45555555556 [33.4555555555562]
6605.76666666667 [33.7666666666664]
6639.06666666667 [34.0666666666666]
6672.37777777778 [33.3777777777777]
6705.7 [33.6999999999998]
6739.01111111111 [34.0111111111109]
6772.28888888889 [33.2888888888892]
6805.61111111111 [33.6111111111113]
6838.92222222222 [33.9222222222224]
User avatar
hydra3333
Posts: 394
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by hydra3333 »

OK, thanks, I'll try that.

I uploaded another clip "05" where the minimum VFR frame rate is reportedly down to 16.
Would that "assume CFR" approach still be doable with clips like that ?

Code: Select all

Bit rate                                 : 17007029
Bit rate                                 : 17.0 Mb/s
Width                                    : 1920
Width                                    : 1 920 pixels
Height                                   : 1080
Height                                   : 1 080 pixels
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixel aspect ratio                       : 1.000
Display aspect ratio                     : 1.778
Display aspect ratio                     : 16:9
Rotation                                 : 90.000
Rotation                                 : 90°
Frame rate mode                          : VFR
Frame rate mode                          : Variable
Frame rate                               : 30.000
Frame rate                               : 30.000 FPS
Minimum frame rate                       : 16.876
Minimum frame rate                       : 16.876 FPS
Maximum frame rate                       : 30.141
Maximum frame rate                       : 30.141 FPS
Frame count                              : 1118
Source frame count                       : 1119
I suppose ffmpeg -vsync 2 or even better -vsync drop would be OK using to convert to CFR.
-vsync parameter
Video sync method. For compatibility reasons old values can be specified as numbers. Newly added values will have to be specified as strings always.
0, passthrough
Each frame is passed with its timestamp from the demuxer to the muxer.
1, cfr
Frames will be duplicated and dropped to achieve exactly the requested constant frame rate.
2, vfr
Frames are passed through with their timestamp or dropped so as to prevent 2 frames from having the same timestamp.
drop
As passthrough but destroys all timestamps, making the muxer generate fresh timestamps based on frame-rate.
-1, auto
Chooses between 1 and 2 depending on muxer capabilities. This is the default method.
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:
Thu Mar 08, 2018 7:17 pm
I uploaded another clip "05" where the minimum VFR frame rate is reportedly down to 16.
I don't see this at the link you gave earlier.
User avatar
hydra3333
Posts: 394
Joined: Wed Oct 06, 2010 3:34 am
Contact:

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by hydra3333 »

Apology, my bad. It's there now (it was in a parent folder).
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 »

It's just the first frame again. After that everything is again close to 29.97.

Look, that camera is not shooting hybrid. It's never going to make real VFR. I don't know the reason for the first frame anomaly. Again, just treat it as CFR.
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 for your confirmation, that sounds like a good plan.
OK, ffmpeg's -vsync 1 -r 29.97 looks like the go to treat it as cfr, so timestamps are fixed up and audio remains in sync.
I really do like it here.
DAE avatar
jpsdr
Posts: 214
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr »

Going back to HDR... ;)
I've posted on another forum a long post, about my still struggling issues and thoughts i have about HDR.
If you have time to read it, and eventually share your thoughts also here.

It's of course absolutely not related to the fact that yesterday i got in my hand my first UHD Blu-Ray, and that i've been able to rip it on my HDD because i have a "friendly" drive... :mrgreen:
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

What are you using to rip the UHD disk?
DAE avatar
jpsdr
Posts: 214
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr »

Usualy, i use AnyDVD for all my BR. But, for this title, i've encounter an issue for the 1rst time, AnyDVD wanted to connect to its database. As my PC video is totaly offline, i had to found something else.
Finaly, makemkv did the job. I didn't create an mkv, but just save the disc. Didn't realize the 1rst time that i had to check the "Decrypt box" to have decrypted data. So, i have my UHD BR on HDD, and DGIndex was fine on it. I was lucky the key was allready in the key list of makemkv.
I also have a "friendly" drive, BH16NS55 FW1.02. It worked, but i think the brand new FW 1.03 fixes the loophole, as do the brand new FW for ASUS 16D1HT and 12D2HT drives.

Nevertheless, there still possibility to reverse FW/Do things, read the posts in the several threads here :
https://www.makemkv.com/forum2/viewforum.php?f=16

The first to read is here, the description of the loophole :
https://www.makemkv.com/forum2/viewtopi ... 16&t=16832
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

Thanks for the info.
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

If you don't have a preference for ISO backup over folder structure, your best bet is MakeMKV
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

Gotta get a usable drive first. Which one do you have, gonca?
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

wh16ns40
svc ns50
fw 1.02

https://club.myce.com/t/the-ultimate-ul ... t/399725/6
That is what it should look like
https://www.amazon.com/LG-WH16NS40-Inte ... s=wh16ns40
This looks right, however FW is the issue, 1.03 removes the capability to read UHD
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

So how do I buy one and be sure not to get 1.03 firmware? Can you downgrade it and if so where do you get it?
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

Brick and mortar store should allow you to inspect the drive before buying, look for the svc code and FW version on the label on the drive
https://club.myce.com/t/dosflash-v2-0-p ... ves/399911
Read here on how to downgrade or crossflash the FW, there are risks, the drive can be bricked I guess
The face plate is a good guide to svc ns50, the m-disc logo should be on the tray itself
User avatar
admin
Posts: 4551
Joined: Thu Sep 09, 2010 3:08 pm

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

OK, thanks.
DAE avatar
jpsdr
Posts: 214
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr »

Otherwise, drives appart, any comment on my post

@gonca
Is it possible for you to do a little experiment for me ?
In the first page of this thread, it seems that you're doing your own H265 HDR encode.
If possible, could you trim 20s of a video, and make 2 encodes of it :
- With the proper mastering informations.
- Changing some mastering informations, but nothing else.
Then, play both files on your system, and tell me if display results are different.
Unless... You've already done this by mistake, in your first encode attempts...?
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

Don't need to trim
I'll just demux the video and patch the stream with the wrong data
DAE avatar
Guest

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by Guest »

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
DAE avatar
jpsdr
Posts: 214
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr »

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:
DAE avatar
jpsdr
Posts: 214
Joined: Tue Sep 21, 2010 4:16 am

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by jpsdr »

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

Re: HDR -> SDR tonemapping for DGDecodeNV

Post by admin »

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