Grating artifacts after slice time correction?

[davidgruskin]

Hi all,

I've recently encountered some interesting slice time correction-related artifacts in my data and was wondering if anyone else has run into these/knows if these will seriously affect downstream preprocessing and analyses.

To begin, my data were acquired in a posterior to anterior order with an interleave factor of two, corresponding to the "alt+z" tpattern in AFNI. I've confirmed this in my acqp files and using the method described in this paper.

When I run STC through RABIES, I got the following tSTD map and noticed the gratings indicated by the blue arrows:

STC performed in: RABIES | Tpattern: Alt+z

If I don't apply STC, or if I apply alt+z STC using SPM before passing my data into RABIES (and not running STC in RABIES), I don't see the gratings:

STC performed in: No STC | Tpattern: No STC

STC performed in: SPM | Tpattern: Alt+z

Here's an image of the alt+z tSTD map minus the no STC tSTD map to more clearly illustrate the gratings:

The gratings are not related to STC vs. motion correction ordering, as running STC in AFNI before passing data into RABIES also leads to similar tSTD gratings. They are also not related to the direction of STC, as running alt+z correction vs. alt-z correction still leads to gratings (although the high tSTD slices are swapped with the low STD slices). Finally, I ran seq+z and seq-z STC in RABIES and saw that instead of gratings, I ended up with a middle-> A/P or A/P -> middle tSTD pattern (shown below).

STC performed in: RABIES | Tpattern: Seq+z

STC performed in: RABIES | Tpattern: Seq-z

These different STC approaches affect the autocorrelation of my data. Here are histograms showing distributions of voxel-wise AR(1) coefficients as a function of STC approach. To summarize, running SPM STC (with any tpattern) before RABIES centers the distribution at 0 with small AR(1) values (red curves). Running AFNI STC (or STC within RABIES) using alt tpatterns gives intermediate AR(1) values (black curves). Running AFNI STC with seq tpatterns (brown curves) leads to high, left skewed AR(1) values, and RABIES STC with seq tpatterns gives a mirrored distribution (purple curves).

Accordingly, I was wondering:

1. Does anyone know what these patterns reflect (e.g., do they indicate improper slice time correction/lots of motion/etc.)?
2. Which STC strategy seems most appropriate for my data? My TR is only 1 second, so I imagine STC might not be critical, but not running STC (or running STC in SPM first, both of which don't result in gratings) drops my AR(1) coefficients to a mean of 0, which seems weird for BOLD data. On the other hand, RABIES/AFNI alt+z both give me reasonable AR(1) values and match the ground truth of the slice order in which my data were acquired, but the gratings are unexpected and I'm hesitant to analyze data with that kind of inhomogeneity.

Any advice/insights would be greatly appreciated, and thanks so much for reading + thanks to the RABIES developers for such a wonderful package!

[gdevenyi]

Hi,

The fact that some tools correct the interleaving collection and others don't indicates to me that your files may not be encoded in the way they're supposed to be. My understanding is SPM is very "dumb" in this regard, blindly loading data and running algorithms, whereas AFNI (and RABIES, or at least the tools inside) "trust" the various metadata properties, which may result in the algorithm doing something different than you expect.

Can you provide some more information on how you got from raw scanner data to the files passed into RABIES/AFNI?

[davidgruskin]

Thanks for the response @gdevenyi!

Sure- I used brkraw to convert my raw Bruker data (acquired in a tail-first, prone orientation) to BIDS format. I then changed my qform code to 1 and sform code to 0, and used fslswapdim to put my images into RAS orientation. I did recently notice that the slice timings in my JSON are off by a consistent ratio, but the order is correct and multiplying my slice timings by a constant to correct this error didn't change the RABIES output (which makes sense, as I don't believe 3dTshift uses JSON files). I've attached my nifti header file here- the header seems more or less similar to the header in the RABIES example datasets in the relevant fields?
sub-Dv006DMS_ses-20220831_run-02_bold_fslhd.txt

Please let me know if any additional information would be helpful re: troubleshooting this issue!

[Gab-D-G]

Hi @davidgruskin, thanks for the thorough investigation! Those are curious features indeed. Why did you have to modify the qform/sform and re-orient to RAS? RABIES will automatically re-orient to RAS before STC, so maybe you could try it with RABIES without a priori re-orientation?

[davidgruskin]

@Gab-D-G thanks for the suggestion! I did originally try to use the direct-from-brkraw data, but I was not able to get through rabies-preprocess without errors. I think this is probably because the labels brkraw applies to my data are incorrect, as you can see in the screenshot of my unpacked nifti file shown below (the A/P labels are flipped). I suspect that's related to this brkraw issue, and that some versions of ParaVision probably correct for orientation while others do not, but I'm not certain.

In any event, below is an example registration plot and rabies log from one such run that illustrates the issues I was encountering.

rabies_preprocess.log

Orienting the files to RAS myself (with fslswapdim and editing the qform) and then passing the data into RABIES resolved that issue, so I didn't pursue the brkraw issue further (although it would be nice to have certainty re: left/right orientation) and I'm not sure there's a way for me to see the effects of re-orientation on STC in RABIES at the moment. Do you think it's worth opening an issue in the brkraw repo?

[gdevenyi]

I suspect that's related to this brkraw issue, and that some versions of ParaVision probably correct for orientation while others do not,

If you're suspecting a brkraw bug, please open an issue with as much info as possible (versions, how the animal is loaded, an example dataset) so we can investigate.

[Gab-D-G]

Overall, it seems that you have managed to narrow down the issue to a difference between how AFNI VS SPM apply STC to your images, so I don't think this issue is about RABIES per say, but AFNI. Understanding why AFNI is not quite applying the right correction would need further inspection of what the software reads from your file... The only other aspect that you could inspect with RABIES is the TR provided to AFNI's command. Did you try manually specifying the TR to your RABIES command? If the TR was misread, it could lead to those stripping effects you're seeing by overcorrecting along the anterior and posterior edges.

[davidgruskin]

@Gab-D-G yup- my TR is always specified!

In any event, I've figured out what's going on. Different interpolation methods for STC (and any other preprocessing step that involves temporal interpolation) introduce different amounts of autocorrelation to the data (with polynomial interpolation introducing more autocorrelation than sinc/fourier approaches), and the amount of autocorrelation introduced is higher for slices that require more temporal interpolation (e.g., even slices acquired in an interleaved sequence). The former effect explains why SPM STC did not introduce gratings (it uses a sinc approach by default) and the AFNI/RABIES STC did (as heptic interpolation is used by default), and the later effect explains the specific patterns of gratings that I saw in the tSTD and AR(1) plots. This was noted in an update to 3dTshift from 2019 (see below).

And here's a relevant post from Bob Cox on interpolation after frame censoring.

When running AFNI STC with different interpolation methods, I get the predicted pattern of AR(1) results (below), and like Bob Cox noted, my gratings completely disappear with Fourier correction (and partially disappear with wsinc9, and less so with wsinc5).

Given these results, I think it would be helpful to be able to specify the specific interpolation method used by 3dTshift from RABIES (just like the tpattern). I'll submit a pull request for that sometime in the next few days if that sounds good to you!

[Gab-D-G]

That's awesome, nice work @davidgruskin ! I'll integrate your pull request as part of the next version.