Issues using freesurfer files to create t1 TO talairach-AC/PC transformations in Freesurfer/BrainVISA import

[wsnyder4]

Dear BrainVISA experts,

Thank you for helping me identify an issue with the transformations I am using to import FreeSurfer files into the Morphologist 2021 pipeline. I am following up in this new thread to ask about how these transformations are calculated when importing.

My issue is that after loading talairach referential in several subjects' sulcal graph in anatomist, the sulcal graphs do not align, mostly misaligned in the y and z planes. Upon checking the AC-PC coordinates for each subject using the Morphologist > viewers > view commissure coordinates process, I saw that the AC/PC coordinates were never on the true AC/PC coordinates in the y and z directions (but were correct / in the center of the brain for the x coordinate).

I first checked to see if my talairach transformations (input to the Import FreeSurfer to Morpho process) (as talairach.auto.xfm) were okay. Checking through my subjects, each transformation yielded proper alignment in freesurfer talairach templates.

I noticed in the source code for the process, the transformations seem to be in this form (when reading the Import_FROM_FreeSurfer_TO_Morpho.py and TalairachTransformationFromNormalization.py called within the former):

A = talairach.auto.xfm
B = transformation from the header from a temporary (tmp_orig) file, created by converting orig.mgz to NIFTI format
C = MNI to Talairach AC-PC transformation

data = any set of coordinates in native space

data in Talairach AC/PC = C * A * B * data 

also allowing operations like:

coordinates of AC in native space = [C*A*B]^-1 * [0,0,0] 

Since my transformations in A were checked out, and C seems to be built in to BrainVISA, I am curious about B. How are the transformations in the header of the temporary nifti file for orig.mgz calculated? I am using brainvisa without the FreeSurfer home path specified -- will a different conversion take place if I allow BrainVISA to use FreeSurfer directly?
Otherwise, I assume it is using AimsFileConvert to get that temporary file. In testing, I noticed that the y and z transformations in the header of a nifti file created from orig.mgz are different when using AimsFileConvert vs. using mri_convert (as part of FreeSurfer), and that AimsFileConvert will produce a warning "transformations in FreeSurfer .mgh / .mgz are probably wrong"

Is this a reasonable place to look towards resolving my transformation issue? Also, A * B is called t1aims2mni in the source code -- is this supposed to mean the talairach space built from MNI305 in FreeSurfer?

I apologize for the long message but wanted to be as verbose as possible in case I might miss any potential hints towards figuring this out. Thank you for the help!!

Best,
Will

[denisri]

Hi,
Yes I think it's a very good clue. Sorry I didn't get time to look at this problem earlier, and I'm still quite busy but you're right and we must find out what's going on here.
I have to look in more details, but I think that the process is uising a converter process, queried from the available converters in Brianvisa. If Freesurfer is configured, then the one based on mri_convert is used, and that's what the FS/Morphologist conversion was designed for. When Freesurfer is not configured, like in your situation, then formerly the process used to just fail because we didn't have the .mgz/.mgh support in AimsFileConvert. But now we have added it (through the minc library actually) so this Aims converter should be triggered, and... that's what we have not tested afterwards... So that's likely the problem.
I will look closer and try to fix it. In the meantime it's recommended to configure freesurfer and allow the conversion using mri_convert.
If the Talairach transform is wrong it's also likely that some data processing will be affected, especially the sulci recognition...
Anyway thanks a lot for helping find the problem, that's very helpful !

[denisri]

So you are right: when the .mgz is converted using the Aims converter, the transform to the scanner-based referential is wrong: it is just a "default" transformation going to the center of the image. As I said in the previous message, we don't have a reader which reads directly Freesurfer formats, we do it through the Minc lib which now supports it (thus it comes for free in the Minc reader) and I don't know if there is a means to get the right transform through the minc lib, or if it doesn't read it at all. I have to investigate. If it doesn't do it then we have to take care when using this reader/converter, and maybe explicitly disable it from the freesurfer / morphologist import process.

[wsnyder4]

Thank you so much for the rapid check on this! This is much clearer now, I appreciate the explanation.
Also, it seems that even with FreeSurfer properly linked to BrainVISA (I tested running the mgz to nit converter process within BrainVISA based on freesurfer scripts) that the Import_FROM_FreeSurfer_TO_Morpho process will still grab the Aims converter before it grabs freesurfer's mri_convert, unless I am still doing something wrong. I would be curious if the context.getConverter(self.T1_orig, tmp_ori) command (in Import_FROM_FreeSurfer_TO_Morpho.py) can still access the FreeSurfer converter first in the presence of a working Aims converter. But I also may be doing something wrong (although I have set up freesurfer databases, etc). I will keep looking into it as well.
Thank you again for the assistance!

[denisri]

Well, the libminc doesn't read this info from .mgz files. We have noticed it and the Aims reader prints a warning "Warning: transformations in a freesurfer .mgh / .mgz are probably wrong.", but I had forgotten about it. I have started digging into the code, and it seems that libminc has an internal function with a bool parameter to tell it if it should ignore offsets in the header, and this function is called with this flag set to ignore (hard-coded) from the read code. I'm trying to copy the function and call it manually and see if I can make something out of it...

[denisri]

Hm, when several converters can do the same job, I'm not sure the converters are ordered/prioritized in brainvisa, thus getConverter() might be somewhat random :/
I also have to check that...

[denisri]

I have opened a ticket brainvisa/soma-io#17

[wsnyder4]

Great!! Thanks so much for all this help.
Is there a way before a future release of BrainvISA that I can best copy these updates into my personal install of BrainVISA to play around and see if it fixes the issue in my sample of brains?

[denisri]

I'm testing a bit before I propose any patch, but I will (if it works as expected)...

[denisri]

I have finally succeeded in reading the transformation in mgh/mgz files, but it's in compiled code that is not so easy to update in a binary distribution. In the meantime I have patched the Aims converter process to exclude freesurfer formats until the next version of Aims. This way it will not be taken as a converter, and will leave this task to the freesurfer converter (based on mri_convert).
The modified converter is here: https://brainvisa.info/download/updates/5.0.3/brainvisa/toolboxes/tools/processes/converters/AimsConverter.py
In order to update your binary distribution, you must make it writeable: if using a singularity container, containers are read-only (unfortunately), which forbids to modify the files there. You can run the bv program in the brainvisa installation dir (from the host system) without arguments: it will open a graphical interface allowing to configure the install. There you have a line saying "BrainVisa installation: read-only" and a button allowing to perform a read-write install: it will copy all the brainvisa files onto the host system disk (thus using about 2 Gb additional disk space, we have no other solution). Then you can get the updated file(s) above and write it at the same location in the install subdirectories there.

[wsnyder4]

Thank you for all the help here! I have one last question -- I was able to get these scripts running well on my virtual machine copy of brainvisa but am still figuring it out for singularity. I performed the steps you mentioned, and now my brainvisa install directory has all the extra subdirectories such as /casa/install . However, now I am unable to run any brainvisa commands -- any time I type "brainvisa" or "bv" into the terminal, I get

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site

I tried changing the PYTHONHOME variable to {path of my brainvisa install}/install/python, and the first three lines of that error disappeared, but I still receive the ImportError: No module named site error. In my ~/.bashrc file I have the location of the {path of my brainvisa install}/install/bin in my PATH variable exported. I also tried sourcing the bv_env.sh script with an argument as the location of my python install for brainvisa ({path of my brainvisa install}/install/python) but am still receiving this import error.

How may I configure my new brainvisa-singularity install to fix this?

Thanks again!
Will

[denisri]

The read/write install from singularity should install things in /casa/host/install (which is actually on the host filesystem, in {path of my brainvisa install}/install), whereas the read-only install is on /casa/install (no "host") inside the read-only singularity image.
Once done you don't have to change any path or PYTHONPATH: when you run the image (you need to restart the image, any shell already running in the image will not be updated), the paths will automatically switch to the new R/W install.
Moreover you should especially not change any PYTHONPATH on your host system.
I have just tried this again on brainvisa 5.0.3 and it works as expected.

[wsnyder4]

I just re-installed and it works as expected when I have my PATH variable point to the {path_of_bv_install}/bin instead of {path_of_bv_install}/install/bin on the host side. Things only seem to get weird when I have the install/bin version in my path (because this bin directory has python in it, and gets picked up instead of my system's python).
I assume that the {path_of_bv_install}/bin still calls upon the read-write files from, e.g., {path_of_bv_install}/install/brainvisa/toolboxes/tools/processes/converters/AimsConvert.py, correct?

Just wanted to double check, but this seems to be the case, as when I use the brainvisa command (from {path_of_bv_install}/bin) and run the FreeSurfer import over the UI, it prevents the usage of AimsConverter for .mgh/.mgz types as expected.

[denisri]

Oh yes, you should not set {path_of_bv_install}/install/<anything> in your host system paths because it contains things than can only run in the container, and would mess up your system. {path_of_bv_install}/bin contains symlinks to {path_of_bv_install}/bin/bv, which actually does what is needed to run the container, with the setup needed to use the right install of brainvisa (either read-only or read/write if this latter one is installed).
If you need to check, an easy test is running: {path_of_bv_install}/bin/bv python -c 'import brainvisa; print(brainvisa.__file__)', and it will print where it is used.