afni_proc.py 11b -- align_epi_anat.py -- attributeError: 'NoneType' object has no attribute 'input'

AFNI Message Board
1

Hello, I am using afni_proc.py to generate a resting preprocessing data script (11b). I have done this in the past, including on the data I am currently examining through the same computer, without issues (even over the past few days). However, today when running the generated script, I run into the error “attributeError: ‘NoneType’ object has no attribute ‘input’” which I have narrowed down to the issue being from align_epi_anat.py. I saw previously one can just add -resample off to the command to circumnavigate the issue. That appears to be working.

My questions are:
(1) Are there any potential issues with the 11b pipeline then if -resample off is set for the align_epi_anat.py step?
(2) Why might this be happening, given this wasn’t happening before, and as far as I can tell I am rerunning the same data that I have in the past that had no issue
(3) Is there any other way I might get around this issue other than manually going into each generated proc script and adding -resample off? For example, is there something I can add to afni_proc.py to tell the generated script to do -resample off in the align_epi_anat.py?

Thanks!

2

Hmm, weird. I see a previous post from 10 years ago when the “-resample off” thing was mentioned… I hope there is a better solution by now!

Just to check, what is your AFNI version:


afni -ver

?

I might have to send you an upload directory for your data, if you can share it with me, to take a look. I have not encountered this before.

So, I don’t know an answer to #1 or #2 because of my ignorance for this… For #3, that really shouldn’t be necessary.

But, I think I would have to check out the data first.

–pt

3

Like Paul, I haven’t seen this often, but the last time, I think, it was related to the input NIFTI dataset having an ambiguous format. If you repeat with

setenv AFNI_NIFTI_VIEW orig

Also show the whole AFNI command or align_epi_anat.py command actually used. The resampling off or on doesn’t really matter though because the alignment will automatically handle resampling internally.

4

Howdy-

To add to Daniel’s advice, it would be nice to check the NIFTI header directly if that is, indeed, the likely culprit—that will help us to recognize this more quickly in the future and help future generations trawling the Message Board diagnose potential issues more quickly.

To see the full NIFTI header:


nifti_tool -disp_hdr -infiles DSET_NIFTI

To target just the [q,s]form_code values:


nifti_tool -disp_hdr -field qform_code -field sform_code -infiles DSET_NIFTI

–pt

5

Thank you! This is all very helpful!

Interestingly, I think I figured out this may be related to a slower internet connection. I have my files auto-update/sync to a secure network. It has never given me issues before, but I realized that the day I was running into this issue my ethernet was not working and instead I was on WiFi. As soon as I moved my files to a different local directory that does not try to update/sync, I no longer got these issues. So, it appears that I either need the higher speed of ethernet, or I need to stick to a non-syncing directory during the processing and upload later?

Odd to me that it kept running into an issue at the same command, and also maybe odd then that -resample off did circumnavigate the issue.

6

That is good to know, but I don’t think I have a good “reverse engineering” explanation for what might have been happening. Maybe using resample shrunk some file size so it it didn’t bottleneck, then? Or maybe a file was damaged at some point in the sync’ing? Or maybe it iwas nterference from those space alien laser rays, as they try to pick out our humanoid cable signals for free? Equally likely to be any of those.

But glad it is resolved—let us know if it happens back.

–pt