3dcalc transformations of the statistic maps

AFNI Message Board
1

Dear AFNI experts,

I am transforming F- and t-statistic maps to z-statistic maps using 3dcalc. In some cases (when df1=1) I think that the z-statistic map resulting from the transformation of the F-statistic should be the same as the z-statistic map resulting from the transformation of the t-statistic. However, I tend to get slightly different results in such cases. I am wondering if this is due to numerical issues or if I make a mistake. Below the AFNI commands:


3dinfo stats.sub-CAS0001_REML+tlrc[0]

  -- At sub-brick #0 'Full_Fstat' datum type is float:  7.54451e-11 to       65.7991
     statcode = fift;  statpar = 1 247

3dinfo stats.sub-CAS0001_REML+tlrc[2]

  -- At sub-brick #0 'activation_stimulus#0_Tstat' datum type is float:     -4.76188 to       8.11167
     statcode = fitt;  statpar = 247

3dcalc -a stats.sub-CAS0001_REML+tlrc[0] -expr 'cdf2stat(stat2cdf(a, 4, 1, 247, 0), 5, 0, 0, 0)' -prefix standardized_stats/zstat_from_Fstat.nii

3dinfo standardized_stats/zstat_from_Fstat.nii 

  -- At sub-brick #0 'Full_Fstat' datum type is float:     -4.34628 to        7.5404
     statcode = fift;  statpar = 1 247

3dcalc -a stats.sub-CAS0001_REML+tlrc[2] -expr 'fitt_t2z(a, 247)' -prefix standardized_stats/zstat_from_tstat.nii

3dinfo standardized_stats/zstat_from_tstat.nii 

  -- At sub-brick #0 'activation_stimulus#0_Tstat' datum type is float:     -4.65303 to       7.63014
     statcode = fitt;  statpar = 247

As you see, the minimum values in the z-statistic maps are -4.34628 and -4.65303, not quite the same. Is it a numerical issue?

Sorry for bothering you!

Best wishes,

Wiktor Olszowy

2

Wiktor,

I cannot offer an exact explanation for such discrepancies. One possibility is a data precision issue; if so, add option “-datum float” to your 3dcalc command and see if that makes any difference.

A side note: you can use “3dmerge -1zscore …” to the whole file, and it will convert all the statistics sub-bricks in the file to Z-stat (and keep anything else intact). At least it works for AFNI format. Not so sure about NIfTI files, though.

3

Dear Gang,

Thanks a lot for your response! So it looks like this is only a numerical issue. However, adding option “-datum float” to 3dcalc did not change the results. “3dmerge -1zscore” sounds like a very helpful command, but actually for my AFNI-format data it only works for the t-statistic map (brick [2]), not for the F-statistic map (brick [0]):


3dmerge -1zscore stats.sub-CAS0001_REML+tlrc[0]

3dinfo mrg+tlrc

++ 3dinfo: AFNI version=AFNI_16.2.02 (Jul 19 2016) [64-bit]

Dataset File:    mrg+tlrc
Identifier Code: XYZ_PWSMDGionJcw1ZRWJwi0kA  Creation Date: Wed Mar 14 00:52:12 2018
Template Space:  TLRC
Dataset Type:    Func-Bucket (-fbuc)
Byte Order:      LSB_FIRST [this CPU native = LSB_FIRST]
Storage Mode:    BRIK
Storage Space:   524,288 (524 thousand [kilo]) bytes
Geometry String: "MATRIX(2.999178,0,-0.103922,-94.31225,0.036819,-2.554494,2.327512,34.34985,0.05979,1.573074,3.779615,-124.6071):64,64,32"
Data Axes Tilt:  Oblique (31.651 deg. from plumb)
Data Axes Approximate Orientation:
  first  (x) = Right-to-Left
  second (y) = Posterior-to-Anterior
  third  (z) = Inferior-to-Superior   [-orient RPI]
R-to-L extent:   -94.312 [R] -to-    94.688 [L] -step-     3.000 mm [ 64 voxels]
A-to-P extent:  -154.650 [A] -to-    34.350 [P] -step-     3.000 mm [ 64 voxels]
I-to-S extent:  -124.607 [I] -to-    13.033 [S] -step-     4.440 mm [ 32 voxels]
Number of values stored at each pixel = 1
  -- At sub-brick #0 'Full_Fstat' datum type is float:  8.67712e-06 to       7.63014
     statcode = fizt

It is not important, but maybe you would see an explanation.

Best wishes,

Wiktor Olszowy

4

Wiktor,

So it looks like this is only a numerical issue. However, adding option “-datum float” to 3dcalc did not change the results.

You can double check some voxels in the brain and make sure that those two files have roughly the same z-values.

“3dmerge -1zscore” sounds like a very helpful command, but actually for my AFNI-format data it only works for the
t-statistic map (brick [2]), not for the F-statistic map (brick [0]):

Actually it did. It does not change the labels, but it does convert all statistic values to z-values as shown in the sub-brick coding:

statcode = fizt

which indicates a Z-stat sub-brick.