Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
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.
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
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.
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
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 again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
1) I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
------------------------------------------------------------------------------------------------------------------------------------------ [rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22 ------------------------------------------------------------------------------------------------------------------------------------------
2) I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
3) Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
4) I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
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 Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files. You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
Dear all
I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm).
Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file?
Thanks,
Fred
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 Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one)
On Mon, 29 Apr 2013, Fred Dick wrote:
> Dear all > > I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). > > Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? > > Thanks, > > Fred > > > > > _______________________________________________ > 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 Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
Hi Bruce
I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on.
I originally thought this was from a bad brainmask, but then generated a good one and same thing happening.
On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
> Hi Fred > > we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) > > > On Mon, 29 Apr 2013, Fred Dick wrote: > >> Dear all >> >> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >> >> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >> >> Thanks, >> >> Fred >> >> >> >> >> _______________________________________________ >> 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 Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails On Mon, 29 Apr 2013, Fred Dick wrote:
> Hi Bruce > > I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. > > I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. > > > On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: > >> Hi Fred >> >> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >> >> >> On Mon, 29 Apr 2013, Fred Dick wrote: >> >>> Dear all >>> >>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>> >>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>> >>> Thanks, >>> >>> Fred >>> >>> >>> >>> >>> _______________________________________________ >>> 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 Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails > On Mon, 29 Apr 2013, Fred Dick wrote: > >> Hi Bruce >> >> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >> >> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >> >> >> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >> >>> Hi Fred >>> >>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>> >>> >>> On Mon, 29 Apr 2013, Fred Dick wrote: >>> >>>> Dear all >>>> >>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>> >>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>> >>>> Thanks, >>>> >>>> Fred >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Doug
totally no worries (this hardly counts as a delay!).
I'm running it as
tkregister2 --ltaout tal-out.lta --gca [sub] --check-reg
As you had suggested, the source and dst are switched (in talaiarch.lta, the .gca is the dst, whereas in new output file, it's the src).
Also, the RB...gca is 256 256 256 in the original lta, whereas in the new one (where it's src) it's 128 128 128, which agrees with mri_info output.
cheers, Fred
On 2 May 2013, at 17:13, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
Hi again
different weighting sorta kinda worked better. It might be a dud brain.
But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options.
[btw, running stable 5.2.0 on snow leopard]
- I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this)
[rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl INFO: LTA input is not RAS to RAS...converting... target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca reg file /tmp/reg.tmp.1367946635.dat LoadVol 1 ZeroCRAS 0 $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ Diagnostic Level -1 GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file No such file or directory ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22
I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either)
Then tried another trick that Doug suggested a while ago on the message boards:
tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg
and got "ERROR: Option --lta-inv unknown"
- I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish:
tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ
This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard).
So I'm slightly stymied.
Thanks tons,
Fred
On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote:
> Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! > On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: > >> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails >> On Mon, 29 Apr 2013, Fred Dick wrote: >> >>> Hi Bruce >>> >>> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >>> >>> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >>> >>> >>> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>> >>>> Hi Fred >>>> >>>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>>> >>>> >>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>> >>>>> Dear all >>>>> >>>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>>> >>>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>>> >>>>> Thanks, >>>>> >>>>> Fred >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>> >>> >>>
-- 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/
Hi Fred, so do you still have an outstanding question? doug
On 05/02/2013 12:55 PM, Fred Dick wrote:
Hi Doug
totally no worries (this hardly counts as a delay!).
I'm running it as
tkregister2 --ltaout tal-out.lta --gca [sub] --check-reg
As you had suggested, the source and dst are switched (in talaiarch.lta, the .gca is the dst, whereas in new output file, it's the src).
Also, the RB...gca is 256 256 256 in the original lta, whereas in the new one (where it's src) it's 128 128 128, which agrees with mri_info output.
cheers, Fred
On 2 May 2013, at 17:13, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred
I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files.
Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert:
mri_convert -nth 0 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ label_means.mgz
mri_convert -nth 1 \ /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ labels.mgz
cheers Bruce
On Tue, 30 Apr 2013, Fred Dick wrote:
> Hi again > > different weighting sorta kinda worked better. It might be a dud brain. > > But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options. > > [btw, running stable 5.2.0 on snow leopard] > > 1) I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this) > > > ------------------------------------------------------------------------------------------------------------------------------------------ > [rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar > tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl > INFO: LTA input is not RAS to RAS...converting... > target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz > movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca > reg file /tmp/reg.tmp.1367946635.dat > LoadVol 1 > ZeroCRAS 0 > $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ > Diagnostic Level -1 > GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file > No such file or directory > ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22 > ------------------------------------------------------------------------------------------------------------------------------------------ > > 2) I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either) > > 3) Then tried another trick that Doug suggested a while ago on the message boards: > > tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg > > and got "ERROR: Option --lta-inv unknown" > > 4) I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish: > > tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ > > This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard). > > So I'm slightly stymied. > > Thanks tons, > > Fred > > > > > On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote: > >> Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! >> On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >> >>> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails >>> On Mon, 29 Apr 2013, Fred Dick wrote: >>> >>>> Hi Bruce >>>> >>>> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >>>> >>>> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >>>> >>>> >>>> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>> >>>>> Hi Fred >>>>> >>>>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>>>> >>>>> >>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>> >>>>>> Dear all >>>>>> >>>>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>>>> >>>>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Fred >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>> >>>> > >
-- 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/
Yes - maybe it is an idiotic one, but is there a straightforward way to write out a tkregister-tweaked talaiarch.lta with the correct geometry so that mri_ca_normalize/register will read it right?
On 2 May 2013, at 18:04, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, so do you still have an outstanding question? doug
On 05/02/2013 12:55 PM, Fred Dick wrote:
Hi Doug
totally no worries (this hardly counts as a delay!).
I'm running it as
tkregister2 --ltaout tal-out.lta --gca [sub] --check-reg
As you had suggested, the source and dst are switched (in talaiarch.lta, the .gca is the dst, whereas in new output file, it's the src).
Also, the RB...gca is 256 256 256 in the original lta, whereas in the new one (where it's src) it's 128 128 128, which agrees with mri_info output.
cheers, Fred
On 2 May 2013, at 17:13, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
Hi Bruce
On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
> Hi Fred > > I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files. Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works.
So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta.
Is it the inverse transform with an offset, perhaps?
The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure.
Thanks as always,
Fred
> You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert: > > mri_convert -nth 0 \ > /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ > label_means.mgz > > mri_convert -nth 1 \ > /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ > labels.mgz > > > cheers > Bruce > > > On Tue, 30 Apr 2013, Fred Dick wrote: > >> Hi again >> >> different weighting sorta kinda worked better. It might be a dud brain. >> >> But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options. >> >> [btw, running stable 5.2.0 on snow leopard] >> >> 1) I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this) >> >> >> ------------------------------------------------------------------------------------------------------------------------------------------ >> [rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar >> tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl >> INFO: LTA input is not RAS to RAS...converting... >> target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz >> movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca >> reg file /tmp/reg.tmp.1367946635.dat >> LoadVol 1 >> ZeroCRAS 0 >> $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ >> Diagnostic Level -1 >> GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file >> No such file or directory >> ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22 >> ------------------------------------------------------------------------------------------------------------------------------------------ >> >> 2) I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either) >> >> 3) Then tried another trick that Doug suggested a while ago on the message boards: >> >> tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg >> >> and got "ERROR: Option --lta-inv unknown" >> >> 4) I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish: >> >> tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ >> >> This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard). >> >> So I'm slightly stymied. >> >> Thanks tons, >> >> Fred >> >> >> >> >> On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote: >> >>> Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! >>> On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>> >>>> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails >>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>> >>>>> Hi Bruce >>>>> >>>>> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >>>>> >>>>> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >>>>> >>>>> >>>>> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>>> >>>>>> Hi Fred >>>>>> >>>>>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>>>>> >>>>>> >>>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>>> >>>>>>> Dear all >>>>>>> >>>>>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>>>>> >>>>>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Fred >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> >>>>> >>>>> >> >>
-- 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/
-- 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/
Funny you should mention that. Martin just wrote a program to convert lta's from one type to another. Martin, can you share with Fred? doug
On 05/02/2013 01:13 PM, Fred Dick wrote:
Yes - maybe it is an idiotic one, but is there a straightforward way to write out a tkregister-tweaked talaiarch.lta with the correct geometry so that mri_ca_normalize/register will read it right?
On 2 May 2013, at 18:04, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, so do you still have an outstanding question? doug
On 05/02/2013 12:55 PM, Fred Dick wrote:
Hi Doug
totally no worries (this hardly counts as a delay!).
I'm running it as
tkregister2 --ltaout tal-out.lta --gca [sub] --check-reg
As you had suggested, the source and dst are switched (in talaiarch.lta, the .gca is the dst, whereas in new output file, it's the src).
Also, the RB...gca is 256 256 256 in the original lta, whereas in the new one (where it's src) it's 128 128 128, which agrees with mri_info output.
cheers, Fred
On 2 May 2013, at 17:13, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
Hi Fred,
I'll have to defer to Doug on this Bruce On Tue, 30 Apr 2013, Fred Dick wrote:
> Hi Bruce > > > On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: > >> Hi Fred >> >> I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files. > Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works. > > So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta. > > Is it the inverse transform with an offset, perhaps? > > The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure. > > Thanks as always, > > Fred > > > > > >> You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert: >> >> mri_convert -nth 0 \ >> /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ >> label_means.mgz >> >> mri_convert -nth 1 \ >> /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ >> labels.mgz >> >> >> cheers >> Bruce >> >> >> On Tue, 30 Apr 2013, Fred Dick wrote: >> >>> Hi again >>> >>> different weighting sorta kinda worked better. It might be a dud brain. >>> >>> But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options. >>> >>> [btw, running stable 5.2.0 on snow leopard] >>> >>> 1) I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this) >>> >>> >>> ------------------------------------------------------------------------------------------------------------------------------------------ >>> [rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar >>> tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl >>> INFO: LTA input is not RAS to RAS...converting... >>> target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz >>> movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca >>> reg file /tmp/reg.tmp.1367946635.dat >>> LoadVol 1 >>> ZeroCRAS 0 >>> $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ >>> Diagnostic Level -1 >>> GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file >>> No such file or directory >>> ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22 >>> ------------------------------------------------------------------------------------------------------------------------------------------ >>> >>> 2) I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either) >>> >>> 3) Then tried another trick that Doug suggested a while ago on the message boards: >>> >>> tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg >>> >>> and got "ERROR: Option --lta-inv unknown" >>> >>> 4) I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish: >>> >>> tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ >>> >>> This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard). >>> >>> So I'm slightly stymied. >>> >>> Thanks tons, >>> >>> Fred >>> >>> >>> >>> >>> On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote: >>> >>>> Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! >>>> On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>> >>>>> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails >>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>> >>>>>> Hi Bruce >>>>>> >>>>>> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >>>>>> >>>>>> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >>>>>> >>>>>> >>>>>> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>>>> >>>>>>> Hi Fred >>>>>>> >>>>>>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>>>>>> >>>>>>> >>>>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>>>> >>>>>>>> Dear all >>>>>>>> >>>>>>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>>>>>> >>>>>>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Fred >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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. >>>>>>> >>>>>> >>> >
-- 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/
-- 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/
Great, thanks!
BTW, Doug, your primer on the hell of transformation matrices is very nice.
On 2 May 2013, at 18:19, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Funny you should mention that. Martin just wrote a program to convert lta's from one type to another. Martin, can you share with Fred? doug
On 05/02/2013 01:13 PM, Fred Dick wrote:
Yes - maybe it is an idiotic one, but is there a straightforward way to write out a tkregister-tweaked talaiarch.lta with the correct geometry so that mri_ca_normalize/register will read it right?
On 2 May 2013, at 18:04, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, so do you still have an outstanding question? doug
On 05/02/2013 12:55 PM, Fred Dick wrote:
Hi Doug
totally no worries (this hardly counts as a delay!).
I'm running it as
tkregister2 --ltaout tal-out.lta --gca [sub] --check-reg
As you had suggested, the source and dst are switched (in talaiarch.lta, the .gca is the dst, whereas in new output file, it's the src).
Also, the RB...gca is 256 256 256 in the original lta, whereas in the new one (where it's src) it's 128 128 128, which agrees with mri_info output.
cheers, Fred
On 2 May 2013, at 17:13, Douglas N Greve greve@nmr.mgh.harvard.edu wrote:
Hi Fred, sorry for the delay. How are you running tkregister2 to produce a new lta? Is the only difference between the lta files the matrix? Or did the src and dst geometry and/or type change?
doug
On 05/02/2013 05:52 AM, Fred Dick wrote:
Hi Doug
sorry to nudge - any thoughts on lta tweaking?
cheers, Fred
On 30 Apr 2013, at 16:44, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote:
> Hi Fred, > > I'll have to defer to Doug on this > Bruce > On Tue, 30 Apr 2013, Fred Dick wrote: > >> Hi Bruce >> >> >> On 30 Apr 2013, at 13:36, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >> >>> Hi Fred >>> >>> I know it's a silly question but are you sure that file exists and is readable by you? The fact that it's calling GCAread means it's doing the right thing and support gca files. >> Totally not a silly question. With tkregister tho it looks like the path to gca is hard coded somewhere (but not in tkregister.tcl). So after finally engaging my brain I realized I could just make a symlink to the path tkregister is looking for (e.g., /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca) and then it works. >> >> So that's great - and then if I use an --ltaout flag, tkregister helpfully writes out the .lta. Which mysteriously is different than the original talairach.lta. >> >> Is it the inverse transform with an offset, perhaps? >> >> The reason I ask is that it looks like you can tweak non-ideal .lta with tkregister. I think Matt Glasser wrote something related a while back, but not sure. >> >> Thanks as always, >> >> Fred >> >> >> >> >> >>> You can also extra the mean of the highest prob label (-nth 0) and the label itself (-nth 1) using mri_convert: >>> >>> mri_convert -nth 0 \ >>> /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ >>> label_means.mgz >>> >>> mri_convert -nth 1 \ >>> /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca \ >>> labels.mgz >>> >>> >>> cheers >>> Bruce >>> >>> >>> On Tue, 30 Apr 2013, Fred Dick wrote: >>> >>>> Hi again >>>> >>>> different weighting sorta kinda worked better. It might be a dud brain. >>>> >>>> But on this topic - I realized I wasn't quite sure of a couple of things, and had some errors pop up with some tkregister2 options. >>>> >>>> [btw, running stable 5.2.0 on snow leopard] >>>> >>>> 1) I first tried to check the reg to the gca, and got the following error message. It looks like maybe this is an old/deprecated option given the hard-coded path to the 5.0.0 linux version (I saw a posting from Doug from a few years ago on this) >>>> >>>> >>>> ------------------------------------------------------------------------------------------------------------------------------------------ >>>> [rancate:/Applications/freesurfer/subjects] fred% tkregister2 --check-reg --gca dancar >>>> tkregister_tcl /Applications/freesurfer/tktools/tkregister2.tcl >>>> INFO: LTA input is not RAS to RAS...converting... >>>> target volume /Applications/freesurfer/subjects/dancar/mri/T1.mgz >>>> movable volume/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca >>>> reg file /tmp/reg.tmp.1367946635.dat >>>> LoadVol 1 >>>> ZeroCRAS 0 >>>> $Id: tkregister2.c,v 1.121.2.1 2011/03/28 20:25:16 greve Exp $ >>>> Diagnostic Level -1 >>>> GCAread(/usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca): could not open file >>>> No such file or directory >>>> ERROR: could not read /usr/local/freesurfer-5.0.0-cent4-64/average/RB_all_2008-03-26.gca as 22 >>>> ------------------------------------------------------------------------------------------------------------------------------------------ >>>> >>>> 2) I also tried to load up the gca in tkmedit using the appropriate gui option, but nothing happened (no error messages either) >>>> >>>> 3) Then tried another trick that Doug suggested a while ago on the message boards: >>>> >>>> tkregister2 --mov $FREESURFER_HOME/average/RB_all_2008-03-26.gca --targ $SUBJECTS_DIR/dancar/mri/brain.mgz --lta-inv $SUBJECTS_DIR/dancar/mri/transforms/talairach.lta --check-reg >>>> >>>> and got "ERROR: Option --lta-inv unknown" >>>> >>>> 4) I finally tried using the talairach.lta as a transform to the fsl target, using some old default-processed brains to make sure it was correct-ish: >>>> >>>> tkregister2 --check-reg --lta transforms/talairach.lta --mov ./T1.mgz --fsl-targ >>>> >>>> This seemed in the ballpark - except when I looked at bert, who I assumed would be canonical, and transform was clearly not correct. (Given Doug's earlier command, it seemed like talairach.lta was the inverse transform of what I thought it was, e.g., sub => standard). >>>> >>>> So I'm slightly stymied. >>>> >>>> Thanks tons, >>>> >>>> Fred >>>> >>>> >>>> >>>> >>>> On 29 Apr 2013, at 15:06, Fred Dick ubjtd13@mail.bbk.ac.uk wrote: >>>> >>>>> Aha, I shall quickly try with the non -w weighting and see what happens. Thanks! >>>>> On 29 Apr 2013, at 15:05, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>>> >>>>>> yes, the -w will create an optimal weighting to maximize gray/white contrast. The image it generates won't in general be physically realizable in an real MR acquisition. Not surprising that the tal stuff fails >>>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>>> >>>>>>> Hi Bruce >>>>>>> >>>>>>> I'm using TR=20, flip=30, TE=5 - but possibly irrelevant as also have the -w flag on. >>>>>>> >>>>>>> I originally thought this was from a bad brainmask, but then generated a good one and same thing happening. >>>>>>> >>>>>>> >>>>>>> On 29 Apr 2013, at 14:27, Bruce Fischl fischl@nmr.mgh.harvard.edu wrote: >>>>>>> >>>>>>>> Hi Fred >>>>>>>> >>>>>>>> we don't have much experience with this. Which synthesis are you using? You might need to use a different one for the talairaching to more closely match the atlas (maybe a TR=20,TE=2.5,flip=20-30 one) >>>>>>>> >>>>>>>> >>>>>>>> On Mon, 29 Apr 2013, Fred Dick wrote: >>>>>>>> >>>>>>>>> Dear all >>>>>>>>> >>>>>>>>> I'm having difficulties getting correct Talairach.lta's from synthetic flash volumes (Bruce, you are probably sorry you ever told me about this!). Basically the brain is over-scaled (bigger than it should be), which I think is happening because the contrast is so good (gm much darker than wm). >>>>>>>>> >>>>>>>>> Is there an example of how to use the -flash_parms flag, and what mri_em_register is expecting in the parameter file? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Fred >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >>>>>>>> >>>>>>> >>>> >>
-- 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/
-- 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/
-- 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 -
Fred Dick