3dFWHMx classic outputs

AFNI Message Board
1

Version AFNI_24.0.19 'Caracalla'

Hi AFNI gurus

I started to prepare a long context email with numbers and an animated gif etc but I'll cut to the chase for this first message:

I'm using 3dFWHMx -ShowMeClassicFWHM for smoothness estimation only (not multiple comparisons correction) and are the 3 outputted numbers, assuming a normal afni_proc pipeline, the x, y and z dimensions in mm, in that order? thanks!

-Sam

2

Ciao, Sam-

Yes, there might be 4 numbers in some cases:

 FWHM_x FWHM_y FHWM_z  FWHM_combined

--pt

3

hi Paul-

Ok thanks for confirming, and so quickly.

I have data that, due to the physics of how it's acquired, is objectively smoother in the slice direction than the in-plane directions. Because of this anisotropic property I need to estimate the (real-world-interpretable, e.g. in mm) smoothness of all 3 dimensions separately. The ACF approach doesn't seem to offer 3 separate estimates, only a single averaged value following the coefficients, therefore I'm using the -ShowMeClassicFWHM option with 3dFWHMx (like I said I'm not using these for inputs into 3dClustSim).

Using "classic" 3dFWHMx I'm perplexed why I consistently get the highest smoothness estimate as the 2nd of the values (as FWHM_y). Note I'm using 3dFWHMx within the AP context, so it's just calculated on the errts, detrended, within a mask.

i was about to send too much info on averaged FWHM across many datasets i have, but just remembered that the vlines processing creates a file that's sort of an extreme version of my data. so to test, i just ran 3dFWHMx -ShowMeClassicFWHM -input APtest.results/vlines.pb00.tcat/proj.r01.nii.gz and got:
7.00272 7.45993 7.20619 7.22053
so that checks out with what i'm seeing with my own data.

what do you think? could there be a bug in this option for 3dFWHMx? Or are these values not real-world-millimeter-interpretable? i could send you more info about my data itself but i think this example especially demonstrates the point, as my data's blurring effects are sometimes subtle depending on which resolution i'm testing. thanks!

-sam

4

Ciao, Sam-

3dFWHMx is indeed a radial (=spherical) fit, and doesn't estimate in distinct directions.

To check one thing, what is the orientation of your dataset---is it "xyz"-like or something else? That is, are you sure that the 2nd component (in one-based counting) is the "y" direction? For example, when I run 3dFWHMx -ShowMeClassicFWHM on an RAI dataset, I got the lines:

# old-style FWHM parameters
 6.17177  5.92997  5.14636     5.73219

If I resampled it to AIR, I got the lines:

# old-style FWHM parameters
 5.92997  5.14636  6.17177     5.73219

Same final result, but the ordering of the individual components follows the orientation.

--pt

5

On initial comment: you are probably showing a partial command, but make sure there is a -detrend option in there, as well as something for masking.

As Paul notes, when AFNI says xyz orientation, it means the orientation of the data on disk, whatever that might be. Otherwise, it should explicitly say DICOM, RAI, LPI, or some other specific orientation. But xyz does not imply what it is, only that it is the disk order.

Note that if your datasets were created using dcm2niix[_afni], then they are generally being reoriented to RPI on disk, so they might not match the original orientation.

  • rick
6

hi guys

oh! ok so i think this settles it; i just need to find a different tool or library to do what i'm looking for. this definitely reflects a misunderstanding of the original algorithm on my part, sorry to bother you again!

-Sam