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
To fix the second problem, why not reorient the T2w image so the image axes are oriented in the way that FreeSurfer expects?
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 8:13 AM To: freesurfer freesurfer@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl Subject: [Freesurfer] T2pial/FLAIRpial processing issues
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 _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
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
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.eduwrote:
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.
I think you can do it with mri_convert rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
Hi Matt
hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we "conform", so the info should be there for flirt
cheers Bruce
On Thu, 14 Nov 2013, Matt Glasser wrote:
I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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, MartijnThe 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
So the T2w image is already having the axes realigned to RAS with mri_convert in FreeSurfer prior to running -init-fsl? If that is the case, FLIRT should work well enough assuming the input orientation information in the T2w and T1w NIFTI headers was accurate. I suppose you could also restrict the -searchxyz angles to +/-30 degrees to keep FLIRT from making large (and incorrect if the axes are aligned) image rotations.
Peace,
Matt.
On 11/14/13 9:52 AM, "Bruce Fischl" fischl@nmr.mgh.harvard.edu wrote:
Hi Matt
hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we "conform", so the info should be there for flirt
cheers Bruce
On Thu, 14 Nov 2013, Matt Glasser wrote:
I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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, MartijnThe 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with
tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk
If that looks ok, then it is possible that flirt is just failing.
Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed.
doug
On 11/14/2013 12:52 PM, Bruce Fischl wrote:
Hi Matt
hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we "conform", so the info should be there for flirt
cheers Bruce
On Thu, 14 Nov 2013, Matt Glasser wrote:
I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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, MartijnThe 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Dear all,
Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk
Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz.
mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug.
Best, Martijn
On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve greve@nmr.mgh.harvard.eduwrote:
It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with
tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk
If that looks ok, then it is possible that flirt is just failing.
Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed.
doug
On 11/14/2013 12:52 PM, Bruce Fischl wrote:
Hi Matt
hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we "conform", so the info should be there for flirt
cheers Bruce
On Thu, 14 Nov 2013, Matt Glasser wrote:
I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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, MartijnThe 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
I digged further into this.
The scale difference previously reported is not true. It is only a translation error.
It looks like that the orig.mgz has (0,0,0) in the center of the image; while FLAIRraw (after header-only registration) has the origin at index (0,0,0) - so in one of the corners of the volume. This means the initial (header based) transformation provided to flirt is also not correct.
On Fri, Nov 15, 2013 at 12:49 PM, Martijn Steenwijk < martijnsteenwijk@gmail.com> wrote:
Dear all,
Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk
Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz.
mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug.
Best, Martijn
On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve < greve@nmr.mgh.harvard.edu> wrote:
It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with
tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk
If that looks ok, then it is possible that flirt is just failing.
Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed.
doug
On 11/14/2013 12:52 PM, Bruce Fischl wrote:
Hi Matt
hopefully Doug will chime in, but I don't see why that is the case. We preserve all the RAS information when we "conform", so the info should be there for flirt
cheers Bruce
On Thu, 14 Nov 2013, Matt Glasser wrote:
I think you can do it with mri_convert ?rl. I don't think it makes sense to expect FLIRT to get the registration right reliably if the axes are off (in the HCP Pipelines we definitely don't expect this and make sure all images are RPI before processing them).
Peace,
Matt.
From: Martijn Steenwijk martijnsteenwijk@gmail.com Date: Thursday, November 14, 2013 9:27 AM To: Bruce Fischl fischl@nmr.mgh.harvard.edu Cc: Veronica Popescu v.popescu@vumc.nl, Hugo Vrenken h.vrenken@vumc.nl, freesurfer freesurfer@nmr.mgh.harvard.edu Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues
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, MartijnThe 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.
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
were these acquired in the same session? If so, were they converted to mgz directly from dicom?
On 11/15/2013 10:15 AM, Martijn Steenwijk wrote:
I digged further into this.
The scale difference previously reported is not true. It is only a translation error.
It looks like that the orig.mgz has (0,0,0) in the center of the image; while FLAIRraw (after header-only registration) has the origin at index (0,0,0) - so in one of the corners of the volume. This means the initial (header based) transformation provided to flirt is also not correct.
On Fri, Nov 15, 2013 at 12:49 PM, Martijn Steenwijk <martijnsteenwijk@gmail.com mailto:martijnsteenwijk@gmail.com> wrote:
Dear all, Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz. mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug. Best, Martijn On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk If that looks ok, then it is possible that flirt is just failing. Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed. doug On 11/14/2013 12:52 PM, Bruce Fischl wrote: > Hi Matt > > hopefully Doug will chime in, but I don't see why that is the case. We > preserve all the RAS information when we "conform", so the info should > be there for flirt > > cheers > Bruce > > > On Thu, 14 Nov 2013, Matt Glasser wrote: > >> I think you can do it with mri_convert ?rl. I don't think it makes >> sense to >> expect FLIRT to get the registration right reliably if the axes are >> off (in >> the HCP Pipelines we definitely don't expect this and make sure all >> images >> are RPI before processing them). >> >> Peace, >> >> Matt. >> >> From: Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>> >> Date: Thursday, November 14, 2013 9:27 AM >> To: Bruce Fischl <fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu>> >> Cc: Veronica Popescu <v.popescu@vumc.nl <mailto:v.popescu@vumc.nl>>, Hugo Vrenken >> <h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl>>, >> freesurfer <freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu>> >> Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues >> >> 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 <mailto: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. >> >> >> _______________________________________________ Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. >> > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Yes, they were acquired in the same session, but using a slightly different FOV. They were converted from dicom to nifti using dcm2nii and then used for FS analysis.
The axis orientation of the images is the same. Extensive image analysis (including registration of FLAIR and T1 using FLIRT) has been run on these images, but I never faced such a problem.
Is it possible that left/right orientation is is flipped by FLIRT due to the initial misalignment?
On Fri, Nov 15, 2013 at 6:45 PM, Douglas N Greve greve@nmr.mgh.harvard.eduwrote:
were these acquired in the same session? If so, were they converted to mgz directly from dicom?
On 11/15/2013 10:15 AM, Martijn Steenwijk wrote:
I digged further into this.
The scale difference previously reported is not true. It is only a translation error.
It looks like that the orig.mgz has (0,0,0) in the center of the image; while FLAIRraw (after header-only registration) has the origin at index (0,0,0) - so in one of the corners of the volume. This means the initial (header based) transformation provided to flirt is also not correct.
On Fri, Nov 15, 2013 at 12:49 PM, Martijn Steenwijk < martijnsteenwijk@gmail.com mailto:martijnsteenwijk@gmail.com> wrote:
Dear all, Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz. mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug. Best, Martijn On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> wrote: It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk If that looks ok, then it is possible that flirt is just failing. Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed. doug On 11/14/2013 12:52 PM, Bruce Fischl wrote: > Hi Matt > > hopefully Doug will chime in, but I don't see why that is the case. We > preserve all the RAS information when we "conform", so the info should > be there for flirt > > cheers > Bruce > > > On Thu, 14 Nov 2013, Matt Glasser wrote: > >> I think you can do it with mri_convert ?rl. I don't think it makes >> sense to >> expect FLIRT to get the registration right reliably if the axes are >> off (in >> the HCP Pipelines we definitely don't expect this and make sure all >> images >> are RPI before processing them). >> >> Peace, >> >> Matt. >> >> From: Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>> >> Date: Thursday, November 14, 2013 9:27 AM >> To: Bruce Fischl <fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu>> >> Cc: Veronica Popescu <v.popescu@vumc.nl <mailto:v.popescu@vumc.nl>>, Hugo Vrenken >> <h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl>>, >> freesurfer <freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu>> >> Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues >> >> 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 <mailto: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. >> >> >> _______________________________________________ Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. >> > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
Can you convert the two to mgz or nii with mri_convert and then run tkregister2? If they were acquired in the same session, then the geometric information in the header should bring them into close registration regardless of voxel size, orientation, field of view, etc. mri_convert should preserve this information. dcm2nii should do the same thing, but I did not write it so I don't know what it is doing:).
On 11/15/2013 01:15 PM, Martijn Steenwijk wrote:
Yes, they were acquired in the same session, but using a slightly different FOV. They were converted from dicom to nifti using dcm2nii and then used for FS analysis.
The axis orientation of the images is the same. Extensive image analysis (including registration of FLAIR and T1 using FLIRT) has been run on these images, but I never faced such a problem.
Is it possible that left/right orientation is is flipped by FLIRT due to the initial misalignment?
On Fri, Nov 15, 2013 at 6:45 PM, Douglas N Greve <greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu> wrote:
were these acquired in the same session? If so, were they converted to mgz directly from dicom? On 11/15/2013 10:15 AM, Martijn Steenwijk wrote: I digged further into this. The scale difference previously reported is not true. It is only a translation error. It looks like that the orig.mgz has (0,0,0) in the center of the image; while FLAIRraw (after header-only registration) has the origin at index (0,0,0) - so in one of the corners of the volume. This means the initial (header based) transformation provided to flirt is also not correct. On Fri, Nov 15, 2013 at 12:49 PM, Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com> <mailto:martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>>> wrote: Dear all, Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz. mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug. Best, Martijn On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>>> wrote: It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk If that looks ok, then it is possible that flirt is just failing. Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed. doug On 11/14/2013 12:52 PM, Bruce Fischl wrote: > Hi Matt > > hopefully Doug will chime in, but I don't see why that is the case. We > preserve all the RAS information when we "conform", so the info should > be there for flirt > > cheers > Bruce > > > On Thu, 14 Nov 2013, Matt Glasser wrote: > >> I think you can do it with mri_convert ?rl. I don't think it makes >> sense to >> expect FLIRT to get the registration right reliably if the axes are >> off (in >> the HCP Pipelines we definitely don't expect this and make sure all >> images >> are RPI before processing them). >> >> Peace, >> >> Matt. >> >> From: Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com> <mailto:martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>>> >> Date: Thursday, November 14, 2013 9:27 AM >> To: Bruce Fischl <fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu> <mailto:fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu>>> >> Cc: Veronica Popescu <v.popescu@vumc.nl <mailto:v.popescu@vumc.nl> <mailto:v.popescu@vumc.nl <mailto:v.popescu@vumc.nl>>>, Hugo Vrenken >> <h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl> <mailto:h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl>>>, >> freesurfer <freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu> <mailto:freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu>>> >> Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues >> >> 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 <mailto:fischl@nmr.mgh.harvard.edu> <mailto:fischl@nmr.mgh.harvard.edu <mailto: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. >> >> >> _______________________________________________ Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. >> > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> Phone Number: 617-724-2358 <tel:617-724-2358> <tel:617-724-2358 <tel:617-724-2358>> Fax: 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 <tel:617-726-7422>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
Allright; I digged further and further...., and finally found out that the sform of our T1 weighted image gets crushed during a lesion filling step earlier in the pipeline. I never recognized this while using FLIRT, maybe because FLIRT uses a different initialization (COG?) than using the header transformation as an initial registration...
Anyway, thanks for all the help. It still would be helpfull (I think) to have some kind of QC step in there which could warn if things got wrong.
Best, Martijn
On Fri, Nov 15, 2013 at 7:52 PM, Douglas N Greve greve@nmr.mgh.harvard.eduwrote:
Can you convert the two to mgz or nii with mri_convert and then run tkregister2? If they were acquired in the same session, then the geometric information in the header should bring them into close registration regardless of voxel size, orientation, field of view, etc. mri_convert should preserve this information. dcm2nii should do the same thing, but I did not write it so I don't know what it is doing:).
On 11/15/2013 01:15 PM, Martijn Steenwijk wrote:
Yes, they were acquired in the same session, but using a slightly different FOV. They were converted from dicom to nifti using dcm2nii and then used for FS analysis.
The axis orientation of the images is the same. Extensive image analysis (including registration of FLAIR and T1 using FLIRT) has been run on these images, but I never faced such a problem.
Is it possible that left/right orientation is is flipped by FLIRT due to the initial misalignment?
On Fri, Nov 15, 2013 at 6:45 PM, Douglas N Greve < greve@nmr.mgh.harvard.edu mailto:greve@nmr.mgh.harvard.edu> wrote:
were these acquired in the same session? If so, were they converted to mgz directly from dicom? On 11/15/2013 10:15 AM, Martijn Steenwijk wrote: I digged further into this. The scale difference previously reported is not true. It is only a translation error. It looks like that the orig.mgz has (0,0,0) in the center of the image; while FLAIRraw (after header-only registration) has the origin at index (0,0,0) - so in one of the corners of the volume. This means the initial (header based) transformation provided to flirt is also not correct. On Fri, Nov 15, 2013 at 12:49 PM, Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com> <mailto:martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>>> wrote: Dear all, Thanks for all the input. Doug, concerning your suggestion tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk Using this, the axes orientationseem to be correct, but scaling and translation of registered FLAIRraw seem to be way off. (registered FLAIRraw is much larger compared to orig.mgz (in the order of multiple times) and is translated to the radiologically left-caudal part of orig.mgz. mri_convert -rl gives a similar result as using tkregister2 as proposed by Doug. Best, Martijn On Thu, Nov 14, 2013 at 8:38 PM, Douglas N Greve <greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>>> wrote: It should not make a difference. We compute an initial registration based on the header and pass that to FLIRT. Can you verify that this initial registration is correct? You can do that with tkregister2 --mov FLAIRraw.mgz --targ orig.mgz --regheader --reg junk If that looks ok, then it is possible that flirt is just failing. Also, newer versions of FS will use an internal version of flirt and so not reliant on FSLDIR being set or FSL being installed. doug On 11/14/2013 12:52 PM, Bruce Fischl wrote: > Hi Matt > > hopefully Doug will chime in, but I don't see why that is the case. We > preserve all the RAS information when we "conform", so the info should > be there for flirt > > cheers > Bruce > > > On Thu, 14 Nov 2013, Matt Glasser wrote: > >> I think you can do it with mri_convert ?rl. I don't think it makes >> sense to >> expect FLIRT to get the registration right reliably if the axes are >> off (in >> the HCP Pipelines we definitely don't expect this and make sure all >> images >> are RPI before processing them). >> >> Peace, >> >> Matt. >> >> From: Martijn Steenwijk <martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com> <mailto:martijnsteenwijk@gmail.com <mailto:martijnsteenwijk@gmail.com>>> >> Date: Thursday, November 14, 2013 9:27 AM >> To: Bruce Fischl <fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu> <mailto:fischl@nmr.mgh.harvard.edu <mailto:fischl@nmr.mgh.harvard.edu>>> >> Cc: Veronica Popescu <v.popescu@vumc.nl <mailto:v.popescu@vumc.nl> <mailto:v.popescu@vumc.nl <mailto:v.popescu@vumc.nl>>>, Hugo Vrenken >> <h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl> <mailto:h.vrenken@vumc.nl <mailto:h.vrenken@vumc.nl>>>, >> freesurfer <freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu> <mailto:freesurfer@nmr.mgh.harvard.edu <mailto:freesurfer@nmr.mgh.harvard.edu>>> >> Subject: Re: [Freesurfer] T2pial/FLAIRpial processing issues >> >> 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 <mailto:fischl@nmr.mgh.harvard.edu> <mailto:fischl@nmr.mgh.harvard.edu <mailto: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. >> >> >> _______________________________________________ Freesurfer mailing list >> Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> >> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 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. >> > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> <mailto:greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu>> Phone Number: 617-724-2358 <tel:617-724-2358> <tel:617-724-2358 <tel:617-724-2358>> Fax: 617-726-7422 <tel:617-726-7422> <tel:617-726-7422 <tel:617-726-7422>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html>
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/ _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> <mailto:Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer -- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu <mailto:greve@nmr.mgh.harvard.edu> Phone Number: 617-724-2358 <tel:617-724-2358> Fax: 617-726-7422 <tel:617-726-7422> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting <http://surfer.nmr.mgh.harvard.edu/fswiki/BugReporting> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html <http://www.nmr.mgh.harvard.edu/facility/filedrop/index.html> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/-- Douglas N. Greve, Ph.D. MGH-NMR Center greve@nmr.mgh.harvard.edu Phone Number: 617-724-2358 Fax: 617-726-7422
Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2 www.nmr.mgh.harvard.edu/facility/filedrop/index.html Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Douglas N Greve -
Martijn Steenwijk -
Matt Glasser