Yes, I see what you mean. We did think of that back when we were first troubleshooting, and simply changing the option to rh on the Design tab did not solve the problem (I just checked again and it still points to lh). So it looks like unless you actually run an analysis from the design tab, the 'Map to All Subjects' option points to the lh. Thank you for helping us solve this problem!
When working with a manually loaded surface, and a new rh label is drawn
or a prior one loaded, prior to pressing the 'Map to All Subjects
Option', do you switch the hemi menu selection in the Design tab to
'rh'? I'm guessing not, because it is not evident that you would need
to do this, but it explains the problem you are seeing. In my own past
usage of qdec, I havent run the use case you described, so until now I
didnt anticipate this problem. The problem is that when loading a
surface or label, there is no step or pop-up box or mechanism to tell
qdec which surface it is loading. I suppose it could infer it from the
name (parse-out 'rh' or 'lh), but that is kind of hacky. What I need to
add is a pop-up box or some user interface gate that forces the user to
set the hemisphere. Otherwise, qdec just default to 'lh'. So until
that feature is added, you will just have to remember to goto the Design
tab and set the hemi to whatever was loaded.
n.
On Wed, 2010-10-13 at 14:22 -0500, Tessa Harrison wrote:
> Nick,
>
>
> Thanks for getting back to me. After you said you could not
> replicate the problem, we went back in and reexamined. It seems that
> if you draw a new rh label or pull up a previously created rh label in
> qdec on a loaded surface (i.e., rh.pial, etc), the “Map to All
> Subjects” option points to the lh (as seen in Derin’s output).
>
>
>
> We tried mapping rh labels after loading them onto an rh analysis and
> it works just fine, which may have been why you could not replicate
> our issue?
>
>
>
> We were using the load surface option so as to save time by avoiding
> running an analysis every time we wanted to map a label created with
> tksurfer to new subjects. Regardless, I am happy to know there is a
> work-around for this issue!
>
>
>
> -Tessa
>
>
>
>
>
> On Mon, Oct 11, 2010 at 9:18 PM, Nick Schmansky
> <nicks@nmr.mgh.harvard.edu> wrote:
> Tessa and Derin,
>
> I'm unable to replicate this problem in the mac or on linux,
> using v5.0.
> I'm running a group analysis on the rh, then drawing a lable
> and
> selecting the Map Label to Subject option, and the label2label
> command
> uses 'rh' as the --hemi option for me.
>
> Can you describe your usage so that I can replicate the
> problem?
>
> n.
>
>
> On Mon, 2010-10-11 at 10:26 -0500, Derin Cobia wrote:
> > I'm experiencing this as well on my Mac OS X distribution of
> FS
> > v5.0.0. Here is terminal output when running the "Map Label
> to
> > Subjects" command on the rh, with a rh label in QDEC
> (below). Looks
> > like there is a small bug in the code where it points to the
> left hemi
> > for registration instead of the right ("--hemi lh").
> >
> >
> > -Derin
> >
> >
> > =======================================
> > mri_label2label --srclabel rh_ifg_test --srcsubject
> fsaverage
> > --trgsubject C1a --trglabel rh_ifg_test --regmethod surface
> --hemi lh
> >
> >
> > srclabel = rh_ifg_test
> > srcsubject = fsaverage
> > trgsubject = C1a
> > trglabel = rh_ifg_test
> > regmethod = surface
> >
> >
> > srchemi = lh
> > trghemi = lh
> > trgsurface = white
> > srcsurfreg = sphere.reg
> > trgsurfreg = sphere.reg
> > usehash = 1
> > Use ProjAbs = 0, 0
> > Use ProjFrac = 0, 0
> > DoPaint 0
> >
> >
> > SUBJECTS_DIR /Volumes/project/freesurfer/PPA
> > FREESURFER_HOME /Applications/freesurfer
> > Loading source label.
> > Found 7351 points in source label.
> > Starting surface-based mapping
> > Reading source registration
> >
> /Volumes/project/freesurfer/PPA/fsaverage/surf/lh.sphere.reg
> > Rescaling ... original radius = 100
> > Reading target surface
> > /Volumes/project/freesurfer/PPA/C1a/surf/lh.white
> > Reading target registration
> > /Volumes/project/freesurfer/PPA/C1a/surf/lh.sphere.reg
> > Rescaling ... original radius = 100
> > Building target registration hash (res=16).
> > Building source registration hash (res=16).
> > INFO: found 7351 nlabel points
> > Performing mapping from target back to the source label
> > =======================================
> >
> >
> >
> >
> > On Oct 11, 2010, at 9:51 AM, Tessa Harrison wrote:
> >
> > > Hi FreeSurfers,
> > >
> > >
> > > I posted this question to the listserv a little over a
> week ago--
> > > does anyone have any insight as to what is going on with
> our RH
> > > labels?
> > >
> > >
> > > -Tessa
> > >
> > >
> > >
> > >
> > > ---------- Forwarded message ----------
> > > From: Tessa Harrison <t-harrison@northwestern.edu>
> > > Date: Thu, Sep 30, 2010 at 9:36 AM
> > > Subject: Mapping labels to the RH on Macs
> > > To: freesurfer@nmr.mgh.harvard.edu
> > >
> > >
> > > Dear FreeSurfers,
> > >
> > >
> > > I am running FS 4.5 or FS 5.0 on Mac OS X 10.6.4 -Intel
> (see
> > > attached screenshot).
> > >
> > >
> > > I am not able to map RH labels created in fsaverage to the
> RH of any
> > > of my subjects. LH labels map to the LH from qdec "Map
> Label to All
> > > Subjects" option and from the command line with no
> problem. However,
> > > when I try to map RH labels (that map correctly to the RH
> in
> > > fsaverage) to individual subjects, the command appears to
> work (no
> > > error messages), but something goes wrong. It appears that
> the label
> > > is actually mapped to the LH because when I pull it up on
> the RH in
> > > an individual subject it looks like scattered dots (see
> attached
> > > image).
> > >
> > >
> > > The same thing happens on another Mac in our lab. I have
> tried both
> > > FS 4.5 and 5.0 and the problem occurs in both versions.
> Could this
> > > be a bug in the Mac FS release? I did not find any mention
> of this
> > > problem in the archives.
> > >
> > >
> > > Thank you for you help!
> > >
> > >
> > > -Tessa
> > >
> > >
> > >
> <MacHardware.png><rh_IFG_large_P12a.png>_______________________________________________
> > > 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
>
>
>
>