HDR -> SDR conversion
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.