HDR -> SDR conversion

[admin]

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.

[Narkyy]

Yes, it is slow. I'm just mentioning it because the conversions seem accurate.

[admin]

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.

[Narkyy]

I have a license already, I just can't use it for HEVC

[admin]

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.

[douzi]

Thank you for the new implementation, I'll try out later.

[admin]

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.

[admin]

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.

[Narkyy]

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

1.png (1.32 MiB) Viewed 734 times

2.png (829.75 KiB) Viewed 734 times

3.png (1.32 MiB) Viewed 734 times

I didn't save the previous plugin version but the colors with inverse looked like HDRTools.

[admin]

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.

none.bmp (23.73 MiB) Viewed 727 times

mobius.bmp (23.73 MiB) Viewed 727 times