Output geometry side effect in fat_proc_dwi_to_dt

giuseppe.cabras · February 4, 2019, 8:45pm

Dear Paul and fatcat expert users,

I am using the command:

fat_proc_dwi_to_dt
-in_dwi dwi_proc/dwi_DMC.nii
-in_col_matT dwi_proc/dwi_DMC.bmtxt
-prefix dwi_DMC2dt
-in_struc_res dwi_proc/dwi_DMC_structural.nii
-in_ref_orig imit2w.nii
-mask dwi_proc/dwi_DMC_structural_brain_mask.nii
${my_flip}

that generate good output for me, but I get a strange side effect in Geometry string of output, e.g.:

$ 3dinfo dt_FA.nii.gz|grep Geometry
++ 3dinfo: AFNI version=AFNI_18.3.15 (Dec 5 2018) [64-bit]
Geometry String: “MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115”

while the Geometry of input files are “rounded”:

3dinfo dwi_proc/dwi_DMC.nii|grep Geometry
++ 3dinfo: AFNI version=AFNI_18.3.15 (Dec 5 2018) [64-bit]
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”

the same Geometry for dwi_DMC_structural.nii and dwi_DMC_structural_brain_mask.nii while of course the imit2w.nii Geometry is different:

$ 3dinfo imit2w.nii|grep Geometry
++ 3dinfo: AFNI version=AFNI_18.3.15 (Dec 5 2018) [64-bit]
Geometry String: “MATRIX(1,0,0,-95,0,1,0,-100,0,0,1,-73):192,236,172”

the different dt_FA.nii.gz Geometry create errors for successive group analysis with SPM.

Note that if I use 3dAutomask:

fat_proc_dwi_to_dt
-in_dwi dwi_proc/dwi_DMC.nii
-in_col_matT dwi_proc/dwi_DMC.bmtxt
-prefix dwi_DMC2dt
${my_flip}

the output Geometry is correctly “rounded”:

3dinfo dt_FA.nii.gz|grep Geometry
++ 3dinfo: AFNI version=AFNI_18.3.15 (Dec 5 2018) [64-bit]
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”

and I have no issues on SPM group analisys, but Automasking is not optimal!

Do you have any suggestion on how to solve my problem?

Cheers,

Giuseppe

ptaylor · February 6, 2019, 10:40pm

Hi, Giuseppe-

Quick question-- how are you making your mask, “dwi_proc/dwi_DMC_structural_brain_mask.nii”? Can you please post the command from that, and its “3dinfo …” output?

Also, have you tried the option: “-mask_from_struc”

–pt

giuseppe.cabras · February 7, 2019, 6:28pm

Hi Paul,

to make mask from dwi_DMC_structural.nii, I used fsl bet command:

bet dwi_proc/dwi_DMC_structural.nii dwi_proc/dwi_DMC_structural_brain.nii -f 0.2 -m -R

the stripping and mask looks fine, while -mask_from_struc option from dwi_DMC_structural.nii generate a very very small mask in many of our images… absolutely useless, I don’t know why. Also, the bet generated mask is geometrically fine:

[qcuser@psy10fdc dwi_proc]$ 3dinfo dwi_DMC_structural_brain_mask.nii.gz
++ 3dinfo: AFNI version=AFNI_18.3.15 (Dec 5 2018) [64-bit]

Dataset File: dwi_DMC_structural_brain_mask.nii.gz
Identifier Code: NII_tR3h5zs0pRTO3gXHEMKIbg Creation Date: Thu Feb 7 17:09:00 2019
Template Space: ORIG
Dataset Type: Anat Bucket (-abuc)
Byte Order: LSB_FIRST {assumed} [this CPU native = LSB_FIRST]
Storage Mode: NIFTI
Storage Space: 4,622,080 (4.6 million [mega]) bytes
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”
Data Axes Tilt: Plumb
Data Axes Orientation:
first (x) = Right-to-Left
second (y) = Anterior-to-Posterior
third (z) = Inferior-to-Superior [-orient RAI]
R-to-L extent: -94.750 [R] -to- 95.750 [L] -step- 1.500 mm [128 voxels]
A-to-P extent: -99.750 [A] -to- 134.250 [P] -step- 1.500 mm [157 voxels]
I-to-S extent: -72.750 [I] -to- 98.250 [S] -step- 1.500 mm [115 voxels]
Number of values stored at each pixel = 1
– At sub-brick #0 ‘?’ datum type is short

Thanks for your help,

cheers,

Giuseppe

ptaylor · February 7, 2019, 7:11pm

Hi, Giuseppe-

Well, if you have to use “bet … -f 0.2”, I am guessing that there is some intensity gradients or something in the structural?

Anyways, that’s somewhat indepedent of the current scenario. Can you please upload the dset (basically, just the files you are inputting to the fat_proc* command) and send me a message when they are there?

–pt

giuseppe.cabras · February 7, 2019, 8:20pm

Hi Paul,
I uploaded the zip file fromGiuseppe2Paul, inside the datasets you asked and my script used to generate the FA, MD, etc… from them (basically tortoise output).
Thanks a lot,
cheers,
giuseppe

giuseppe.cabras · February 7, 2019, 8:28pm

… btw, with the same datasets you may discover why -mask_from_struc option is so bad with this dataset.
Thankx for your time,
Giuseppe

ptaylor · February 7, 2019, 9:44pm

Hi, Giuseppe-

Well, when I run the fat_proc command, all the dwi_* and dt_* files produced by fat_proc_dwi_to_dt have the same geometry (in this case, it is the origin that we are talking about):


3dinfo dwi*gz dt*gz  | grep MATRIX 

Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"
Geometry String: "MATRIX(1.5,0,0,-94.74982,0,1.5,0,-99.7506,0,0,1.5,-72.75083):128,157,115"

If you use the dwi_dwi.nii.gz made by fat_proc._dwi_to_dt with your dt*FA.nii.gz measures, then your files should have the same geometry. The TORTOISE-output DWI file, whose MATRIX is different, can be so because the fat_proc_dwi_to_dt re-centers the DWIs over the input “ref_orig” file as part of its workings-- one can expect in general that the output DWI file form TORTOISE could (likely will) have a different origin than the one that has been re-aligned to the ref_orig dset. The values in teh DWI files should be the same-- it is just the location+orientation information that would be different.

–pt

giuseppe.cabras · February 8, 2019, 3:01pm

Thanks Paul for the detailed check and answer. Indeed I also get the same results and they are correct to me too. My problem is that the analisys team of my project (which use SPM) tell me that they can’t run group analysis because they get the following error in DTI group statistics:

Running job #1

Running ‘Factorial design specification’
Mapping files :
** The images do not all have same orientation and/or voxel sizes. **
The function assumes that a voxel in one image corresponds exactly
with the same voxel in another. This is not a safe assumption if
the orientation information in the headers or .mat files says that
the images are oriented differently. Please ensure that you process
all data correctly. For example, you may have realigned the images,
but not actually resliced them to be in voxel-wise alignment.
Here are the orientation matrices of the image volumes. This list
can be used to determine which file(s) are causing the problem.

[-1.5 0 0 96.2498; 0 -1.5 0 101.251; 0 0 1.5 -74.2508] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/312/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2507; 0 -1.5 0 101.251; 0 0 1.5 -74.2504] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/59229/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2499; 0 -1.5 0 101.251; 0 0 1.5 -74.251] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/2604/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.25; 0 -1.5 0 101.25; 0 0 1.5 -74.2512] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/69420/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2501; 0 -1.5 0 101.25; 0 0 1.5 -74.2513] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/2972/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2504; 0 -1.5 0 101.251; 0 0 1.5 -74.2511] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/19100/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.251; 0 -1.5 0 101.25; 0 0 1.5 -74.2506] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/19971/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2502; 0 -1.5 0 101.25; 0 0 1.5 -74.2509] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/11336/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2497; 0 -1.5 0 101.25; 0 0 1.5 -74.25] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/39802/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2515; 0 -1.5 0 101.251; 0 0 1.5 -74.2499] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/11290/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2498; 0 -1.5 0 101.25; 0 0 1.5 -74.2499] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/31146/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2495; 0 -1.5 0 101.251; 0 0 1.5 -74.2512] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/22266/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2513; 0 -1.5 0 101.25; 0 0 1.5 -74.2514] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/35175/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2498; 0 -1.5 0 101.25; 0 0 1.5 -74.251] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/43442/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2508; 0 -1.5 0 101.251; 0 0 1.5 -74.2509] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/777/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2501; 0 -1.5 0 101.251; 0 0 1.5 -74.2508] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/44076/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2495; 0 -1.5 0 101.251; 0 0 1.5 -74.25] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/33920/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2516; 0 -1.5 0 101.251; 0 0 1.5 -74.2502] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/60497/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2497; 0 -1.5 0 101.251; 0 0 1.5 -74.2507] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/3910/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2496; 0 -1.5 0 101.251; 0 0 1.5 -74.2498] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/13746/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2502; 0 -1.5 0 101.25; 0 0 1.5 -74.2509] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/38697/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2503; 0 -1.5 0 101.25; 0 0 1.5 -74.2502] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/69124/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2507; 0 -1.5 0 101.25; 0 0 1.5 -74.2492] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/17850/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2502; 0 -1.5 0 101.25; 0 0 1.5 -74.2501] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/24095/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2505; 0 -1.5 0 101.251; 0 0 1.5 -74.2501] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/52379/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.25; 0 -1.5 0 101.25; 0 0 1.5 -74.2504] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/54612/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.25; 0 -1.5 0 101.251; 0 0 1.5 -74.2494] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/30763/gc_DIFFPREP14/dt_FA.nii
[-1.5 0 0 96.2504; 0 -1.5 0 101.251; 0 0 1.5 -74.2504] /home/Data_ss/NAS_wp3/20-Dec-2017/Data/38846/gc_DIFFPREP14/dt_FA.nii

Failed ‘Factorial design specification’
Error using spm_check_orientations (line 65)
The orientations etc must be identical for this procedure.
In file “/home/wp3/spm12_v6685_cat12_r1207/spm_check_orientations.m” (v5097), function “spm_check_orientations” at line 65.
In file “/home/wp3/spm12_v6685_cat12_r1207/config/spm_run_factorial_design.m” (v6219), function “spm_run_factorial_design” at line 677.

No executable modules, but still unresolved dependencies or incomplete module inputs.
The following modules did not run:
Failed: Factorial design specification
======END======================

and they get this error only if dt_FA.nii are generated by fat_proc_dwi_to_dt with -mask* option, i.e. all matrix origins are veeery little different (0.00xx), while with fsl dtifit, tortoise EstimateTensorWLLS and even with fat_proc_dwi_to_dt with Automask the matrix is the same for all images FA images of all subjects:
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”
Probably the problem is in the SPM side, but we have not found a solution for our data yet.
Cheers,
Giuseppe

ptaylor · February 8, 2019, 7:28pm

Hi, Giuseppe-

Still looking into options for changing some of this, since the rounding differences are causing so much headache.

One thing, though-- are you needing all of these brains to align voxelwise for whatever analysis you are choosing? Each of these will “just” be in subject-native space after TORTOISEing, having just been aligned to their own anatomical. From the TORTOISE+FATCAT steps, there is no alignment to a standard space-- so even if their origin+orientation information matches, there will be no meaningful voxelwise alignment across subjects.

-pt

giuseppe.cabras · February 11, 2019, 8:52am

Hi Paul,
well, I axialized the subject images to an anatomical reference (mni icbn152 ACPCE) before DIFFPREP, and this seems sufficient for Tortoise, fsl dtifit and fat_proc_dwi_to_dt with Automask to mantain voxel align, but fat_proc_dwi_to_dt -mask* introduce this 3drefit step in computation:
3drefit -dxorigin .000172 -dyorigin -.000603 -dzorigin -.000828 ./dwi_DMC2dt_dwi.nii.gz
before 3dDWItoDT that seems to me just a rounding problem (0.000xxx mm?). Probably, if you could avoid this 3drefit, the analysis group of my project would not have the difficulties encountered whatever analysis they invents.
Cheers,
Giuseppe

ptaylor · February 11, 2019, 3:15pm

Hi, Giusseppe-

I think that if you don’t include the “-in_ref_orig …” option, your dsets will be in the same space.

Traditionally, when TORTOISE would output dsets, it would output volumes with a particular orientation and with an origin = (0,0,0). In order to keep data in a single “native anatomical” space, the fat_proc_dwi_to_dt would use the “-in_ref_orig …” option to reset the orientation+origin of the set so it would overlay with the anatomical reference provided into TORTOISE-- hence the option’s name. Typically, the data is recentered via the “-in_struc_res …” input, because that is just the input anatomical dset, resampled by TORTOISE and on the same grid as the output DWI-- basically, following standard usage, the ‘-in_struc_res …’ dset is therefore extremely easy to align with the ‘-in_ref_orig …’ dset, because they are The Same data, just at different resolutions-- the only real difference should be however TORTOISE resampled them.

In your data, the ‘-in_struc_res …’ and ‘-in_ref_orig …’ dsets basically already align almost-- the resampling differences are the only differences in origin. They are tiny, <<1 voxel edge. So, I don’t believe that it is a 3drefit error, it is just the tiny differences between the resampled dsets.

I will chat with the TORTOISE folks-- if they are no longer changing the origin+orientation on output, it is possible that the “-in_ref_orig …” will no longer be useful. Can I ask what version of TORTOISE you are using?

Some other comments:

You mentioned difficulty making a mask of the structural using AFNI. However, note that those “structurals” are imitation t2w dsets-- by definition when you used the AFNI/FATCAT tool fat_proc_imit2w_from_t1w to make them, a mask of the input (T1w) structurals was made-- you can use/apply that same mask here, as by definition that should be the most appropriate mask for these particular dsets.
Have you contacted the TORTOISE people about using DIFFPREP in the manner that you are currently using it-- namely, not using the subject’s own anatomical structural space as a reference, but instead using a warped version of it to standard space? When warping to standard space, it is important to have appropriate warps and cost functions for it; it is possible the kinds of warps that DIFFPREP utilizes are not meant for such large changes. If you haven’t already, I would definitely ask the TORTOISE folks for their opinion on that; even if it is something possible, it might benefit from special flags/settings.

Typically, when aligning data across subjects (which includes ‘subject space’ to a ‘standard space’), one should use real/full nonlinear alignment. In AFNI, that would be 3dQwarp/@SSwarper, and TORTOISE that might be DR_TAMAS.

-pt

giuseppe.cabras · February 11, 2019, 6:19pm

Hi Paul,
thanks for your comments and interest. Just a few rapid reply to your questions:

I am using TORTOISE_V3.1.1/DIFFPREPV311
I am using fat_proc_imit2w_from_t1w Ver. 2.2 (PA Taylor, Mar 1, 2018) and I don’t see an output mask, I see a a skull-stripped version of PREFIX_t1w.nii.gz: you mean that I can generate a mask from this skull-stripped and use it?
why you sed “a warped version to standard space” I have just axialized to a reference (6DOF) not warped… isn’t it?

To reply to other comments I have to check (and study more).
Cheers,
Giuseppe

ptaylor · February 11, 2019, 6:36pm

Hi Giuseppe,

A rapid reply to your rapid reply:

OK, thanks.
Yes, you can use something like


3dcalc -a DSET -expr 'ispositive(a)' -prefix DSET_BINARIZED

to make a binary mask from the ss’ed version.

I see-- my fault for the confusion-- I misunderstood your previous post.
I thought you were warping all the dsets to a standard space so that you could do a voxelwise analysis across them all.
If they are just axialized, I guess I don’t understand the need for grid overlap across different subjects’ DTI data (even though the comment for the fat_proc_dwi_to_dt command in my previous post should lead to subjects having that grid matching).

–pt

giuseppe.cabras · February 12, 2019, 4:34pm

Dear Paul,
seems that your suggestion to NOT include the option “-in_ref_orig …” solve my problem, now all subject Geometry string outputs are in “exactly” expected form:
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”
Geometry String: “MATRIX(1.5,0,0,-94.75,0,1.5,0,-99.75,0,0,1.5,-72.75):128,157,115”

I also generated the -mask from the structural output of Tortoise, which as the same Geometry string and the same voxel size (1.5x1.5x1.5), while the imit2w_orig_ss has generally different geometry.

Thank you very much for your valuable help,
cheers,
Giuseppe