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
