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 <fis...@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 <ubjt...@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 <fis...@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 <fis...@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. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>> >>> >>> >>> > > > > _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
