HDR -> SDR conversion
Re: HDR -> SDR tonemapping for DGDecodeNV
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
Thanks for the info.
Re: HDR -> SDR tonemapping for DGDecodeNV
If you don't have a preference for ISO backup over folder structure, your best bet is MakeMKV
Re: HDR -> SDR tonemapping for DGDecodeNV
Gotta get a usable drive first. Which one do you have, gonca?
Re: HDR -> SDR tonemapping for DGDecodeNV
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
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?
Re: HDR -> SDR tonemapping for DGDecodeNV
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
OK, thanks.
Re: HDR -> SDR tonemapping for DGDecodeNV
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...?
@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...?
Re: HDR -> SDR tonemapping for DGDecodeNV
Don't need to trim
I'll just demux the video and patch the stream with the wrong data
I'll just demux the video and patch the stream with the wrong data
Re: HDR -> SDR tonemapping for DGDecodeNV
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
Changed the meta data and got a green screen
messed up colors
original colors
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
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
Re: HDR -> SDR tonemapping for DGDecodeNV
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...
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...
Re: HDR -> SDR tonemapping for DGDecodeNV
Ok, got a very interesting answer and information about HDR. I had no idea it was in a such mess state...
Seeing this, i gave up the idea of trying to do an HDR to SDR convertion.
Seeing this, i gave up the idea of trying to do an HDR to SDR convertion.
Re: HDR -> SDR tonemapping for DGDecodeNV
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)
Re: HDR -> SDR tonemapping for DGDecodeNV
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
Mind you, I am not that experienced with what you are trying to accomplish
Maybe others can help out more
This is a good starting pointHere is the ugliness (although the resultingwith the Reinhard tonemapping):Code: Select all
video looks great
Re: HDR -> SDR tonemapping for DGDecodeNV
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.
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.
Re: HDR -> SDR tonemapping for DGDecodeNV
I have it working in RGBP16 so the script now looks like this:
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.
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
Re: HDR -> SDR tonemapping for DGDecodeNV
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).
Re: HDR -> SDR tonemapping for DGDecodeNV
Edit
I liked that movie
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.