HDR -> SDR conversion
Re: HDR -> SDR tonemapping
Great to hear, douzi. Thanks for the update.
Re: HDR -> SDR tonemapping
I think light defaults for Gamma should be left like they are now, it all depends on the film tonemapped so it should be adjusted by the user.
Resized to 720p to take less space
default vs light=0.55
Resized to 720p to take less space
default vs light=0.55
Re: HDR -> SDR tonemapping
Hi,
I encountered some issue with highlights with DGHDRtoSDR.
Here's three-way comparison between DG(sw mode, hable) vs. MadVR (130nits, dumb mode, late gamut conversion) vs.VS Hable
The third one with Hable in vapoursynth is using the script here: https://forum.doom9.org/showthread.php? ... ost1832071
Same issue for "gamma" and "reinhard" too.
Here's a link to the sample (screenshots at frame #400):
https://mega.nz/#!O0sEDTKZ!f-2a2cJEcKpx ... fTn4YMlPao
I encountered some issue with highlights with DGHDRtoSDR.
Here's three-way comparison between DG(sw mode, hable) vs. MadVR (130nits, dumb mode, late gamut conversion) vs.VS Hable
The third one with Hable in vapoursynth is using the script here: https://forum.doom9.org/showthread.php? ... ost1832071
Same issue for "gamma" and "reinhard" too.
Here's a link to the sample (screenshots at frame #400):
https://mega.nz/#!O0sEDTKZ!f-2a2cJEcKpx ... fTn4YMlPao
Re: HDR -> SDR tonemapping
"I encountered some issue with highlights with DGHDRtoSDR."
Can you please tell me what the issue is specifically? Refer to specific areas of specific frames and say what you think is wrong with them. I'm not good at guessing games.
Can you please tell me what the issue is specifically? Refer to specific areas of specific frames and say what you think is wrong with them. I'm not good at guessing games.
Re: HDR -> SDR tonemapping
Sorry, forgot to point out its in the highlights, look at the lighting in the blue light bars, it looks very unnatural in your implementation while it is ok on source, MadVR and VS's hable tonemap.
The screenshots are taken from frame #400 in the sample clip.
The screenshots are taken from frame #400 in the sample clip.
Re: HDR -> SDR tonemapping
Thank you. Investigating...
Re: HDR -> SDR tonemapping
I hope everyone had a great Memorial Day.
The problem with douzi's stream is caused by my using a shortcut (for performance reasons) to avoid implementing the full EETF of ITU-R BT.2390. It works well for some streams but it's clear now that it does badly on some streams and I cannot avoid implementing the full EETF. It's going to take some time to implement.
As I mentioned, I'm learning a lot.
The problem with douzi's stream is caused by my using a shortcut (for performance reasons) to avoid implementing the full EETF of ITU-R BT.2390. It works well for some streams but it's clear now that it does badly on some streams and I cannot avoid implementing the full EETF. It's going to take some time to implement.
As I mentioned, I'm learning a lot.
Re: HDR -> SDR tonemapping
Status update: Hmm, well, implementing the EETF didn't make much difference and didn't fix douzi's stream! Digging deeper I found that it is the 2020->709 gamut mapping that is responsible. That is surprising to me as it is just the inverse of BT.2087 and is recommended in several papers I read. I'm going to dig way deeper into this but for now I will probably give you a version tomorrow that at least fixes douzi's stream. I have it working but don't expect it to be the final solution.
Still learning.
Still learning.
Re: HDR -> SDR tonemapping
Here is an interim fix for douzi's stream. A new gamut mapping option was added called gm. Read the user manual for details. This may not be the final solution as I am still researching gamut mapping methods. gm is a hand-rolled method that seems to perform reasonably.
This version may be ~5-10% faster when using gm="compress".
http://rationalqm.us/misc/DGHDRtoSDR_1.3.rar
Here is douzi's frame 400 with gm="compress":
This version may be ~5-10% faster when using gm="compress".
http://rationalqm.us/misc/DGHDRtoSDR_1.3.rar
Here is douzi's frame 400 with gm="compress":
Re: HDR -> SDR tonemapping
I'm not sure if it's of any use (since there's not much documentation about the code), but there's this plugin which does conversion from BT2020 (and others) to BT709, as well as linear HDR -> SDR
https://github.com/jpsdr/HDRTools
I've been able to get good results (other than the linear lighting) with this script:
Thanks for the update
https://github.com/jpsdr/HDRTools
I've been able to get good results (other than the linear lighting) with this script:
With example sample above:FFVideoSource("source.hevc", colorspace="YUV420P16")
ConvertYUVtoXYZ(Color=0,OutputMode=1, Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Rx=0.708,Ry=0.292,Wx=0.31271,Wy=0.32902) #BT2020 chromacity parameters
ConvertXYZ_HDRtoSDR(MinMastering=1, MaxMastering=1000,Coeff_X=20, Coeff_Y=20, Coeff_Z=20)
ConvertXYZtoYUV(Color=2, OutputMode=2, pColor=0)
z_ConvertFormat(pixel_type="YV12")
Thanks for the update
Re: HDR -> SDR tonemapping
You're welcome and thanks for pointing out HDRTools. I'll definitelt check it out. Looks like jpsdr has done some serious research on all this.
Don't forget that I'm going for speed and that way looks a bit sluggish.
BTW, don't you use DGSource()? If you have an nVidia card I'll give you a free license.
Don't forget that I'm going for speed and that way looks a bit sluggish.
BTW, don't you use DGSource()? If you have an nVidia card I'll give you a free license.
Re: HDR -> SDR tonemapping
Yes, it is slow. I'm just mentioning it because the conversions seem accurate.
Re: HDR -> SDR tonemapping
Yes, I'm interested to see what he is doing for gamut mapping. Going through XYZ space is interesting but can be slow.
I'm probably going to open source my plugin code too at some point.
Check the last line in my previous post.
I'm probably going to open source my plugin code too at some point.
Check the last line in my previous post.
Re: HDR -> SDR tonemapping
I have a license already, I just can't use it for HEVC
Re: HDR -> SDR tonemapping
Ah, wrong card!
Timings for prefetch=6 on my i7-7700K + 1080 Ti:
HDRTools: 15.25 fps
DGHDRtoSDR: 102.4 fps
Don't know if I have maxed out HDRTools because the multithreading instructions are a bit complicated and confusing (to me). I'm not sure I like the idea of internal multithreading in the filters.
Timings for prefetch=6 on my i7-7700K + 1080 Ti:
HDRTools: 15.25 fps
DGHDRtoSDR: 102.4 fps
Don't know if I have maxed out HDRTools because the multithreading instructions are a bit complicated and confusing (to me). I'm not sure I like the idea of internal multithreading in the filters.
Re: HDR -> SDR tonemapping
Thank you for the new implementation, I'll try out later.
Re: HDR -> SDR tonemapping
FYI guys, the sat parameter is broken and is fixed at 1.5. I'll fix that in the next release. Fortunately, 1.5 is a reasonable value.
Re: HDR -> SDR tonemapping
I figured out how to determine which pixels are outside the 709 gamut.
* Convert 10-bit YUV to normalized [0,1] float RGB (still nonlinear).
* Linearize by applying ST.2084 PQEOTF.
* Convert to CIE XYZ space. Use the matrix from:
http://www.russellcottrell.com/photo/ma ... ulator.htm
* Project to obtain the the x and y values of the CIE colorspace.
* Test if the x,y value falls outside the triangle defined by the 709 color primaries.
This will enable me to test different nonlinear (i.e., different action on in-gamut and out-of-gamut) gamut mappings.
I'm starting to actually grok all this stuff.
* Convert 10-bit YUV to normalized [0,1] float RGB (still nonlinear).
* Linearize by applying ST.2084 PQEOTF.
* Convert to CIE XYZ space. Use the matrix from:
http://www.russellcottrell.com/photo/ma ... ulator.htm
* Project to obtain the the x and y values of the CIE colorspace.
* Test if the x,y value falls outside the triangle defined by the 709 color primaries.
This will enable me to test different nonlinear (i.e., different action on in-gamut and out-of-gamut) gamut mappings.
I'm starting to actually grok all this stuff.
Re: HDR -> SDR tonemapping
Thanks for the update
There seems to be some issues with the tonemap parameters
none and mobius are returning the same result, and hable is very dark in <150 luma (light param only affects high luma areas)
Also the saturation looks off, the reds are unsaturated for some reason.
In order: default, hable, HDRTools
I didn't save the previous plugin version but the colors with inverse looked like HDRTools.
There seems to be some issues with the tonemap parameters
none and mobius are returning the same result, and hable is very dark in <150 luma (light param only affects high luma areas)
Also the saturation looks off, the reds are unsaturated for some reason.
In order: default, hable, HDRTools
I didn't save the previous plugin version but the colors with inverse looked like HDRTools.
Re: HDR -> SDR tonemapping
Thank you for your testing.
mobius and none are not the same. Check the detail in the clouds right around the left of the left-hand rider and the green tone in the clouds for none in the samples below. Mobius is subtle but definitely improves colors and details in the brighter areas. The first is:
dghdrtosdr(impl="255",tm="none",sat=1.00,light=250)
and the second is:
dghdrtosdr(impl="255",tm="mobius",sat=1.00,light=250)
You can try a sat=1.25 to increase the saturation. I would look at HDRTools but it's all hard-core ASM with no C version, so it may be difficult to compare what I am doing to that. I expect that the difference here is due to the gamut mapping, which I am still studying. To me, the HDRTools soldier's face looks a bit too red.
Regarding Hable, I hate Hable. I simply don't understand the parameters at all, so I cannot tell if it is working correctly. Can you give me that sample please? Also, try increasing the exp parameter to something like 10.
mobius and none are not the same. Check the detail in the clouds right around the left of the left-hand rider and the green tone in the clouds for none in the samples below. Mobius is subtle but definitely improves colors and details in the brighter areas. The first is:
dghdrtosdr(impl="255",tm="none",sat=1.00,light=250)
and the second is:
dghdrtosdr(impl="255",tm="mobius",sat=1.00,light=250)
You can try a sat=1.25 to increase the saturation. I would look at HDRTools but it's all hard-core ASM with no C version, so it may be difficult to compare what I am doing to that. I expect that the difference here is due to the gamut mapping, which I am still studying. To me, the HDRTools soldier's face looks a bit too red.
Regarding Hable, I hate Hable. I simply don't understand the parameters at all, so I cannot tell if it is working correctly. Can you give me that sample please? Also, try increasing the exp parameter to something like 10.
Re: HDR -> SDR tonemapping
You're right, there's a difference between none and mobius mostly only in highlights, mobius being much better at retaining detail and not overblowing the lighting.
However the colors are still off, and increasing saturation doesn't restore the reds.
I managed to get the old 1.2 version of the plugin and the colors are much better.
In order: none, mobius, old plugin I don't really care about Hable either anymore, but I'm not sure it's a problem with Hable as it works properly on the old plugin.
Tested HDRTools with the different chromacity parameters
1 is Gx=0.265, Gy=0.690, Bx=0.150, By=0.060, Rx=0.680, Ry=0.320 (BT2100, from the github page)
2 is Gx=0.170, Gy=0.797, Bx=0.131, By=0.046, Rx=0.708, Ry=0.292 (BT2020, from the code)
However the colors are still off, and increasing saturation doesn't restore the reds.
I managed to get the old 1.2 version of the plugin and the colors are much better.
In order: none, mobius, old plugin I don't really care about Hable either anymore, but I'm not sure it's a problem with Hable as it works properly on the old plugin.
Tested HDRTools with the different chromacity parameters
1 is Gx=0.265, Gy=0.690, Bx=0.150, By=0.060, Rx=0.680, Ry=0.320 (BT2100, from the github page)
2 is Gx=0.170, Gy=0.797, Bx=0.131, By=0.046, Rx=0.708, Ry=0.292 (BT2020, from the code)
Re: HDR -> SDR tonemapping
That's great info, thanks. Can I get the source file to be able to investigate all this? Thank you.
Re: HDR -> SDR tonemapping
Here's a small sample of the part
https://mega.nz/#!AVliwIqa!XSnOsoEAMGG8 ... R9hW8QvtYE
Script for HDRTools 0.1, it errors with the latest 0.2 for some reason.
https://mega.nz/#!AVliwIqa!XSnOsoEAMGG8 ... R9hW8QvtYE
Script for HDRTools 0.1, it errors with the latest 0.2 for some reason.
ConvertYUVtoXYZ(Color=0,OutputMode=1, Gx=0.170,Gy=0.797,Bx=0.131,By=0.046,Rx=0.708,Ry=0.292,Wx=0.31271,Wy=0.32902)
ConvertXYZ_HDRtoSDR(MinMastering=1, MaxMastering=1000,Coeff_X=26, Coeff_Y=26, Coeff_Z=26)
ConvertXYZtoYUV(Color=2, OutputMode=2, pColor=0)
z_ConvertFormat(pixel_type="YV12")
Re: HDR -> SDR tonemapping
Great, thank you.
Re: HDR -> SDR tonemapping
@Narkyy
Please re-download version 1.4 as I have slipstreamed a fix for the colors issue. Looks good to me although, again, this may not be my final gamut mapping solution.
http://rationalqm.us/misc/DGHDRtoSDR_1.4.rar
@douzi
For your stream with the blown-out heater set light=400-500 for good results with this new version. I am working on a heuristic to set light automatically based on the metadata and video content.
Please re-download version 1.4 as I have slipstreamed a fix for the colors issue. Looks good to me although, again, this may not be my final gamut mapping solution.
http://rationalqm.us/misc/DGHDRtoSDR_1.4.rar
@douzi
For your stream with the blown-out heater set light=400-500 for good results with this new version. I am working on a heuristic to set light automatically based on the metadata and video content.