OpenMP for align_image_stack

[Daniel Kaneider]

Hi,

I'm not sure if this is the right place for features requests, as this is one:

align_image_stack is very slow. On my system with 4 cpus (2 logical HT) I rarely have more than 30% of cpu usage. This means that alignment currently takes minutes with 3-5 bigger images (< 20MP). OpenMP is one of the easier possibilities to make the whole process faster. Please evaluate how/whether this could help. I observed that hugin, or parts of it, are already using OpenMP, since the specific dll is shipped on windows.

[tmodes (tmodes)]

Hugin is not using OpenMP (it is only used by enblend/enfuse). Hugin is using boost::threads, zthreads and on Windows also the Parallel Patterns Library (PPL) in different code parts for multi-threading.
Align_image_stacks consists of 3 parts:
1.) Control points finding/fine tuning: This part can't be so easy made multi-threaded, because each iteration is using some variables from the previous iteration. This requires some more deeper changes to the code than a simple OpenMP pragma.
2.) Optimisation: this takes the shortest time (and is using libpano13) - this will remain single-threaded.
3.) Remapping: This part was only using one thread. I committed changes to use all available cores (or you can fine-tune the number of threads with --threads=NUM). The changeset contains also code to alternatively use the GPU for remapping (add switch --gpu, the GPU remapping code is still marked as experimental, but it works fine in my test). On my machine the new default setting with 4 cores is faster than the older version, the GPU version is even faster.

[Daniel Kaneider (kaneiderdaniel)]

Thanks! Would it be possible to get some beta builds? (x64 or x86). Or in other words, in which timeframe is the new release scheduled?

[tmodes (tmodes)]

Beta 1 (without the fix) was release last week. The fix will be in beta2 or RC1. I'm expecting a new release in the first quarter of this year.

[tmodes (tmodes)]

I implemented OpenMP for align_image_stack in an own branch. A further speed up could achieved by a faster cross correlation algorithm. Both changes result in shorter processing times.
If the availability of OpenMP is checked for the different system, it can go into default branch.