Back to the main page.

Bug 1826 - make a version of ft_volumerealign that can align T1, T2, PD, CT, DTi and such to each other

Status ASSIGNED
Reported 2012-11-08 11:38:00 +0100
Modified 2012-12-19 15:29:18 +0100
Product: FieldTrip
Component: forward
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Ümit Aydin
URL:
Tags:
Depends on:
Blocks:
See also:

Robert Oostenveld - 2012-11-08 11:38:09 +0100

At this moment we have ft_volumerealign with takes one input and assigns a coordinate system based on landmarks. We also have ft_volumenormalize that takes one input and spatially warps it to the MNI template brain. It would be useful to have the code in fieldtrip style that would align one individual's T2, T2 and DTi (or for that matter: other anatomical scans).


Robert Oostenveld - 2012-11-08 11:53:40 +0100

I have added a test script to get started mac001> svn add test_bug1826.m A test_bug1826.m mac001> svn commit test_bug1826.m Adding test_bug1826.m Transmitting file data . Committed revision 6889.


Robert Oostenveld - 2012-11-08 21:07:31 +0100

note to the simbio team: This is an idea we did not concretely decide upon in Nijmegen, but I do think it makes sense: it is in line with what Umit presented and would be a natural part of the required anatomical preprocessing pipeline. It can be considered a ana2ana function, i.e. anatomy in, anatomy out.


Lilla Magyari - 2012-11-19 12:13:26 +0100

hi Umit, I assigned this bug for you. Please, read the earlier comments to see which part of the FieldTrip code should be developed. You can find also a test_script (in fieldtrip/test/test_bug1826) that gives some information how the new functionality could fit into the FieldTrip pipeline. (At the moment, a "return" is inserted at the beginning of the test script for the common svn version, which you can comment out in your version.) But first, we need images which are aligned and which are not aligned, and also DTi ones. Could you send me aligned and also not aligned images (including dti type) that you usually use for segmentation? I would like to try first if I can read them in into FieldTrip. Thanks. Lilla


Ümit Aydin - 2012-11-19 15:31:26 +0100

Sorry for not being involved for a while but I have been working on a paper which I hope to finish till 1st of December then I will be able to spend more time on the filedtrip pipeline. I always first convert them from DICOM to nifti format and then use in the pipeline and since fieldtrip is able to load nifti, I did not face any problem loading those. You can download the T1, T2 and DTI images in their own spaces and in T1 space after registration: "https://www.dropbox.com/s/riplyw102bhlcl2/test_bug1826_data.zip" I will send you the password for the zip file via e-mail. I usually use the 4D nifti data for DTI but I can also divide it to separate 3D images. Is there any preferential there ? Should we give the user different options like different interpolation techniques, cost functions etc .. In our pipeline I use the spline based interpolation instead of the default trilinear interpolation. It adds a second step (I call the nonlinear registration for the interpolation with the transfer matrix calculated from the linear registration) to the pipeline but the smoothing is reduced like that. In the folder there is 'T2_T1space_trilinear' and 'T2_T1space_spline' so you can check the difference. Best Ümit


Robert Oostenveld - 2012-11-19 16:45:14 +0100

Hi Umit, thanks for the replies. Since Lilla is not an expert on anatomical processing, you'll have to concretely guide her through the analysis using the test script. Regarding DTi (not our expertise, although we could ask colleagues at the Donders): What does the 4D nifti represent? If it had been FA, then it would have been a 3D representation, right? Giving the user options is in general a good idea, but having defaults is also good. If there are many options, I suggest the same strategy as used in ft_componentanalysios, using cfg.fsl.option=value etc. Or in general cfg.(cfg.method).name = value.


Ümit Aydin - 2012-11-19 17:10:46 +0100

(In reply to comment #5) I will modify the test script until weekend and then Lilla could try to use it with the data I have sent. The 4D data it is not the FA image. The FA image is 3D as you also stated. For the DTI pipeline we have one 3D b0 image (no diffusion gradient), and for example 20 directional images (b1, b2, ...b20) where each of them are also a 3D image. So as a result we can have 21 3D images to process or 1 4D image which is simply the stacked version of those 21 images. Probably it will be best to supply the users the default parameters as I am using for our pipeline now and allow them to use other functionalities in a format as you suggested (as in ft_componentanalysis).


Robert Oostenveld - 2012-11-19 17:16:12 +0100

for the 4D data we will have to think on how to represent it in FieldTrip. Pls don't forget to send the zip password by email. Robert


Robert Oostenveld - 2012-11-20 09:15:28 +0100

@Lilla, I have made the data available on /home/common/matlab/fieldtrip/data/test/bug1826. I have also updated the test script mac001> svn commit test_bug1826.m Sending test_bug1826.m Transmitting file data . Committed revision 6960. The reading part works fine (also with unzipping on mac and linux). Even for the DTi it works, resulting in DTi = dim: [128 128 70] anatomy: [4-D double] hdr: [1x1 struct] transform: [4x4 double] where >> size(DTi.anatomy) ans = 128 128 70 21 I do expect this 4D representation currently to be problematic for many fieldtrip functions, as they expect size(DTi.anatomy)==dim and it to be 3D.


Robert Oostenveld - 2012-11-20 09:18:36 +0100

(In reply to comment #8) > I do expect this 4D representation currently to be problematic for many > fieldtrip functions, as they expect size(DTi.anatomy)==dim and it to be 3D. Sorry, I pressed commit too fast... We have to discuss in-house how to deal with DTi data (or in general with N-D volumetric data. Possibly we have to extend ft_datatype_volume with a check on the dim and to ensure that it is 3-D where needed and that it can be N-D at some places. E.g. ft_sourceplot would probably not know how to deal with it, but ft_sourceinterpolate would.


Ümit Aydin - 2012-11-20 10:53:17 +0100

(In reply to comment #9) The 4D data is not a must for DTI. It just depends on how you convert the images from DICOM to nifti. One can also use the dcm2nii converter to produce 3D data. In that case we will have DTI_01.nii DTI_02.nii ... ans use them one by one. I can also check if the data is 4D and 3D, and divide it to 3D by adding the following script. aa=horzcat('fsl4.1-fslsplit ',DTI,' splitted_',DTI(1:end-4),'_ -t'); unix(aa,'-echo') This converts a 4D image to 3D images and the naming will again be like splitted_DTI_01.nii splitted_DTI_02.nii ... Probably this will be the best way to do this, so we can check if it is 3 or 4D and then split it to 3D if it is 4D. I can perform all steps on those seperated images too. Also all results after the DTI processing pipeline like FA, MD, main diffusion vectors are in 3D.


Robert Oostenveld - 2012-11-20 12:29:52 +0100

I suggest not to explore alternatives at the moment, but just work on the data and example pipeline that we have. Ignoring the DTi data at the moment is fine. The problem then reduces to "make a version of ft_volumerealign that can align T1, T2". Once we have that, we can later consider to "make a version of ft_volumerealign that can align T1, DTi".


Jan-Mathijs Schoffelen - 2012-11-20 12:30:35 +0100

spm_coreg can do between modality coregistration


Robert Oostenveld - 2012-11-20 12:31:30 +0100

(In reply to comment #12) That is another possibility to explore.


Lilla Magyari - 2012-11-20 14:36:56 +0100

(In reply to comment #13) Hi Robert and Umit, my permission to read in test/bug1826 is denied. I can read the T1, T2 and DTi images though (from my own directory). But I could not plot them, I got an error with ft_plot_ortho. But this is a problem with the function, because I could plot the images with ft_sourceplot. I could even plot the DTi image (on the first 3 dimensions). So, I changed ft_plot_ortho to ft_sourceplot. I also looked at the T2 spline and trilinear aligned T2's. The only difference I could see (by visually inspecting the plot) that the bone, skin...etc. (everything except of brain) was much darker on the tri-linearly aligned image. The transformation matrix is the same for T1, not-aligned T2 and for both aligned T2's. Lilla


Ümit Aydin - 2012-11-20 14:59:40 +0100

(In reply to comment #11) Then I will modify the test script and make it work with our data for now. Then we can decide on other steps. (In reply to comment #12) There are indeed many useful image registration algorithms that we might use in SPM. If it is preferable to use SPM we can use those. I am referring to the registration algorithms of the FSL here because that is what we are currently using in our pipeline in Munster and the ones who will use the segmentation pipeline in FSL for FEM, can also use it for registration purposes. (In reply to comment #14) yes of course you can plot the dti with a line like figure; ft_plot_ortho(DTI_aligned.img(:,:,:,1));title('DTI after aligning') The difference between trilinear and spline will be on the smoothness of the image. You can see that the trilinear is more blurred in comparison to spline. Currently I am working on the test script and hopefully I will commit it by tomorrow.


Ümit Aydin - 2012-11-28 09:01:07 +0100

Hi Lilla, I send you the modified test/bug1826 that can register T1, T2 and dti images to each other last wednesday via e-mail since I don't have the rights to write to test folder. I was wondering if you got the e-mail and testing it or did it fall to your spam folder ?


Lilla Magyari - 2012-11-28 10:34:54 +0100

(In reply to comment #16) hi Umit, sorry for not replying at all! I got it and I am busy with testing your script. I had a bit of an issue with figuring out the right path to the FSL functions. But I can run it now and next issue is that I got slightly different screen outputs when I was running your script with different versions of FSL (when I was running it with fsl 4.1.7, I got an error message on the screen, but I still had a T2_aligned matlab variable.) How do you check if the alignment went well? Do you check it? or is it possible to check it? Lilla


Lilla Magyari - 2012-11-28 11:16:51 +0100

(In reply to comment #17) hi Umit, I got this on the matlab screen running the T1-T2 alignement with fsl 4.1 The following COMPULSORY options have not been set: -w,--warp filename for warp/coefficient (volume) *************************************************** Part of FSL (build 413) applywarp (Version 1.2) Copyright(c) 2001, University of Oxford (Mark Jenkinson) Usage: applywarp -i invol -o outvol -r refvol -w warpvol applywarp -i invol -o outvol -r refvol -w coefvol Compulsory arguments (You MUST set one or more of): -i,--in filename of input image (to be warped) -r,--ref filename for reference image -w,--warp filename for warp/coefficient (volume) -o,--out filename for output (warped) image Optional arguments (You may optionally specify one or more of): --abs treat warp field as absolute: x' = w(x) --rel treat warp field as relative: x' = x + w(x) -d,--datatype Force output data type [char short int float double]. -s,--super intermediary supersampling of output, default is off --superlevel level of intermediary supersampling, a for 'automatic' or integer level. Default = 2 --premat filename for pre-transform (affine matrix) --postmat filename for post-transform (affine matrix) -m,--mask filename for mask image (in reference space) --interp interpolation method {nn,trilinear,sinc} -v,--verbose switch on diagnostic messages -h,--help display this message But the alignement still happens (at least I end up with a T2_aligned variable in matlab workspace which has an anatomy field different from the original T2 image. Is this something to worry about or is this how you are doing the alignement usually as well? Lilla


Robert Oostenveld - 2012-11-28 11:20:54 +0100

Perhaps this helps for debugging: You should be able to use mricro, mricron, or fslview to look at the (temporary) files on that are written.


Ümit Aydin - 2012-11-28 16:44:59 +0100

What I understood from this error is it wants you to supply a warp field and since it does not find, it gives an error. At the code we do not use the non-linear registration itself but just use the interpolation option of it for spline. With my current fsl4.1.7 version it also works without supplying it a warp field, and just uses the linear transformation matrix and the spline interpolation option. I will check if they changed something in the usage. But your version is also 4.1.7 right then there should not be any problem with that? Did you check the option trilinear for the registrations where we do not use the applywarp option. What you saw as aligned in workspace is probably the registration with trilinear interpolation. Since the steps are: 1)calculate linear transformation matrix, using a trilinear interpolation 2)Calculate spline interpolation with nonlinear registration function using the linear transformation calculated in step 1. So what you see in workspace is the outcome of the step 1. What can be done is also performing this operation with the trilinear option and checking if the results are same just change parameters: cfg.fsl.T2interp='trilinear' cfg.fsl.DTIinterp='trilinear' and run it again. For visualization as Robert suggested you can always use fslview and load the T1 and registered T2 on top of each other. Then by selecting and deselecting them you can compare the registered images. You can type 'fsl4.1-fsl' on the command window and then select the fslview from the graphical user interface. Note: If they are not registered to each other you will not be able to open them on top of each other because it will give the error that their dimensions do not fit.


Ümit Aydin - 2012-11-28 17:10:01 +0100

I checked my version and the applywarp version does also fits version 1.2 and there is does not say that supplying the warp is compulsory. Are you sure if your version is 4.1.7 could it be 4.1.3 because what I saw in your applywarp was written build 413 I would be surprised if they made that kind of a change and they did not even change the version of the tool. Because both of our applywarp version is 1.2. Part of FSL (build 417) applywarp (Version 1.2) Copyright(c) 2001, University of Oxford (Mark Jenkinson) Usage: applywarp -i invol -o outvol -r refvol -w warpvol applywarp -i invol -o outvol -r refvol -w coefvol Compulsory arguments (You MUST set one or more of): -i,--in filename of input image (to be warped) -r,--ref filename for reference image -o,--out filename for output (warped) image Optional arguments (You may optionally specify one or more of): -w,--warp filename for warp/coefficient (volume) --abs treat warp field as absolute: x' = w(x) --rel treat warp field as relative: x' = x + w(x) -d,--datatype Force output data type [char short int float double]. -s,--super intermediary supersampling of output, default is off --superlevel level of intermediary supersampling, a for 'automatic' or integer level. Default = 2 --premat filename for pre-transform (affine matrix) --postmat filename for post-transform (affine matrix) -m,--mask filename for mask image (in reference space) --interp interpolation method {nn,trilinear,sinc,spline} -v,--verbose switch on diagnostic messages -h,--help display this message


Lilla Magyari - 2012-11-29 11:44:52 +0100

(In reply to comment #21) hi Umit, thanks for the reply. I'll check what is happening using your suggestions. Lilla


Jan-Mathijs Schoffelen - 2012-12-05 11:03:30 +0100

Good link to read about Flirt: http://www.fmrib.ox.ac.uk/fslcourse/lectures/reg.pdf


Jan-Mathijs Schoffelen - 2012-12-05 11:48:08 +0100

Hi all, I updated the test script and ft_volumerealign. flirt can now be called from ft_volumerealign when providing in the input a third argument, which is the target volume: ft_volumerealign(cfg, T2, T1); % coregister the T2 to the T1 image. I am working on the 4D DTI images now, but that seems a bit more involved. To further do: -support reslicing of 4D nifties -support cfg.fsl.reslice = false (don't reslice the output volume but update the transformation matrix -come up with a set of clever defaults: e.g. for intra modality other defaults are needed than for across modality. -consider a cfg.modality option that can deal with this (or cfg.modalitytarget and cfg.modalityinput or so).


Robert Oostenveld - 2012-12-13 11:34:00 +0100

This is a reminder for Lilla: the dimensions to consider for testing are within versus between modalities (i.e. T1, T2, DTI, FA) within versus between subjects linear versus non-linear deformations whether to reslice or not To make a single subject FEM model, within subject between modality realignment with reslicing would be desired.


Lilla Magyari - 2012-12-16 00:29:14 +0100

(In reply to comment #24) This is a reaction on the issue of "sensible" combinations configuration options. I run fsl (with the new implementation of the ft_volumerealign function) with 'trilinear' interpolation method with the 5 cost-functions. My input was the T1 and the T2 that Umit sent us but I applied a 15 degrees rotation along the y axis on the T2 (in order to see the actual differences between T1 and T2). You can find attached the images of the aligned volumes with the different cost functions. Apparently, the "least square" led to volume which is still slightly rotated. And the "normcorr" volume looks to be aligned but a it looks slightly different (see image on the left lower corner). All the others look OK, I think. Lilla


Lilla Magyari - 2012-12-16 00:38:26 +0100

(In reply to comment #26) sorry, I can't attach the images yet. Somehow, jpeg or png images do not get saved in the right way at the moment.


Lilla Magyari - 2012-12-16 13:04:07 +0100

(In reply to comment #27) While I was reading the slideshow (link is in one of JM's earlier comments), I see on slide 60 that the "least square" and "normalized correlation" cost-functions are applicable only for alignment (with linear transformation) between images with the same modality.


Ümit Aydin - 2012-12-19 15:29:18 +0100

(In reply to comment #28) Yes, Least squares and Normalized correlations will not be useful for T2 to T1 MRI registration. I think using mutual information as the default cost function is a good idea. One note: although FA images are produced from DTI images. When one is willing to register the FA image it is usually advisable to register it to the T1 and not to T2 (Because the FA image shows mainly high values in the white matter, and white-grey matter distinction is not very good in T2 images). So just writing the FA image name instead of the T2 image name in the test file will work for that purpose.