Hi Bruce, 
Thanks for the reply. So I will do recon-all -talairach for all subjects
using version 4.30 and obtain the new eTIV, keeping the segmentation and
surface data unchanged. Is that the correct way? And can someone please help
me with problem #1?

Thanks,
Zheng Hui


On 8/4/09 20:51, "Bruce Fischl" <fis...@nmr.mgh.harvard.edu> wrote:

> Hi Zheng,
> 
> I'll leave 2 for Nick. As for 1, we don't use the tal very much, and a
> bad tal will not affect your thickness estimates. The newer versions
> rarely have a bad tal since we changed over to Avi Synder's code (which
> also fixes the problems we had with eTIV). You can manually correct it
> using tkregister2, although this is probably only needed if you want to
> report tal coords (or average in tal space).
> 
> cheers,
> Bruce
> 
> On Wed, 8 Apr 2009, gmszh wrote:
> 
>> Hi all,
>> 
>> I have two problems here.
>> 
>> 1. talairach.xfm
>>    By browsing through the mailing list, it seems that talairach.xfm was
>> not used much in the recon-all process which is quite different from the
>> table given at
>> https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllFilesVsSteps. We did find
>> many subjects with bad talairach transformation but reasonable segmentation
>> and surface reconstruction (version 3.05). Are the results (volumes and
>> cortical thickness) for those subjects still trustworthy? Can you kindly
>> clarify the importance of talairach.xfm in the pipeline? And since the new
>> method of eTIV uses this transformation, is there any way to ensure manual
>> registration is fine enough to be used for this estimation, if I have to
>> manually register those subjects mentioned above?
>> 
>> 2. recon-all -long
>>    We processed our data with the longitudinal pipeline. So far we only
>> found 6 subjects failed among 200 subjects (tp1 corrected). All these 6
>> subjects seemed to have problem during the registration from tp2 to tp1. I
>> used the command "tkmedit -f tp2.long.tp1/mri/orig.mgz -aux
>> tp2.long.tp1/mri/orig_tp1_to_tp2.long.tp1.mgz" and realized they were not
>> aligned. I have tried different cost functions using
>> "fsl_rigid_registration". All of them gave the same result. Is there any way
>> I can do the manual registration? I used "fsl_rigid_registration" because no
>> matter which cost function I specified to recon-all -long, it would call
>> "fsl_rigid_registration" with corratio as the cost function.
>> 
>> Thanks in advance,
>> Zheng Hui
>> 
>> _______________________________________________
>> 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

Reply via email to