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

Of course, if you aren't trying to look at anatomical changes from
registration, then surface distortion could be exactly what you want.


On Fri, Oct 20, 2017 at 4:24 PM, tony han <> 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 <>
> *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 (
> 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
> with <current-sphere>
>          and has the desired output mesh
>       <method> - the method name
> The <method> argument must be one of the following:
> as explained in the command-line usage instructions
> On Oct 20, 2017, at 2:36 PM, Harwell, John <> wrote:
> Hello,
> You are correct, it is not an affine matrix.   A description of the file’s
> content is available at
> CaretHelpAccount/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 <> 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 mailing list
> _______________________________________________
> caret-users mailing list
caret-users mailing list

Reply via email to