Hi Matt, Bruce,

The problems are indeed a flirt issue, but given that it's programmed with --init-fsl there is not much flexibility.

However, from a FS point of view, it might be a better and more robust approach to first register FLAIRraw.mgz to raw.mgz, and then concatenate the resulting registration with the (header based) registration from raw.mgz to orig.mgz - instead of trusting the robustness of either registration algorithms.

... or, as Matt suggests, fix the image axes appropriately after converting the FLAIR to mgz, and then run the registration. But I'm not sure how to do that.

Best,

Martijn

On Thu, Nov 14, 2013 at 5:53 PM, Bruce Fischl <fischl@nmr.mgh.harvard.edu> wrote:

Hi Martijn

we can print warning and errors if FSLDIR is not set, but the registration errros seem to be mostly a flirt issue, no? Have you posted on the FSL list?

Bruce

On Thu, 14 Nov 2013, Martijn Steenwijk wrote:

Dear all,
There seem to be some serious issues with the T2pial / FLAIRpial processing
options provided in the latest versions of FreeSurfer.

First of all, although not clearly documented, T2pial / FLAIRpial processing
does require the FSLDIR to be set (in order to use bbregister with
--init-fsl). If not set, recon-all will finish just without using the T2 or
FLAIR information. Importantly, no clear warning about this is given
although the user expects that T2/FLAIR has been used for pial surface
refinement. I think this is a very easy source of errors, so it might be a
good idea to just throw an error when FSLDIR is missing and T2pial/FLAIRpial
processing is requested.

Second, if FSLDIR has been set. T2pial/FLAIRpial uses bbregister with FLIRT
initialisation to align the T2 or FLAIR image to orig.mgz. However, we have
some high-res 3DFLAIR data in which this registration (more specifially, the
FLIRT initialisation step of bbregister) seems to fail in more than half of
the cases. Apparently, the FSL initialisation is not capable to change the
orientation such that it fits to the coordinate system used for orig.mgz.
Again, no warning or error is thrown, but the processing just continues with
the wrong registration and without noticing the results will get worse
compared to not using T2 or FLAIR.
Although I know its essential to look at the output data; would it be
possible to put some effort in letting the user know that things got wrong?

As a sidenote; I tried to fix this registration issue, but it seems to be
very complicated using bbregister (other than just inserting my own
registration obtained by using FLIRT to register native FLAIR to native T1,
and subsequently transform the result to Freesurfer space in order to obtain
FLAIR.mgz).

Best,
Martijn

The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.