3dSkullStrip failure on current but not previous version

The script I am working on began to fail, and the failure point seems to be in 3dSkullStrip run by align_epi_anat.py run by afni_proc.py run by a heavily modified derivative of MACAQUE_DEMO_REST

It occurs with a specific data set (session 1). Another very similar data set (same experiment, same subject, different session (3)) runs fine. But the problematic session 1 was analyzed in the same way before without problems, and I think that the reason why it does not anymore is a change to afni.

Below is my reasoning for that.

I reverted my script to the state equivalent to the state in which it ran successfully on the same data set. While I did not have the old version of the script, I knew what changes I made. The reverted script failed again when run on session 1.

I had a copy of the old results folder. I compared the ‘old’ vs ‘new’ proc file for session 1, and I see no differences except for a few minor changes (which seem to be in TSNR calculation and in gen_ss_review_scripts.py), the date when it was run, and afni_proc.py version.

I compared ‘old’ and ‘new’ output.proc file, and the only differences I see up to the point of failure are the date when it was run, afni_proc.py version, and AFNI version (and minor differences in execution time)

afni_proc version is 7.12 vs 7.14, afni version is 21.0.08 vs. 21.0.13.

The point of failure is:

3dSkullStrip -orig_vol -input ./__tt_vr_base_min_outlier_ts+orig -prefix ./__tt_vr_base_min_outlier_ts_ns
Warning 3dSkullStrip:****************
 Surface self intersecting! trying again:
 smoothing of 84, avoid_vent -1
Warning 3dSkullStrip:****************
 Surface self intersecting! trying again:
 smoothing of 96, avoid_vent -1
Warning 3dSkullStrip:****************
 Surface self intersecting! trying again:
 smoothing of 108, avoid_vent -1
Warning 3dSkullStrip:****************
 Surface self intersecting! trying again:
 smoothing of 120, avoid_vent -1
Warning 3dSkullStrip: Stubborn intersection remaining at smoothing of 120. Ignoring it.*** NO CLUSTERS FOUND ***

Then it tries to soldier on, but in 3dBrickStat -automask it applies a rather suspicious threshold of 0 (previously 2730) and the script soon dies with
** FATAL ERROR: 3dAllineate fails :: base image has 0 nonzero voxels (< 100)
No surprise, the base: __tt_vr_base_min_outlier_ts_ns+orig is all black.

This all seems to point to a change made in 3dSkullStrip(?) between the versions. But I realize that there is a chance that I failed to revert the script to exactly same state even if there was no difference in proc or output.proc. Or there was a change to source data that I forgot about…

So I found a computer with AFNI 20.3.03 installed, I copied all source data and scripts from my ‘new’ version that failed, ran the script, and it did not fail.

This makes me pretty confident that a change between 21.0.08 and 21.0.13 is responsible for the skull-stripping failure when processing session 1 - so I am wondering if this change could be traced and re-evaluated if it is really necessary?

I will be happy to provide the data and scripts which should allow to replicate the issue.

Hi, Pawel-

There are a couple things here:
First, we do keep histories of changes, both in this history text file, gateway’ed here:
and in the github:
The second is more finegrained, because every bit of change is recorded in detail.

I note that AFNI binary version 21.0.08 got built on Feb 11, 2021, and ver 12.0.13 got built on March 3, 2021.

Second, with afni_proc.py (AP), gen_ssreview.py and TSNR—
AP used to apply a mask to the TSNR dset, but now it no longer does that, so we can see it every TSNR everywhere in the brain. You should also get QC images of TSNR now in the APQC HTML.

Third, with skullstripping/processing:
Something that could throw skullstripping off, esp. if you have subj from a different session, is the coordinates not being good. That is, if (x,y,z)=(0,0,0) is not loosely central in the volume/dset, then 3dSkullStrip might fail about growing a surface outward (how it works). So, that is something to check for this subject where it fails. It also sounds like you are changing a script between these tests, and could that be introducing a change?

I don’t see any major changes to 3dSkullStrip in that interval. There was a change with NIFTI I/O, but that was something that applied in some very particular case(s).
A test of changes/failure would be if: you have one script+AFNI Binary version that worked today on a particular dataset, and then if, on the very same dataset and using the same script, processing failed with an updated binary version. Very small changes in a script miiight affect things–e.g., the coordinates.

If you have a dataset and a specific command(s) that used to work, but now doesn’t, I’d be happy to take a look. Otherwise, with possible script changes and differing datasets, it is a bit hard to try to suggest anything.


Hi Paul,

sorry I think after several hours of testing I failed to convey my points in my lengthy post. Let me try again, briefly:

  1. I only have a problem with skullstripping, I mentioned TNSR and gen_… just to say I see differences but I think not relevant.

  2. I think I can provide a data/script combo that fails on 21.0.13 and works fine 20.3.03. Though I noticed the change between 21.0.08 and 21.0.13 I have no access to 21.0.08 to doublecheck.

Let me prepare that combo: I will ensure that it will be clear for you how to make it work on your machine (directories, etc) and that I strip it of irrelevant stuff. I will also re-test it both in 20.3.03 and 21.0.13, and if it still replicates the problem, I’d love to send it to you. What is the best way? I am in NIH, so maybe NIH Box?

Thanks a lot,


Hi, Pawel-

Sure, sounds good. I will send you a Box link for the dset, yes.


Hi, Pawel-

Well, after a looong day yesterday of building AFNI versions, testing, and investigating code… you were absolutely right. A bug had crept into 3dSkullStrip via a side function. Thanks very much for bringing this to our attention (with a good example dset to test on).

We have fixed the bug, and started a build about an hour ago. So, in another hour or two, the updated binaries should be downloadable with “@update.afni.binaries -d”. The version you will want to end up with is at least: AFNI_21.0.19.


Thanks, Paul!

I think it must have been pretty subtle given that a dataset from the same monkey, just a different session, did go through. I am glad I could (indirectly) contribute to AFNI becoming a tiny bit better!