functional image minimized despite being in same space?

[csuncodes]

Hello AFNI gurus,

I am trying to overlay these two images to see areas of activation. I set the structural MNI as the underlay and the functional as the overlay. When I do this, afni for flash the correctly overlayed images for a second and then I can only see the MNI image. Then after changing the threshold for the overlay, I see that it is there but for some reason is shifted and minimized. I have no idea why it does this since both images are in the same space. I am working in AFNI version 18.1.26 but have replicated this in other versions as well.

The 3dinfo for both images are:
Dataset File: MNI152_T1_3mm.brain.nii.gz
Identifier Code: XYZ_4uNZnWnhn0gVWKG2mRs6wA Creation Date: Wed Feb 11 09:48:52 2015
Template Space: MNI
Dataset Type: Anat Bucket (-abuc)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 543,266 (543 thousand [kilo]) bytes
Geometry String: “MATRIX(3,0,0,-90,0,-3,0,126,0,0,3,-72):61,73,61”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -90.000 [R] -to- 90.000 [L] -step- 3.000 mm [ 61 voxels]
A-to-P extent: -90.000 [A] -to- 126.000 [P] -step- 3.000 mm [ 73 voxels]
I-to-S extent: -72.000 [I] -to- 108.000 [S] -step- 3.000 mm [ 61 voxels]
Number of values stored at each pixel = 1
– At sub-brick #0 ‘?’ datum type is short: -962 to 8353

----- HISTORY -----
[agrethe@taisen.ucsd.edu: Wed Feb 11 09:48:52 2015] 3dresample -rmode Cu -inset …/…/standard/MNI152_T1_2mm.nii.gz -dxyz 3 3 3 -prefix …/…/standard/MNI152_T1_3mm.brain.nii.gz

Dataset File: lme_resample2.nii.gz
Identifier Code: XYZ_pxLsZ2IFoIuaeyXJoJS2UA Creation Date: Fri Jul 29 16:36:20 2022
Template Space: MNI
Dataset Type: Echo Planar (-epan)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 13,038,384 (13 million [mega]) bytes
Geometry String: “MATRIX(3,0,0,-90,0,-3,0,126,0,0,3,-72):61,73,61”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Posterior-to-Anterior
third (z) = Inferior-to-Superior [-orient RPI]
R-to-L extent: -90.000 [R] -to- 90.000 [L] -step- 3.000 mm [ 61 voxels]
A-to-P extent: -90.000 [A] -to- 126.000 [P] -step- 3.000 mm [ 73 voxels]
I-to-S extent: -72.000 [I] -to- 108.000 [S] -step- 3.000 mm [ 61 voxels]
Number of time steps = 12 Time step = 1.00000s Origin = 0.00000s
– At sub-brick #0 ‘GroupCW_Estimate’ datum type is float: -0.000110403 to 0.000161289
– At sub-brick #1 ‘GroupCW_t.value’ datum type is float: -3.17021 to 3.73328
statcode = fizt
– At sub-brick #2 ‘GroupCW_pval’ datum type is float: 0 to 0.999949
** For info on all 12 sub-bricks, use ‘3dinfo -verb’ **

----- HISTORY -----
[sunc04@gux01-1: Wed Jul 27 23:27:25 2022] {AFNI_18.1.26:linux_openmp_64} 3drefit -view tlrc -space MNI -substatpar 1 fizt -substatpar 5 fizt -substatpar 9 fizt -sublabel 0 GroupCW_Estimate -sublabel 1 GroupCW_t.value -sublabel 2 GroupCW_pval -sublabel 3 GroupCW_pflip -sublabel 4 VisitFED_Estimate -sublabel 5 VisitFED_t.value -sublabel 6 VisitFED_pval -sublabel 7 VisitFED_pflip -sublabel 8 GroupCW:VisitFED_Estimate -sublabel 9 GroupCW:VisitFED_t.value -sublabel 10 GroupCW:VisitFED_pval -sublabel 11 GroupCW:VisitFED_pflip lme_CW_BN_FAST_FED_StopError-GoCorrect_n_15_0.99_TrueModelFreeOutput.nii.gz
[sunc04@gux01-1: Fri Jul 29 16:36:20 2022] {AFNI_18.1.26:linux_openmp_64} 3dresample -inset lme_CW_BN_FAST_FED_StopError-GoCorrect_n_15_0.99_TrueModelFreeOutput.nii.gz -master MNI152_T1_3mm.brain.nii.gz -prefix lme_resample2.nii.gz

Any help is appreciated.

[ptaylor]

This is still a bit under investigation, but the issue appears to be that the R script didn’t propagate header information when making the output dset. So, instead of applying 3dresample immediately, 3drefit should have been applied to fix the header information.

Note that 3dresample is typically used when the header and data information match each other. Then, 3dresample is used to adjust the header information, while also adapting the data information to be consistent with the new header and also correct.

3drefit is typically used when a piece of header information is known to be incorrect, and so it should be changed and the data is not accompanyingly changed. Also, 3drefit does not produce a new dset (3dresample does, via the “-prefix …” option), so we would typically recommend copying the dset in question first, and putting the copy through 3drefit. In case something goes wrong or you decide you are unhappy with that change, you have the untouched original still.

So, if I started with a dset with LAI information, then:

• “3dresample -orient RAI …” would lead to a new dset that would still match exactly with the original dset in the viewer—if I overlay the new RAI one on the old LAI one, all features line up still between them.
• “3dcopy … … ; 3drefit -orient RAI …” would lead to a new dset that does not generally match the original in the viewer (assuming the left and right are not exactly symmetric). If I overlay the new RAI one on the old LAI one, the features will not line up between them.

When created new dsets in Matlab, R, Python, etc. one should always be very careful about what header information gets propagated, and how—it is very tricky and requires a lot of verification. Using packaged software when possible, which should manage both data and header aspects consistently, is often safer to use.

This is also another reason why visualizing the data during intermediate steps is so important—noticing that the new brain here was tiny was key to noting an issue occurred. If the data had just been thresholded and only looked at at output time, for example, in some cases such problems can be hidden. So, great to notice this issue, and now it is just a matter of tracking where/why it occurs in the R script, and how to re-set things appropriately afterward.

–pt