Roi export as nifti mask goes into wrong space

[dbach]

I draw RoIs on a T1 nifti image (img/hrd) that was created in SPM, and export them as masks, specifiying a filename that ends with .img. This creates a valid nifti img/hrd file with the same resolution and dimensions as the underlying T1 image. However, when I overlay this mask image over the T1 image in SPM, it is shifted by a few centimetres towards superior/medial. How can this happen?

[dbach]

Just a few things I checked:

- the mask is not in MNI space either
- it appears to be in the wrong place when displayed with other tools (e.g. MRIcron)
- colleagues in my lab appear to have the same problem

any ideas?

[riviere]

Hi,
You're right: there is a bug here in Anatomist, referentials / transformations information is not correctly reported to the mask image.
I have just fixed it on our source code repository. The fix will be included in the next update release.
Denis

PS: note that when you save a .img/.hdr image from Anatomist 3.1.x, or any Aims* command, you are actually saving as Analyze format, not NIFTI. Use .nii to ensure writing Nifti.

[dbach]

Hi

many thanks for pointing this out, and for emailing the workaround using AimsConvert. this works fine for SPM and MRIcron, however not for FSL (note that the original images have a slightly odd orientation which does not matter for SPM but does for FSL). Any idea why that is?

Will there be an updated release in the foreseeable future?

Dom

[riviere]

Hi Dom,

Well I don't know why it doesn't work with FSL, maybe it's using its own transformation system, not information from the NIFTI header (?). If it's OK on SPM I guess the image is OK now.

We will do an update, eh... when we can... but not right now because we have just reorganized our sources/compilation servers for a completely different system, and the packaging tools are currently broken... The next update will be a 3.2 version, not a 3.1, and it's not completely ready yet...

Denis

[Narly]

Hi Denis,

I'm having exactly the same problem as descibed above (I'm exporting into analyze format, will exporting into nifti solve the problem? I suspect not..). Has this fix been released yet? (I don't see the dates of the releases anywhere and so I'm not sure if a new version has been released since these posts). If not, when do you plan to release it?
And could you possibly post the AimsConvert workaround in the meantime?

thanks and best wishes,
Narly.

[riviere]

Hi,

No the fix hasn't been released yet. We are getting "closer" to a new release but it is not ready yet. We cannot promise a release date because we are not many people and have many things to do... But I hope it will be ready within a month or so.

For a workaround, you could mabe save the whole ROI graph (as a .arg), then convert it to a graph with a labels volume:

Code: Select all

AimsGraphConvert -i roigraph.arg -o roigraph2.arg --volume

Then the volume in the roigraph2.data directory should have the correct information, and can be converted to any format (nifti, analyze etc)
I didn't take time to check that it is OK...

Denis

[Narly]

Hi again Denis,
No unfortunately this workaround does not work, it generates an image in exactly the same space as the original label.
best,
Narly.

[dbach]

Hi there

I am using version 3.2 now but the bug still exists.

My workaround is to create a temporary file from the original anatomical image with AimsFileConvert, copy the associated .minf file to overwrite the exported mask's .minf file, and convert the mask using AimsFileConvert. This works, but is a bit complicated. I'd be glad for a bugfix.

Dom

[riviere]

Hi,

We recently found that there was actually still a bug in this ROI referential (one of our users put the problem under my nose so I couldn't say it did not exist... )
The problem was when saving a ROI session (as .arg file), and then reloading it, the referentials/transformation information was lost. So after that, "export as mask" didn't get the missing info, too.
It is now fixed for the next release.

Denis

[Narly]

Great, thanks Denis. when will the next release be out?

best,
Narly.

[riviere]

when will the next release be out?

Normally at the end of march... hum, we're late, yes... well, I would say in 2-3 weeks if we don't find new severe problems...
Denis

[guillaume]

Hi BrainVisionners,

Denis, I guess you're bored with the NIFTI convertion issue, sorry for this new post.

I have two volumes that are registered with SPM and not with BV3.2
The second volume is a subpart of the first, obtained with SPM Imcalc (the volume composition tool in SPM).
The 2 figs attached hereafter are the snapshots of the respectives "browser window" of each volume, maybe you can read in it as Neo reads in the matrix

I see that the transformations are not all the same (there are now multiple transformations in the nifti header...) but SPM says that the 2 volumes are registered.
One suggestion should be that BV and SPM don't use the same transformation matrix, so my questions are:

-can you see where the problem is ?
-Does anatomist apply one of the transformation matrices by default at the loading of a volume?
-if yes, which transformation matrix is used by anatomist at this point?
-When applying the vol->referential->apply SPM/NFTI referential process in anatomist, which matrix transformation is used?

Thank you for your help (one more time)

Guillaume

[riviere]

Hi Guillaume,

Denis, I guess you're bored with the NIFTI convertion issue, sorry for this new post.

Yes, of course! but that's life...

The 2 figs attached hereafter are the snapshots of the respectives "browser window" of each volume, maybe you can read in it as Neo reads in the matrix

Sure I do...

-can you see where the problem is ?

Yes!

-Does anatomist apply one of the transformation matrices by default at the loading of a volume?

It depends on your settings in Anatomist, but if you have left the default values, NO.

-When applying the vol->referential->apply SPM/NFTI referential process in anatomist, which matrix transformation is used?

All of them if they are not identical. Here each volume stores 2 times the same matrix so it's only actually 1 transformation per volume.

The answer of your problem is in the referentials, not in the transformations. Here each volume stores a transformation to another referential. Destination referentials are listed in the "referentials" field. Here they are all "aligned to another [unspecified] file". This code in Nifti files doesn't specify a precise referential, so Anatomist cannot identify those referentials to be the same. In SPM all transformations are assumed to go toward the same common referential, but Anatomist does not do this assumption (just because it is not always true and it would sometimes break the referentials/transformations system in Anatomist and BrainVisa).

The solution is to manually specify that these referentials are the same: in anatomist, open the referentials window, and draw an "identity link" (ctrl+left mouse button) between the destination referentials of the transformations. Then view the volumes in any referential connected (in the referentials graph) to the images.
Another solution would be to indicate a common unique identifier (UUID) in the referentials field (it is stored in the .minf file) (you would need to generate a suitable UUID using pyaims or soma python modules).

Does it make sense for you ?

Denis

[guillaume]

Hi Denis, thanks for your help,


>> -Does anatomist apply one of the transformation matrices by default at the loading of a volume?
>It depends on your settings in Anatomist, but if you have left the default values, NO.
where can I tune this setting?
There is something that I don't understand: if not any transfo is loaded, how does anatomist knows the voxel size? (it was written in the .dim in the GIS format but there is not any "voxel size" field in NIFTI, and SPM uses the diagonal of the matrix if I'm not mistaken).


>> -When applying the vol->referential->apply SPM/NFTI referential process in anatomist, which matrix transformation is used?
>All of them if they are not identical. Here each volume stores 2 times the same matrix so it's only actually 1 transformation per volume.
Does that signify that if we apply the vol->referential->apply SPM/NFTI referential process in anatomist, and that the nifti header contain let's say 2 different matrices, M1 and M2, then anatomist applies M1*M2?

>The answer of your problem is in the referentials, not in the transformations. Here each volume stores a transformation to another referential. Destination referentials are listed in the "referentials" field. Here they are all "aligned to another [unspecified] file". >This code in Nifti files doesn't specify a precise referential, so Anatomist cannot identify those referentials to be the same. In SPM all transformations are assumed to go toward the same common referential, but Anatomist does not do this assumption (just >because it is not always true and it would sometimes break the referentials/transformations system in Anatomist and BrainVisa).
-Could the solution be to associate this [unspecified referential] to the "Talairach-MNITemplate-SPM" referential, already proposed by anatomist (when we find the string "spm" in the nifti field "descrip")?

>The solution is to manually specify that these referentials are the same: in anatomist, open the referentials window, and draw an "identity link" (ctrl+left mouse button) between the destination referentials of the transformations. Then view the volumes in any >referential connected (in the referentials graph) to the images.
As usual you're right and this solution works.
However, it's a litle bit fastidious, so I would try the second one:
>Another solution would be to indicate a common unique identifier (UUID) in the referentials field (it is stored in the .minf file) (you would need to generate a suitable UUID using pyaims or soma python modules).
>Does it make sense for you ?
Well, not precisely because I have no .minf associated to my nifti files.
-Do you mean that I should create this .minf and give the UUID?
-Could you please give me an example of command line to generate a suitable UUID?
-Should this UUID be the one associated to the "Talairach-MNITemplate-SPM" referential, already proposed by anatomist?
-Isn't it possible to modify directly the "referentials" field in the nifit header?

Be carefull Neo, Mr Smith is everywhere!