ConvertSurface issues

[neurolabusc]

ConvertSurface seems to flip the X and Y polarities when reading from/to the FreeSurfer (.asc), PLY (.ply) and byu (.g) formats. Since this is applied both on reading and writing, the round trip from GIFTI->other->GIFTI restores the coordinates. Notice that FreeSurfer uses the same coordinate system as GIFTI, so a FreeSurfer format mesh created by ConvertSurfaces appears flipped in the Anterior-Posterior and Left-Right dimensions (see screenshot). The -native switch does not seem to help.

ConvertSurface  -i_gii L.surf.gii -o_gii afni
ConvertSurface  -i_gii L.surf.gii -o_fs afni
ConvertSurface  -i_gii L.surf.gii -o_ply afni
ConvertSurface  -i_gii L.surf.gii -o_byu afni

ConvertSurface  -i_gii afni.gii -o_gii gii2
ConvertSurface  -i_fs afni.asc -o_gii fs2
ConvertSurface  -i_ply afni.ply -o_gii ply2
ConvertSurface  -i_byu afni.g -o_gii byu2

FreeSurfer FreeView provides the reference display for FreeSurfer format images. The original (green) and converted (yellow) images are not aligned, but the converted back (red) perfectly aligns with the source:

[mrneont]

Hi, @neurolabusc : Hmmm, weird. OK, thanks, we will dig into the code and see what is happening. Thanks for pointing this out.

[afni-dglen]

I took a look at this and tried similar examples. Interestingly, they all appear correct and nearly identical (except for some small rounding differences with ascii output) within the suma interface. What I think is going on is that almost all the surface reading functions assume LPI coordinate order, rather than RAI/DICOM order. It's mentioned in a couple places in some of the help output, but it's definitely not obvious. Based on that help, it seems that FreeSurfer used to output data in RAI order, but that has not been the case in recent years. Is this data, the l.surf.gii, a new GIFTI dataset?

In any case, there is a workaround, use the "-xmat_1D NegXY" option for ConvertSurface to negate X and Y coordinate values.