HDR -> SDR conversion
Re: HDR -> SDR tonemapping
Earlier I was a bit concerned about whether an external Avisynth+ filter could change the video format, e.g., from YUV420P16 to YV12. Then I realized that is exactly what z_ConvertFormat() does. So I tried it and it is actually quite easy. So I now have a filter that just converts YUV420P16 to YV12 by truncating the lower 8 bits and it works fine. Of course without proper gamut mapping and tone mapping it is washed out as expected. But this forms the basis for implementing the process I gave a few posts up. So, well on the way to nirvana!
Re: HDR -> SDR tonemapping
Good Avatar.admin wrote: ↑Tue Apr 24, 2018 7:37 amEarlier I was a bit concerned about whether an external Avisynth+ filter could change the video format, e.g., from YUV420P16 to YV12. Then I realized that is exactly what z_ConvertFormat() does. So I tried it and it is actually quite easy. So I now have a filter that just converts YUV420P16 to YV12 by truncating the lower 8 bits and it works fine. Of course without proper gamut mapping and tone mapping it is washed out as expected. But this forms the basis for implementing the process I gave a few posts up. So, well on the way to nirvana!
Re: HDR -> SDR tonemapping
I have coded the proposed algorithm in a C-code filter, eliminating the calls to z_ConvertFormat() in the script. It works quite well. Surprisingly, the speed is almost identical to the existing DGTonemap(). It's surprising because z_ConvertFormat() is assembler optimized. But apparently that's canceled out by the fact that the script uses two z_ConvertFormat() calls. The image quality is comparable to what we have from the existing DGTonemap script. I expect to see a large speedup when implementing it in CUDA. Keep your fingers crossed.
Re: HDR -> SDR tonemapping
I have tossed out Hable/Reinhard and rolled my own locally adaptive tonemapping operator. Below is an example. Note the lack of blowout in the clouds and retention of detail there. Also, detail is retained on the dark areas of the left-hand rider. Detail in the hills is brought out nicely. To me, it nicely conveys the 'wow' factor of the original HDR. It's computationally more intensive but I think it's worth it and CUDA should give acceptable frame rates.
Here is the process (all done in C code for now):
* Convert full-depth YUV to 32-bit float RGB.
* Normalize R, G, and B to [0.0,1.0].
* Linearize with ST.2084 EOTF.
* Map the gamut from 2020 to 709 using the inverse of REC.2087.
* Tonemap with locally adaptive algorithm.
* Compress to 709 gamma.
* Scale to 0-255 and convert to YV12.
Here is the process (all done in C code for now):
* Convert full-depth YUV to 32-bit float RGB.
* Normalize R, G, and B to [0.0,1.0].
* Linearize with ST.2084 EOTF.
* Map the gamut from 2020 to 709 using the inverse of REC.2087.
* Tonemap with locally adaptive algorithm.
* Compress to 709 gamma.
* Scale to 0-255 and convert to YV12.
Re: HDR -> SDR tonemapping
Amazing...
When do we get to try this ourselves
When do we get to try this ourselves
Re: HDR -> SDR tonemapping
Thanks. I have to port it to CUDA to make it practical. Patience!
Re: HDR -> SDR tonemapping
Looking very impressive
Re: HDR -> SDR tonemapping
Does porting to CUDA imply that it'll be integrated with DGSource and the indexing? Or still a standalone plugin?
Wondering as I can't currently use the indexing for HEVC
Thanks for the hard work
Wondering as I can't currently use the indexing for HEVC
Thanks for the hard work
Re: HDR -> SDR tonemapping
You're welcome.
It'll probably be a standalone filter requiring YUV420P16. The utility filters currently in DGDecodeNV.dll can be used independently of DGSource() and indexing, BTW, so even if I integrated it you could still use it. Why can't you currently use indexing for HEVC? No suitable nVidia card?
Re: HDR -> SDR tonemapping
Yep, and from past support emails from a while ago I couldn't get the 970 to work with DXVA + Win10 for HEVC.
That sounds good then
That sounds good then
Re: HDR -> SDR tonemapping
I have the initial port to CUDA completed with Reinhard tonemapping. It's running at 80 fps on HDR 3840x2160. Pretty good. Software mode runs at about 1 fps, so that's an 80x speedup.
I'll add the option for my local tonemapping and then give y'all a test version. I expect the frame rate to drop by about 25% but we'll see. I'll allow selection of the desired tonemapping operator.
I'll add the option for my local tonemapping and then give y'all a test version. I expect the frame rate to drop by about 25% but we'll see. I'll allow selection of the desired tonemapping operator.
Re: HDR -> SDR tonemapping
Can hardly wait, you are a busy one
Re: HDR -> SDR tonemapping
80x, wow.admin wrote: ↑Thu May 10, 2018 5:05 pmI have the initial port to CUDA completed with Reinhard tonemapping. It's running at 80 fps on HDR 3840x2160. Pretty good. Software mode runs at about 1 fps, so that's an 80x speedup.
I'll add the option for my local tonemapping and then give y'all a test version. I expect the frame rate to drop by about 25% but we'll see. I'll allow selection of the desired tonemapping operator.
local tonemapping ... copyrighted ?
Thank you ... again
I really do like it here.
Re: HDR -> SDR tonemapping
You're welcome. Actually, local tonemapping is a well-known thing, with several approaches having been tried. The challenge is to make it computationally feasible for video. I am using a histogram equalization approach.
I have a beta for y'all to try:
http://rationalqm.us/misc/DGHDRtoSDR_1.0.rar
Read the included text file DGHDRtoSDR_1.0.txt for usage instructions. Feedback will be gratefully received.
Some parts are not yet ported to CUDA. I am working on that and also improvements to the local tonemapping. I am getting ~80 fps (measured with AVSMeter64) with this version.
I have a beta for y'all to try:
http://rationalqm.us/misc/DGHDRtoSDR_1.0.rar
Read the included text file DGHDRtoSDR_1.0.txt for usage instructions. Feedback will be gratefully received.
Some parts are not yet ported to CUDA. I am working on that and also improvements to the local tonemapping. I am getting ~80 fps (measured with AVSMeter64) with this version.
Re: HDR -> SDR tonemapping
Thanks for your results. Try equal=15 or 20 to really bring out the details. I'm working on not amplifying noise in flat areas at those high levels of equalization.
I'm also curious to know your GPU, CPU, and attained frame rate.
I'm also curious to know your GPU, CPU, and attained frame rate.
Re: HDR -> SDR tonemapping
https://i.imgur.com/GJMK9wr.jpg
The flower looks distorted.
My script:
Upd: imgur used jpeg so it's not that visible on my first screenshot. Hope that one is better: https://i.imgur.com/hcihLxO.png
The flower looks distorted.
My script:
I've got near 14 fps with software decoder.LwLibAvVideoSource("G:\SOURCES\MARI_TO_MAJO_NO_HANA_UHD\BDMV\STREAM\00001.m2ts")
ConvertFromDoubleWidth(bits=10)
ConvertBits(16)
DGHDRtoSDR(impl="255",light=90,equal=2)
DeBicubicResizeMT(1920,1080)
Upd: imgur used jpeg so it's not that visible on my first screenshot. Hope that one is better: https://i.imgur.com/hcihLxO.png
PC: RTX 2070 | Ryzen R9 5950X (no OC) | 64 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Notebook: RTX 4060 | Ryzen R9 7945HX | 32 GB RAM
Re: HDR -> SDR tonemapping
Had a quick go at it, here's some comparisons
SDR
Hable
Reinhard
DGHDRtoSDR(impl="255",light=50,equal=10)
DGHDRtoSDR(impl="255",light=50,equal=5 )
Some other than default settings
DGHDRtoSDR(impl="255",light=100,equal=5)
DGHable(exposure=1.5, w=1.8)
Around 29 fps average for just the tonemapping at 3840x2160 with prefetch(2)
Ryzen 2700X, GTX 970
Script for speed test:
SDR
Hable
Reinhard
DGHDRtoSDR(impl="255",light=50,equal=10)
DGHDRtoSDR(impl="255",light=50,equal=5 )
Some other than default settings
DGHDRtoSDR(impl="255",light=100,equal=5)
DGHable(exposure=1.5, w=1.8)
Around 29 fps average for just the tonemapping at 3840x2160 with prefetch(2)
Ryzen 2700X, GTX 970
Script for speed test:
I think it does a great job at keeping detail, a bit messy in darker areas thoughFFVideoSource("source.mkv", colorspace="YUV420P16")
DGHDRtoSDR(impl="255",light=50,equal=5)
trim(30000,35000)
prefetch(2)
Re: HDR -> SDR tonemapping
Thanks for your testing.
Maybe I should put a CUDA resizer in there too as your scripted resize is losing you a lot of time.
Can you please give me a source sample that produces this? I can PM you an FTP if you need it.The flower looks distorted.
Maybe I should put a CUDA resizer in there too as your scripted resize is losing you a lot of time.
Re: HDR -> SDR tonemapping
Reinhard (equal=0)
DGHDRtoSDR(impl="255",light=50,equal=10)
From equal=0 to equal=10, it seems to affect everything in the frame. If you look at the bottom left, there's a lot of noise introduced because 'detail' is recovered from the dark. Maybe there could be a luma threshold.
Here's another example:
Reinhard (equal=0)
DGHDRtoSDR(impl="255",light=50,equal=10)
Re: HDR -> SDR tonemapping
Thank you so much for your work.
From my initial tests, I've experienced some heavy banding with the "equal" value being anything other than 0.
Screenshots:
From my initial tests, I've experienced some heavy banding with the "equal" value being anything other than 0.
Screenshots:
Re: HDR -> SDR tonemapping
Software mode 8.5 FPS
GPU mode 112 FPS
I'll post images later, I am getting a HTTP error when trying to attach
GPU mode 112 FPS
I'll post images later, I am getting a HTTP error when trying to attach