A small addendum: spherical surface registration is not the only use for
measuring surface distortion.  If you use it on resampled anatomical
surfaces from different longitudinal timepoints, or from different species,
or just different subjects, you can get a measure of the difference in
anatomical size of various features of the cortex.

Since you were talking about "deformation from native space to fs_LR", I
didn't think about these other possibilities.

Tim


On Fri, Oct 20, 2017 at 5:59 PM, Timothy Coalson <tsc...@mst.edu> wrote:

> Deformation maps are inherently designed for the purpose of going from one
> topology (number of triangles and their layout) to a different one, so they
> are a tricky thing to try to compare vertexwise.  They also don't really
> encode warpfield deformations (and even using them to reconstruct as much
> as possible gives you only half the story).  This is actually another
> reason why we chose not to use them in workbench.
>
> If you want to see the amount of deformation that happened to the sphere
> during registration, what you need are the original and registered spheres
> - these will always be on the same mesh, so they can be compared directly
> via things like wb_command -surface-distortion.
>
> However, I am curious about your interest in surface distortion, so some
> explanation is in order, and here is where things get mind-bending (or more
> properly, where they don't, as I will explain).  Surface registration and
> resampling does not cause any change in the shape of an individual's
> brain.  It is not an anatomical registration, unlike volume-based
> registration: it does not align anatomical coordinates.  What it actually
> does, is take the original coordinates of the subject's cortex, and
> represent them with a different set of triangles - the places where the new
> surface intersects the subject's voxels are unchanged, it just has
> different triangle and vertex numbers in each location than it used to (and
> generally a different total count of vertices/triangles).
>
> To come at it from a different angle, surface registration is about
> finding corresponding locations on brains with different shapes - it
> doesn't change the shapes in the process, it just finds where, for
> instance, foveal V1 is in each subject, and stores that information for
> later.  When surfaces and data are then resampled, foveal V1 is now vertex
> #2856 in every subject (whereas previously it was on a different vertex
> number per subject) - but, in every subject, the coordinates of that vertex
> is different, corresponding to where the original surface said foveal V1
> was located.
>
> So, what does surface registration distortion actually represent?  It is,
> in fact, the change in sampling density of that patch of the surface:  If
> part of the subject's sphere gets expanded during registration, then that
> patch will have a lot of small triangles within it in the resampled
> surface.  If it gets elongated on the sphere, then on the resampled surface
> it will have skinny (obtuse) triangles on the resampled surface.  This is
> one of the main reasons that we try to control distortion in registration
> (another is that it is also a good proxy for overfitting).
>
> If what you are after is distortion of anatomical coordinates, then you
> should only be looking at the volume registration.  While you could look at
> the changes that happen to the coordinates when you average different
> subject's surfaces together, but we don't recommend using group average
> surfaces for much more than visualization (when doing surface-based
> processing on them, such as gradients, we generally supply a secondary file
> in order to do some correction for the effects of averaging the
> coordinates).
>
> Of course, if you aren't trying to look at anatomical changes from
> registration, then surface distortion could be exactly what you want.
>
> Tim
>
>
> On Fri, Oct 20, 2017 at 4:24 PM, tony han <oktony...@hotmail.com> wrote:
>
>> Hi John and David,
>>
>>
>> Thanks a lot for your reply! Yes I'm thinking to move from Caret to
>> Workbench since most of the time we use wb_command a lot and it makes sense
>> to keep our tools up-to-date and consistent.
>>
>>
>> Just want to clarify: the weights (last 3 columns) of the vertices
>> (indexed by the first 3 columns) are decided by the distance from the 3
>> vertices of SOURCE to the vertex of TARGET? If so, maybe that's the reason
>> why why the sum of weights is not one for each vertex of TARGET?
>>
>>
>> So the reason why I'm looking at deformation maps is that I'm trying to
>> figure out a way to quantify the deformation from native space to fs_LR at
>> each vertex on the surface (32k fs_LR atlas surface). Could you give me any
>> suggestion?
>> ------------------------------
>> *From:* David Van Essen <vanes...@wustl.edu>
>> *Sent:* Friday, October 20, 2017 3:41:11 PM
>> *To:* Caret, SureFit, and SuMS software users; tony han
>> *Subject:* Re: [caret-users] info in the deformation maps
>>
>> Hi Tony et al.
>>
>> John’s explanation regarding deformation map files is correct.  Here, I’m
>> drawing to your attention the fact that Connectome Workbench (and
>> wb_command) provides improved methods for mapping from one surface mesh
>> that has been registered to another (see below).  Depending on your use
>> case scenario, you (and others) may decide to stick with Caret and its
>> deformation maps (even though Caret is no longer under active development).
>> Or you may find it advantageous to switch to wb_command for future
>> analyses, as it has become more  powerful and flexible, and is still under
>> active development (https://www.humanconnectome.o
>> rg/software/connectome-workbench).
>>
>> wb_command -label-resample
>> wb_command -metric-resample
>>   <current-sphere> - a sphere surface with the mesh that the metric is
>>          currently on
>>       <new-sphere> - a sphere surface that is in register wi
>> th <current-sphere>
>>          and has the desired output mesh
>>       <method> - the method name
>> The <method> argument must be one of the following:
>>       ADAP_BARY_AREA
>>       BARYCENTRIC
>> as explained in the command-line usage instructions
>>
>> On Oct 20, 2017, at 2:36 PM, Harwell, John <jharw...@wustl.edu> wrote:
>>
>> Hello,
>>
>> You are correct, it is not an affine matrix.   A description of the
>> file’s content is available at http://brainvis.wustl.edu/C
>> aretHelpAccount/caret5_help/file_formats/file_formats.html#
>> deformationMapFile.
>>
>> Essentially, the deformation map file defines a resampling of one surface
>> triangular mesh to another.  For each vertex in the target surface, it
>> identifies the corresponding location in the source surface using
>> barycentric coordinates.  A barycentric coordinate contains three vertex
>> indices that form a triangle and the weights define the location within the
>> triangle.
>>
>> John H
>>
>> On Oct 20, 2017, at 1:00 PM, tony han <oktony...@hotmail.com> wrote:
>>
>>
>> Hi,
>>
>> I notice that there are 6 columns of data stored in the deformation map
>> (actually it's 7 but the first one looks like the indices). So what are
>> these columns? It doesn't look like affine matrices? Thanks!
>>
>> Best,
>> Tony
>> _______________________________________________
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>> _______________________________________________
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>>
>> _______________________________________________
>> caret-users mailing list
>> caret-users@brainvis.wustl.edu
>> http://brainvis.wustl.edu/mailman/listinfo/caret-users
>>
>>
>
_______________________________________________
caret-users mailing list
caret-users@brainvis.wustl.edu
http://brainvis.wustl.edu/mailman/listinfo/caret-users

Reply via email to