Understanding and handling brainvisa referential system

[pron.a]

Hello Brainvisa Team,

we are currently implementing a diffusion pipeline using Brainvisa which mixes several softwares (FSL and Dipy essentially) and are sometimes writing some outputs using FSL other using nibabel (dipy use it to save fiber bundles as trk files) and we are getting some surprises. Sometimes volumes have the same orientations sometimes not.. We started to dig a little bit, looking in the forum, both brainvisa and nibabel documentations, and nifti standards.. My loooong post (sorry for that) has two purpose. Trying to understand better how brainvisa and referentials system works and also find out a proper solution in order no to set up tansformation matrix manually. Here is what we think to have understood but to be confirmed ^^.

- Data are stored in certain layout and when loaded to anatomist or aims, data is automatically put in Aims referential which is LPI the flipping is encoded in storage-to memory transformation. This is transparent for us users. If the storage is done properly (according to Nifti standards) can storage to memory correspond to RAS to LPI voxel spaces transformation ?

- Affine in the transformation field of the aims header does not correspond to the actual affine transformation encoded in the nifti header but to a recalculated transformation between Aims referential and let say Scanner Based referential. In particular scaling is not taken into account.

What happens if a Volume is created from scratch using the loaded header of a previously loaded Volume. What field will actually be saved in the physical nifti header ? In particular which affine ?

-Meshes do not have proper header and are assumed to be created in the mm LPI space with 0 being the center of the first voxel by default but different referential can be precise in the minf file associated.

We guess that a convenient way to solve most of our orientation problem is to keep information using the minf file and staying in the brainvisa way.

Last problem we have is that fiber bundles are written with nibabel into the trk format. The bundles are then i the trackvis system coordinates. Referential seems to be well recognized into trackvis but not into anatomist. If we set this info into the minf file will brainvisa recognize it ? If not is there a way to retrieve classical referential (other than MNI and Talairach) using brainvisa or aims ?

Thank you very much ^^

[riviere]

Hi,

Yes that's it, more or less.

There is a bit of doc on the coordinates systems in aims here, I don't know if you have already found it: http://brainvisa.info/aimsdata/user_doc ... formations

When a volume is created from scratch, it will still be considered LPI in memory, and will possibly be saved in a different orientation according to the IO format capabilities and specs. If header information form another volume is copied in it, it will be used when saving. The Nifti file will contain at least a scanner-based transform needed to restore this orientation, but is the header specifies 2 transforms they will be saved in the nifti (in qform and sform). Nifti doesn't support more than 2 transforms, so if more are specified, the additional ones will only be saved in the .minf file.

In meshes and tracts, coordinates are read as they are stored without interpretation, in millimeters (not in voxels) and thus they are supposed to be in the same coordinates system as the aims volume they are built from. But now you're right you don't always have the source aims volume. However they still can carry transformations information in the .minf, so it should be possible to carry and apply transformations when needed, just the IO do not perform them automatically.
The trackvis format support is probably not complete right now, we haven't used it a lot for now, and the orientation info is read but not used, I think. That's something we can/must improve. Looking at the source code I think it doesn't even try to read any .minf file in this format (anyway we don't write .trk files so don't produce .minf with it). I didn't take the needed time to code all this properly, and I didn't have test data to test the use cases...

Denis

[pron.a]

Super ! Thank you very much for your quick and complete answer Denis
Thanks for the documentation link I have seen tracks are usually saved as graph in Brainvisa but I was not able to understand exactly how.
In fact I have the output from dipy in Aims mm coordinates and would like to use Graph ( bundles and associated bundlesdata). But due to time constraint I used the save_to_trk ready-to-use function of Dipy. I have just started to look a little bit in the code of the old connectomist to understand how to create the bundle file but for now did not manage to do it.

Have a good day and thanks again

[riviere]

Hi,
In fact tracts are not saved as graphs in brainvisa, but represented as graphs in memory for visualization. The graph structure allows to hold several meshes (for fibers), divided into several bundles etc. But this is normally just for visualization. Processings are based on a "streaming" API which allows to process one bundle/fiber/point at a time while they are read (a little bit like SAX for XML), avoiding to keep all data in memory because tracts data are generally huge and there is generally little need to process all of it at the same time in memory.
The bundles/bundlesdata format is more or less equivalent to the trackvis format, it's just older and .trk has grown more popular, thus more standard. Reading .trk should be the same in aims/anatomist, there should be no need to convert to .bundles, and if there are still problems with it, we will fix them.
Denis