> This makes perfect sense. I realize now that BV saves things
> in a different coordinate system than other surface-generation
> software (we've run into this before with TLRC coordinates in
> BV).
Coordinate systems are like opinions, everybody has one (and they're all different)

> When I load a surface with suma's -i option alone (no
> -sv), the surfaces are flipped (the file labelled LH displays
> as a RH surface, and vice versa). However, when I include the
> -sv option (and the proper aligned volume) it displays
> correctly. I guess it's finding out the orientation of the
> coordinates in the surfaces from the volume header info. Is
> that correct?
Using the proper sv is curcial. SUMA uses it to transform the coordinates of the surfaces on the fly into afni's RAI.
>
> Importantly, in my spec file, I have several surfaces that
> display both LH and RH on the screen at the same time (by
> mapping both LH and RH surfaces of a single type to a common
> StateDef/SurfaceState). It was never obvious to me that the
> surface controller that opens at any given time is specific to
> the surface that the cursor happens to be on at the moment one
> opens the surface controller. Knowing this makes a huge
> difference.
Correct, I know the documentation on this is terse. Someday I'll attend to that.

cheers,
ziad