afni_proc: different -align_epi_ext_dset and -volreg_base_dset


I wanted to ask if I understand the help correctly and not missing something.

In I want to use a -volreg_base_dset that is different from -align_epi_ext_dset: MIN_OUTLIER vs. epi[0], the latter is otherwise removed by -tcat_remove_first_trs. As all epi volumes are aligned to MIN_OUTLIER, but epi[0] is used as a basis of anat alignment, any difference between epi[0] and MIN_OUTLIER should be included in the pipeline as another transform, correct? Do I have to explicitly do that in any way? Or, as I am inferring from the help, this is handled internally by afni_proc?

Sorry for not looking at this earlier. This is currently not handled by It has been on the to-possibly-do list for years, but has not had much demand.

What is your use case? I would think MIN_OUTLIER would be a very good volreg base. What are you using for that? Is it to get the volreg output into a different location? Are you not going to standard space?


  • rick

Oh, thank you for looking at this (and the other one) during weekend!

This is an NHP dataset which gives me a lot of trouble with EPI-anat alignment. Like I said in the other post, I am basically following MACAQUE_DEMO_REST so I am going to standard (NMT2.1) space, using animal_warper, now possibly adding another anat step, as described in the other post.

At some point, I spent a lot of time tuning epi-anat alignment (but using MIN_OUTLIER) but even in relatively successful attempts, one or two epi dsets would fail to align. And these were different dsets depending on the parameters, so it wasn’t that I had two completely bad datasets. Daniel Glen suggested using EPI[0] for epi-anat alignement, with the logic that a pre-steady state image has better contrast. I should also have said that the EPIs are collected with MION, which changes contrast compared to regular EPIs.

This worked fine (well, better than before), so I used EPI[0] for volreg and EPI-anat alignement.

Just recently I had a thought that maybe EPI[0] is good for anat but not ideal for volreg,

In afni_proc help I found

    The entire purpose of -align_epi_ext_dset is for the case where the
    user might want to align the anat to a different volume than what is
    used for the EPI (e.g. align anat to a pre-steady state TR but the EPI
    to a steady state one).


        The user might want to align to an EPI volume that is not in the
        processing stream in the case where there is not sufficient EPI
        contrast left after the magnetization has reached a steady state.
        Perhaps volume 0 has sufficient contrast for alignment, but is not
        appropriate for analysis.  In such a case, the user may elect to
        align to volume 0, while excluding it from the analysis as part of
        the first volumes removed in -tcat_remove_first_trs.
  • which is exactly what I had in mind. So I decided to try that. But then I started having doubts about the “missing link” between the epi[0] volume and the MIN_OUTLIER volume, I could not find an answer in the documentation, so I thought I’d ask here.

By the way, I hope you don’t mind if I quickly ask about a different thing,
This sequence:

3dAllineate -base           $MPRAGE_file                             \
            -input          ${MDfile_u}+orig                         \
            -prefix         $MDfile_alMP_u                           \
            -cost           lpa                                      \
            -1Dmatrix_save  tmp                                      \
            -automask                                                \
            -source_automask                                         \
            -cmass                                                   \
            -maxrot         45

#convert transform into 3x4 format for further cat_matvec
cat_matvec tmp.aff12.1d > ${MD_MP_lin_Xfm}.1d
rm tmp.aff12.1d

works fine on Ubuntu on my laptop, but fails on CentOS Biowulf. Both cat_matvec and rm claim that tmp.aff12.1d is not there. If I check after the script finished, I see tmp.aff12.1d in the folder.

This looks like an HPC issue (because it runs fine on Ubuntu), and I have a ticket open with them, but just in case it’s actually an AFNI thing, I am asking here as well. (I believe AFNI versions might be slightly different, on Ubuntu I have 22.0.01 and HPC is on AFNI_22.0.04)

Okay, your case is exactly what has been on the list, and what I should have done long ago, but have not. My first reading had MIN_OUTLIER in the wrong position, so I wanted to verify your usage.

The messy aspect of this case is deciding how to align those 2 volumes. Maybe using 3dAllinneate and allowing a cost function would be most reasonable. But that might not fully generalize. I will have to ponder and test that a bit…

  • rick

Thank you. For now I will probably use EPI[0] for both. I do not have a strong rationale for using separate bases, just wanted to see if it helps.

This seems like something we can resolve directly. The biowulf folks might just ping us about this in any case.

Can you send me the AP text output containing the full volreg block via email (or just the full AP text output)?

It is likely that something else is failing first.


  • rick

Then intention was always to allow a [0] separate from a more appropriate volreg base (MIN_OUTLIER). It is past time to make it work
It might be most straightforward mixing with the -volreg_post_vr_allin abilities, I will ponder that…

  • rick

You might try putting a short delay before the cat_matvec with a 2 second sleep.

Regarding the differing EPI and volreg bases, Rick and I have had discussions about this for a very long time. The assumption in, I believe, is that if they are different, then they are already aligned, say the volume 0 and volume 3 are used. Because they are close in time to each other, and with little motion between the two times. also allows for different bases for alignment, but those two are aligned to each other with an additional transformation. I haven’t looked at this myself for many years, so I’m not completely sure it still works.

Hi Daniel,

thank you for the explanation about different bases. These are 15-minute runs in a monkey, so I think that making an assumption of negligible movement between epi[0] and min_outlier, which may be anything from epi[2] to epi[409], may be too risky. I will probably revert to epi[0] for both.

I had thought that maybe something is going on with the file system, and I did try inserting a sleep, and it was sleep 10. Same result…

Hi Rick,

I sent you an explanation by email, but I thought I would put it here as well, maybe it will be useful for someone in the future.

My Ubuntu runs in VM on Windows, and my script operates on folders that are shared with Windows. File operations on such folders are apparently handled by Windows (even if requested by Linux), and thus are case-insensitive. The script had wrong case in a file name, which broke it when running on native Linux on HPC, but not in VM in folders shared with Windows.

There are ways to make these file operations case-sensitive in Windows (and, consequently, they become case-sensitive for Linux when reaching to the folders from VM). Of course, I am going to do it from now on…

Hi Pawel,

That is interesting. I had not known of WSL making the linux subsystem essentially case-insensitive. Maybe there is a similar translation on macs, because they are case-insensitive for some operations, too.

Good to know, thanks!

  • rick

Hi Rick,

just to clarify, I am using Oracle VM, not WSL - trying to run AFNI on Linux on WSL was far more cumbersome than via VM. But based on the information I have, the same problem may occur with WSL. Incidentally, the solution may be identical in both cases.

Hi Pawel,

I just wanted to mention that this additional registration is now automatically performed. Whenever -align_epi_ext_dset is used, an extra affine registration is applied to align it with the EPI registration base. These changes went in on March 10-12, so hopefully you have them now.

It was long past time for that to come of “the list”…


  • rick

Thanks, Rick!