I’m following the HCP connectome tutorial and I’ve some questions related with the parcellation step.
I have used the freesurfer’s parcellation running the labelconvert command and it worked OK.
Now, I want to do the same but using the AAL’s LUT, my problem is that I don’t have the subject’s brain parcellated with AAL atlas, so how do you use this LUT? what is your input image in labelconvert when your LUT is the aal.txt file? I only have a template of the AAL atlas and I tried with FreeSurfer but there is no command to change and use it.
Using FreeSurfer v.s. AAL parcellations for connectome construction require a considerably different set of steps (and one wouldn’t typically ‘instruct’ FreeSurfer to use the AAL parcellation even if it’s technically possible, which I’m not sure if it is).
There’s really two separate steps of interest that you need to deal with:
Getting the AAL template parcellation into subject space;
If necessary, converting the AAL parcel indices so that they form a continuous set from 1 upwards.
The first step is dealt with using image registration tools; there’s been a couple of discussions on this forum regarding the appropriate steps here, this post is all I can find right now though. The second step is dealt with using labelconvert, and its order with respect to the first step shouldn’t really matter.
Hi Rob, thanks for the response!
I’ll try this and then I’ll probably come back!
A few days ago (before your response) I tried to registrated the AAL template to my dwi image (using flirt) and then I ran labelconvert. When I tried to visualize the output as node image with the connectome tool of mrview, I got this: Qt has caught an exception thrown from an event handler. Throwing exceptions from an event handler is not supported in Qt. You must reimplement QApplication::notify() and catch all exceptions there.
terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc [1] 3443 abort (core dumped) mrview
Having in mind what you posted, this isn’t the correct way to use the AAL atlas!
In the last one, I applied the transformation image (warp2.nii) to the template to obtain it in the subject’s space.
The resulting image is not the best, obviously. Also I probed more options in -type input (affine, rigid) but I didn’t obtain better results. Attached are two screenshots: one of the AAL template in its space and the other one in the subject’s space. Any ideas on how could I improve this? May be the aal parcellation is the problem?
I would focus entirely on using mrregister -type rigid for now. Using -type nonlinear will only perform updates to the non-linear warp field, and assume no linear transformation; so if your subject image and the AAL template image don’t line up whatsoever, the nonlinear updates have no chance of fixing that gross misalignment. Once you have rigid body registration working adequately, you can then have a go at higher-order registrations.
Since mrregister currently only has a least-squares difference metric, even when working with two images of the same modality the overall image intensities need to be comparable. If your subject T1 image has values ranging from 0-1,000, but the AAL template T1 image has values ranging from 0-10,000, the registration is almost certain to fail.
label2colour will make your parcellation images look much nicer
Step 4:
Next, I created the LUT file. and I executted the labelconvert command.
But unfortunately, the obtained AAL atlas was discontinuous.
The original value of AAL file was continuous, then I think this error was caused.
If anyone know the solution to overcome this error, please explain it.
Firstly, you may want to consider trying 12 degrees of freedom for the T1 → MNI template registration. 6 degrees of freedom is really for intra-subject registration; you can see in some of your images that there are still clear gross misalignments between your subject-s T1 image and the overlaid parcels, probably due to the fact that your registration doesn’t include scaling components.
Regarding this:
Next, I created the LUT file. and I executted the labelconvert command.
But unfortunately, the obtained AAL atlas was discontinuous.
The original value of AAL file was continuous, then I think this error was caused.
If anyone know the solution to overcome this error, please explain it.
It’s not entirely clear what the problem is that you’re encountering; I’ll make a couple of stabs in the dark, but if I don’t hit the mark you’ll need to explain the issue more precisely.
Your registration of AAL parcellation to subject space appears to be using tri-linear interpolation. For re-gridding a parcellation image, nearest-neighbour interpolation must be used.
For label images being used in connectome construction, tck2connectome expects an image where the label numbers increment continuously from 1 upwards. This is the purpose of the labelconvert command: to manipulate any arbitrary label image into this form. I have however seen the AAL image provided via some sources where the image values already increment continuously from 1; if this is the case for you, then the labelconvert step may not be necessary for your data.
If none of this makes sense to you, there’s a page in the online documentation that will hopefully help explain the purpose of this command, how it works, and therefore possibly how to get it to work for your data.
I have the same problem as Takafumi even when I use the nearest-neighbour interpolation.
I realized is that when I use mrview to visualize the AAL atlas it has decimal value in the border of 2 regions (screenshot 1), but if I open the image with fslview I only found integer values of intensity (which is more appropiate). Moreover, when I visualize the final image (after the flirt and labelconvert commands) it looks like Takafumi’s one: with mrview I find decimal values (but not zeros between regions) (screenshot 2) and with fslview I find only integer values for intensity and zeros between the regions (screenshot 3).
Why are the differences? “Value” for mrview and “intensity” for fslview are not the same?
Is that an issue of visualization?
your observation is probably related to the fact that there is interpolation on by default in mrview.
By switching interpolation off the voxels in my case contain only integer values and mrview screenshot of loaded AAL looks like this:
Hi Antonin,
Thanks! You’re right about the interpolation, now I have only integer values, that was so simple.
I still have the issue with the parcellated image, it isn’t continous: I have zeros in the borders of the regions. Any ideas?
Can you break up the steps and determine exactly which command is responsible for introducing the discontinuities (i.e. flirt or labelconvert)?
It will be an interpolation issue somewhere: any voxel for which non-nearest-neighbour interpolation would typically be sampling different values from the surrounding voxels is failing to take “fractions of integers” from those surrounding voxels, and instead yielding zero. The most likely solution is a bit of image type casting gymnastics between integer and floating-point; but it depends on which of those two commands is producing the problem as to where those type conversions need to take place.
I’m trying to determine the responsable command.
I did the following steps:
I run labelconvert directly on the aal atlas (without registering with the subject, so I didn’t use the flirt command), the output hasn’t discontinuities.
On the other hand, as I said in the previous message, the discontinuities appeared in the output of the labelconvert command after doing the registration with flirt (using the nearest neighbour interpolation).
show the AAL parcellation image after resampling to individual space, but before labelconvert, with showing the example voxel values in offending discontinuous areas (with mrview interpolation off)
Invert the matrix convert_xfm -inverse T12AAL_nn.mat -omat AAL2T1_nn.mat
Apply the inverted matrix: flirt -in aal_template.nii -ref T1_betnii -applyxfm -init AAL2T1_nn.mat -out AAL2T1_nn.nii
So here I have the AAL parcellation in the subject’s space, it hasn’t discontinuous areas yet.
In the next screenshot I show the AAL2T1_nn.nii with the nodos_AAL_nn.nii overlayed, with the interpolation option off and pointing a specific discontinuity in the node image.
On the other hand, I tried this just to see what happens:
Case 2: Run the labelconvert command directly on the AAL template, without moving it to the subject’s space. labelconvert aal_template.nii aal_mapping.txt aal.txt nodos_aal_template.nii
I guess that your problem is that in the step 3 the nearest neighbour interpolation is not applied. Try to add also -interp nearestneighbour to your step 3 and see if that fixes your problem.
Could you please provide an example of the aal_mapping.txt you have used?
Normally the AAL atlas comes with a file called e.g. “ROI_MNI_V4.txt”, which contains the indices and names of parcels in the atlas (a “lookup table”). However AAL can be acquired in a few different ways, and so the lookup table may be different / have a different name. Look for something like this that has come with the AAL atlas however you have acquired it:
I was wondering why you use the inverse transform (from subject’s T1 to aal first and do a inverse transform) while not transform the aal to subject’s T1 directly.
I tried both and it seems transforming the aal to subject’s T1 directly works better than the inverse transform. Is there any specific reason for doing an inverse transform or did I miss something?
Fig 1 is the inverse transform and Fig 2 is the direct transform, both are overlaid on mean-b0 image. Nearestneighbour interpolation and 12 dof were used in both cases.
I was wondering why you use the inverse transform (from subject’s T1 to aal first and do a inverse transform) while not transform the aal to subject’s T1 directly.
I think it’s a purely historical thing; people regularly think of “normalisation” as being the combination of registering a subject’s data to the template / transforming the subject’s image data toward the template / resampling the subject’s image data onto the voxel grid of the template. (We tend to avoid using “normalise” in this way, partly because of needing to discriminate between these three things, partly to avoid conflation with intensity normalisation).
If the registration is genuinely symmetrical, and if the inversion of the transformation is without error (though it should be obtained implicitly if the registration is genuinely symmetrical), then there should be no difference in outcome between registering “in one direction” and then inverting vs. registering “in the other direction”. The fact that you’ve demonstrated this to not be the case for your data proves that one of these assumptions is breaking down. Which is interesting, it’s not something I’ve looked at experimentally or recall reading a great deal about.
Though I would follow up by saying that I’m nowadays sceptical of using only affine registration between subject and template. If a similar effect were to be occurring for nonlinear registration, and this were demonstrated to be the case across multiple subjects, then recommendations would potentially need to be revised.
