gen_ss_review_scripts.py doesn't understand @slice_timing_file style tpattern

AFNI Message Board
1

Hey,

I run afni_proc.py using the -tshift_opts_ts -tpattern @${sliceTimesFilename} because my BOLD files do not have slice timing embedded in the header. This works well in afni_proc. However, the filename gets passed on to gen_ss_review_scripts.py which has not been written to recognize this method of providing the slice times. Consequently, the @${sliceTimesFilename} just gets printed out by the review tcsh scripts, rather than, in this case, being converted into a multiband level of 2 and alt+z slice time pattern.

If possible, could someone please modify gen_ss_review_scripts.py so that it knows what do do with a tpattern that begins with an @?

Precompiled binary linux_ubuntu_22_04: Mar 30 2025 (Version AFNI_25.0.13 'Severus Alexander')

2

Hello,

This is a little surprising. afni_proc.py was updated more than 2 years ago to pass this information on to gen_ss_review_scripts.py (GSRS was not updated for it), and a current analysis shows this correctly.

Are you possibly running a very old proc script, even with a current version of AFNI?
What is the version at the very top of the proc script (should be the 4th line, below auto-generated)?

Thanks,

-rick

3

from the tcsh file generated by the invocation of afni_proc.py

echo "auto-generated by afni_proc.py, Thu Feb 27 13:58:09 2025"
echo "(version 7.85, January 29, 2025)"
echo "execution started: `date`"
4

Hi Colm,

While I think this is all solvable, it seems easier to workaround this report display trickiness by refitting or making a new dataset with the correct slice timing in the first place before feeding it to afni_proc.py. You can use either 3drefit -Tslices or 3dTcat -tpattern to do this. Both can make either AFNI or NIFTI format with AFNI extensions that contain the required slice timing information. afni_proc.py can query the dataset with 1d_tool.py to figure out the slice timing pattern name. Do either of these sound like reasonable options?

5

Indeed. Also, I was a bit too distracted and blew off the @ aspect in that 2 year old update. Will ponder...

Thanks,

-rick

6

I thought about that but discounted it since just to get correct reports would require running the entire afni_proc pipeline from scratch on all my subjects data. For a (effectively) 160 subjects that's about a week of compute time for what's not a big deal for me. My only point in reporting the issue is that if it's not behaving for me, then it's probably not behaving for others

7

Plus, all reprocessing would do is pass the timing that you give it up to the reports. It might be better to still insert the times in the files (maybe using abids_tool.py?) and then gtkyd_check.py to check for consistency.
Or else just run 1d_tool.py -show_slice_timing_pattern on all of the @pattern file data to look for consistency.

But either way, I will try to add that in.
Thanks for bringing it up,

-rick

8

The DICOMS were bids-ified by dcm2bids v3.2.0 which invoked dcm2nii v1.0.20241211. Quite why the slice times were not put in the nifty header I don't understand. In any case, my scripts extracts the slice times from each subject's JSON side car (for one run) and passes the created file into afni_proc.

9

Reading a sidecar is on the todo list as well... :)

NIFTI datasets can only store a small set of timing codes, so in general, that format is not good enough to rely on timing, e.g. it cannot encode multiband timing at all. That is probably why dcm2niix does not even bother, and goes straight to the json files.

10

Before I forget again, I put in an update to afni_proc.py for this on Wednesday, though you probably don't need it. Basically, this will just run 1d_tool.py -show_slice_timing_pattern, and pass the text output to gen_ss_review_scripts.py.
Thanks,
-rick