nick Wrote:
-------------------------------------------------------
> Hi Ziad,
>
> ziad Wrote:
> --------------------------------------------------
> -----
> > Problem solved, I hope. The gifti coordinates
> > transform was being applied after center of
> mass
> > computation. The next set of binaries will
> contain
> > the fix.
>
> Thanks for making this fix - I will give it a try
> once the new binaries are there.
>
> Does that mean I should set the xform matrix m for
> the vertices such that m[0,0]=m[1,1]=-1 and
> m[2,2]=1, to achieve RAI/LPI compatibility?
Sure, and I checked that SUMA now rotates the surface similarly whether or not you have a transform that is not the identity.

In
> your earlier post you mentioned " I do use GIFTI
> versions of FreeSurfer surfaces fine" - could you
> take a look and see what the xform matrix for the
> surface coordinates contains for these files?

I do not set the xform for my output, rather I set the coordinates directly, and assume they are RAI at loading time. I hesitate to assume LPI across the board for my GIFTI surfaces because I worry this will cause me grief elsewhere. Years ago when we were testing compatibility, GIFTI test surfaces for different packages did display properly in SUMA and AFNI so I hesitate to touch anything on that front unless I have to.

cheers,
z

>
> I'm asking because we are adding support to GIFTI
> surface files in PyMVPA through the nibable
> package, and I would like to make sure that the
> files generated there are compatible with whatever
> GIFTI files typically contain, yet are also
> compatible with how other surface formats
> (currently ascii and caret binary are supported)
> are treated.
>
> cheers,
> Nick