Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
it's also worth noting that version 4 comes with Avi Snyder's most excellent talairaching instead of the one we used to use, which in our experience is *extremely* accurate and Robust (thanks Avi!).
Bruce
On Thu, 11 Oct 2007, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Yes, based on a small N, version 4 does seem much more robust.
So, if we wanted accurate .xfm's without requiring manual editing, would it be appropriate/fair to use v4 for autorecon1, but then use v3.0.5 for autorecon2 and 3, so as to maintain compatibility with other data processed under v3?
thanks, Mike H.
On Thu, 2007-10-11 at 17:30 -0400, Bruce Fischl wrote:
it's also worth noting that version 4 comes with Avi Snyder's most excellent talairaching instead of the one we used to use, which in our experience is *extremely* accurate and Robust (thanks Avi!).
Bruce
On Thu, 11 Oct 2007, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
you could just rerun the tals with version 4 if you want. On Fri, 12 Oct 2007, Michael Harms wrote:
Yes, based on a small N, version 4 does seem much more robust.
So, if we wanted accurate .xfm's without requiring manual editing, would it be appropriate/fair to use v4 for autorecon1, but then use v3.0.5 for autorecon2 and 3, so as to maintain compatibility with other data processed under v3?
thanks, Mike H.
On Thu, 2007-10-11 at 17:30 -0400, Bruce Fischl wrote:
it's also worth noting that version 4 comes with Avi Snyder's most excellent talairaching instead of the one we used to use, which in our experience is *extremely* accurate and Robust (thanks Avi!).
Bruce
On Thu, 11 Oct 2007, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Mike,
I think it is perfectly acceptable to use the talairach.xfm file generated for a subject by v4 for use with v3.0.5 processing. There is no difference in the file format, it is just more accurate. Another feature in v4 is a check of the talairach.xfm file against a set of known-good alignments (-tal-check), so if your subjects pass 'recon-all -s <subj> -talairach -tal-check' with v4, then you can be assured that the talairach.xfm is as good as you can get.
Nick
On Fri, 2007-10-12 at 09:30 -0500, Michael Harms wrote:
Yes, based on a small N, version 4 does seem much more robust.
So, if we wanted accurate .xfm's without requiring manual editing, would it be appropriate/fair to use v4 for autorecon1, but then use v3.0.5 for autorecon2 and 3, so as to maintain compatibility with other data processed under v3?
thanks, Mike H.
On Thu, 2007-10-11 at 17:30 -0400, Bruce Fischl wrote:
it's also worth noting that version 4 comes with Avi Snyder's most excellent talairaching instead of the one we used to use, which in our experience is *extremely* accurate and Robust (thanks Avi!).
Bruce
On Thu, 11 Oct 2007, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Is talairach.xfm even used as input for any stage of autorecon2 or 3? (Or, is it just the talairach.lta and talairach.m3z files?)
thanks, Mike H.
On Thu, 2007-10-11 at 16:28 -0400, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Hi Mike,
it is used a bit in mri_fill I think, although it might actually have been removed now that we use the aseg. There is also the option of using it to initialize the spherical morph, but that is disabled by default, so it's not used very much. Generally as long as it's not dramatically wrong it won't effect the processing, but will of course mean the tal coords you report are wrong.
cheers, Bruce On Fri, 12 Oct 2007, Michael Harms wrote:
Is talairach.xfm even used as input for any stage of autorecon2 or 3? (Or, is it just the talairach.lta and talairach.m3z files?)
thanks, Mike H.
On Thu, 2007-10-11 at 16:28 -0400, Doug Greve wrote:
It is not that important from a recon standpoint. However, if you intend to report talairach coods, create an average surface, or use that talairach transform in any way, it will be a problem.
doug
Michael Harms wrote:
Hello, We are running FS v3.0.5 on some elderly brains, and the talairach transform (as assessed via tkregister2 with fstal flag) is inaccurate in an appreciable number of the scans we have examined so far. Frequently, the inaccuracies involve primarily scaling or translation, although in one instance the rotation was way-off (such that the cardinal axes were basically swapped). However, even for this worst case, the white and pial surfaces, as well as the aseg, look reasonable. (I haven't run autorecon3 to create the surface parcellations yet).
To what extent is talairach.xfm important for the autorecon2 & 3 stages? If surfaces and aseg look ok, can an inaccurate talairach.xfm just be ignored if we are not going to be averaging functional data? Will the surface parcellations perhaps be affected somehow?
Looking at ReconAllDevTable it appears that talairach.lta and talairach.m3z are the primary inputs to stages 2 and 3. So, I'm wondering how the .xfm relates to the .lta and .m3z files...?
Lastly, the particularly bad .xfm under v3.0.5 looks fine when created using v4.0.1. If we need or want accurate .xfm's would it be appropriate to run autorecon1 under v4 but then switch to v3 for autorecon2 & 3 so as to maintain compatibility with other subjects processed under v3?
thanks, Mike H.
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Bruce Fischl -
Doug Greve -
Michael Harms -
Nick Schmansky