Dear Bruce,
I understand the requirement about surfaces. But what about the volumes passed to mris_make_surfaces, do they have the same vox2ras as the surfaces?
Maybe it could be a good option to incorporate checks of this to mris_make_surfaces binary to prevent possible problems caused by this.
Regards,
Antonin
yes, all the surfaces used by mris_make_surface must share things like
ras2vox and such
cheers and happy thanksgiving
Brue
On Wed, 23 Nov 2016, Antonin Skoch wrote:
> Bruce,
>
> and do you require that also all volumes which are passed as arguments to
> mris_make_surfaces must have identical vox2ras and also the vox2ras of the
> volumes has to be identical to vox2ras of all surfaces?
>
> And, still it is not clear to me this:
>
> In freeview, there is perfect overlap of ?h.white.deformed and lh.white, but for
> the selected vertex the freeview shows different coordinates in lh.white and
> lh.white.defomed (see screenshot, note the perfect overlap of the meshes).
> My click on the surface in 3D view mode selects vertex no 66639 in both
> surfaces, located at the same position on the screen, however the vertex
> coordinates shown in freeview are different.
>
> How it is possible?
>
> Antonin
>
>
> From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> To: Antonin Skoch <ansk@ikem.cz>
> Sent: 11/23/2016 2:26 AM
> Subject: Re: [Freesurfer] v6.0_beta - mris_make_surfaces -T2 refinement -issue
> with overlapping pial surfaces
>
> no, they look fine in freeview because freeview is treating them as
> sseparate surfaces. In mris_make_surfaces we are assuming it is the
> same
> surface (same ras2vox, same number of vertices/faces, etc...)
>
> On Wed, 23 Nov 2016, Antonin Skoch wrote:
>
> > Dear Bruce,
> >
> > I am trying to understand. The vox2ras are indeed different:
> >
> > lh.white
> >
> > Volume Geometry vox2ras
> > -0.70000 0.00000 0.00000 108.35732;
> > 0.00000 0.00000 0.70000 -131.16824;
> > 0.00000 -0.70000 0.00000 112.74670;
> > 0.00000 0.00000 0.00000 1.00000;
> >
> > lh.white.deformed
> >
> > Volume Geometry vox2ras
> > -0.70000 0.00000 0.00000 108.33944;
> > 0.00000 0.00000 0.70000 -127.46620;
> > 0.00000 -0.70000 0.00000 109.73940;
> > 0.00000 0.00000 0.00000 1.00000;
> >
> > But when I load both surfaces in freeview, they perfectly fit,
> optically there is perfect
> > vertex-by vertex match (by looking at the mesh rendering or 2D
> surface contour, even with
> > extended zoom).
> > However, vertices show different RAS coordinates in freeview
> cursor display, for example
> > vertex 136135 in lh.white.deformed shows coords -1.36 -6.9 21.69,
> in lh.white shows
> > coords -1.38 -3.2 18.68.
> >
> > It is some kind of issue of freeview?
> >
> > Antonin
> >
> >
> > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > To: Antonin Skoch <ansk@ikem.cz>
> > Cc: <freesurfer@nmr.mgh.harvard.edu>
> > Sent: 11/23/2016 1:43 AM
> > Subject: Re: [Freesurfer] v6.0_beta - mris_make_surfaces -T2
> refinement -issue with
> > overlapping pial surfaces
> >
> > the vox2ras. Not sure about the HCP pipeline. They use a
> deprecated
> > version of FS, but in any case what you had would not work
> as the ?h.pial
> > surface didn't match the ?h.white.deformed one. If you also
> deformed
> > the pial it would be ok
> >
> > On Wed, 23 Nov 2016, Antonin
> > Skoch wrote:
> >
> > > Dear Bruce,
> > >
> > > thank you very much for your time.
> > >
> > > Concerning transformations, that is weird since I adopted
> my code from HCP
> > pipelines
> > >
> > >https://github.com/Washington-University/Pipelines/blob/master/FreeSurfer/scri
> pts/FreeSu
> >
> > > rferHiresPial.sh
> > >
> > > and there I think they use the surfaces precisely this
> way. They are using
> > the surfaces
> > > generated by 1mm3 volumes as input and refine them by
> using co-registered
> > higher
> > > resolution volumes. I use full-hires reconstruction, but
> for my safety and
> > convenience I
> > > left the code with transformations, which (I thought)
> should do not any
> > harm (there is
> > > not any resampling in my case).
> > >
> > > I also checked the white and white.deformed processed by
> default HCP
> > pipeline and they do
> > > NOT have the same ras2vox.
> > >
> > > BTW, which transformation in mris_info is relevant for
> this case? I found
> > several of them
> > > in mris_info:
> > >
> > > talairch.xfm
> > >
> > > surfaceRAS to talaraiched surfaceRAS
> > >
> > > talairached surfaceRAS to surfaceRAS
> > >
> > > Volume Geometry vox2ras
> > >
> > > Volume Geometry vox2ras-tkr
> > >
> > > Antonin
> > >
> > >
> > > From: Bruce Fischl <fischl@nmr.mgh.harvard.edu>
> > > To: Antonin Skoch <ansk@ikem.cz>
> > > Sent: 11/23/2016 12:42 AM
> > > Subject: Re: [Freesurfer] v6.0_beta - mris_make_surfaces
> -T2 refinement
> > -issue with
> > > overlapping pial surfaces
> > >
> > > yes, and I tracked it down and fixed it. BTW: don't
> use the
> > > white.deformed surface - use the white one. You
> can't use one surface
> > that
> > > has been transformed (i.e. has a different ras2vox)
> and other
> > surfaces that
> > > have not (you can see this if you run mris_info on
> the surface files,
> > the
> > > ras2vox should match in all of them)
> > >
> > > cheers
> > > Bruce
> > >
> > >
> > >
> > >
> >
> >
> > 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.
> >
> >
> >
>
>
>