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 <gr...@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 <gr...@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 <fis...@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 <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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> -- >>> Douglas N. Greve, Ph.D. >>> MGH-NMR Center >>> gr...@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 > gr...@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 mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
