I created a branch with a significant speedup for Mantiuk08 tmo
4 Likes
https://filebin.net/iyh1xb0ib0t6ujaq/Luminance_HDR_2.5.2-SNAPSHOT-Test1k.dmg
Here is a dmg for MacOS 10.9+
I patched in the Mai speedup as well. 
wget https://github.com/LuminanceHDR/LuminanceHDR/pull/113.patch
wget https://github.com/LuminanceHDR/LuminanceHDR/pull/114.patch
patch -p1 < 113.patch
patch -p1 < 114.patch
1 Like
I guess you meant the mai speedup
#&%!ˆ@ autocorrect
1 Like
I have no clue about the programming of this algorithms, but I played yesterday with the tone mapping in GIMP (GEGL) 2.10 RC2 and it was extremely slow:
http://www.gegl.org/operations/tonemapping.html
Especially the Mantiuk 2006 (GEGL has no Mantiuk 08) was nearly unusable with an 8192x4096 image. Perhaps you can port some of you optimisations to the GEGL code.
Mantiuk06 is one of the slow tonemappers.
Nevertheless there was room for improvements
I had a look at the gegl implementation and indeed at least one of my speedups could be used there as well.
For example:
Renormalize luminance sorts all the pixels of your image using only one thread to find the Luminance values which correspond to the (minPrctsize) smallest value and the (maxPrctsize) smallest value in data.
This can be done much faster without sorting and also multithreaded. Caller is here.
The current Luminance HDR code uses this method for mantiuk06, fattal and durand tonemappers.
Maybe @houz can tell us where to file an optimization request for mantiuk06 in gegl. I can give some hints then.
I think the best way is to write a “bugreport” here:
Mantiuk06 is one of the slow tonemappers.
Do you know a website, that compares the different tonemappers?
I found this not long ago:
https://www.cl.cam.ac.uk/~rkm38/pdfs/eilertsen2017tmo_star.pdf
Mantiuk is referenced a number of times, but I haven’t done the reading to see if/how 06 is considered.