Does 3dvolreg have OpenMP support?

Dear afni experts,

I have a “Precompiled binary macosx_10.7_Intel_64: Nov 23 2016 (Version AFNI_16.3.13)” version of afni on my Mac Pro, and I notice that some commands (e.g., 3dAllineate, 3dDeconvolve, etc.) are parallelized using OpenMP, making them run considerably faster.

Does 3dvolreg has similar OpenMP support?
If I need to compile afni myself in order to get such functionality, could you point to some docs with how-to’s (step-by-step guide would be the best) for me, please?

Thank you!

3dvolreg has been fast enough to do registration in
real time since 1988, so there is little need to speed
it up with OpenMP. Only some programs have been
enhanced with OpenMP support, as the author (usually
Bob) has seen fit.

3dAllineate is a more computationally intensive program
(plus it takes much longer than 3dvolreg to run), and so
Bob has enhanced it with OpenMP support, for example.

To be sure, exactly why are you wondering about this?
Is there some circumstance under which you believe
3dvolreg is not fast enough?

  • rick

Thank you rick for your reply:)

I was fiddling to see whether upsampling a little bit before running 3dvolreg would be helpful for getting more accurate realignment, especially when only a limited portion of the brain is covered in the functional images.
In the above circumstance, I found 3dvolreg actually became the bottleneck in the pipeline, consuming much more time than 3dAllineate and 3dDeconvolve, contrary to my expectation.
Without upsampling, 3dvolreg is fast, as you mentioned.

I think 3dvolreg is a perfect candidate for parallelization in term of the nature of its computation, given that each sub-brick is independently (please correct me if this is not the case) registered to the template.

Do you think this feature would be on your list in the future?:slight_smile:

What you ask is not unreasonable, but it is not something I’ve considered doing. It would take some effort, since that old program was not written with parallelization in mind, so make it work with multi-threading would require a careful examination of the code. Without a stronger argument than you give, it’s not worth my effort.

Thank you Bob for your explanation. I understand you must have a busy priority queue for developing such a complex piece of software.

By the way, do you think upsampling the functional data before 3dvolreg would possibly do any good to motion correction?
Is there an easy way to objectively compare the quality of two sets of motion correction results using afni (e.g., 3dvolreg -dfile would be one possibility)?