Export to SPM: erroneous coordinates of origin in Nifti output file


I noticed that after updating to the current Brainstorm version (February 2021), the 4D export to SPM from my previous protocols produced Nifti files with a correct origin (i.e. at the anterior commissure). However, creation of any new protocols after the update is currently leading to the origin coordinates being assigned to the very extreme of the Nifti image. See attachedincorrect_origin correct_origin

After a lot of trial and error (I am talking days:), I managed to work out that this appears not to be due to any differences in electrode locations, head model or lead field configurations, but rather a simple change in the default anatomy file (ICBM 152). Double clicking on it in Brainstorm February 2021 version it appears the World coordinates are already present and equal to the MNI coordinates, whereas the older ICBM 152 template (Brainsuite 2016) does not have World coordinates initially defined at all. See images attached.

Essentially, the oolder_default_anatomy_ICBM_152 new_default_anatomy_ICBM_152 rigin is correctly exported only when using the old ICBM 152 template, which is not the case if one uses the new ICBM 152 template.

Let me know of course if you find similar behavior on your end, and if so, I hope this can be remedied in future releases.

Many thanks, Tomas

Hi Tomas,

There were some random things done in the .nii export.
I tried to straighten than up a bit. The sform/qform matrices saved in the .nii files are now more correct.
Since there are cases where I now save both qform (scanner referential) AND sform (normalized or aligned referencial), some other things might change: I don't know how SPM12 deals with this.

Update Brainstorm, try it again, avoid using the option "Cut empty slices" because it removes all the transformations available in the original images, be careful with the .nii files you export with Brainstorm.
Please let me know if you find other cases in which you get incorrect or questionable coordinates in .nii files generated with Brainstorm.

Thanks for reporting this!


1 Like

Thanks Francois. I just tested it and the origin seems to be fine when the spatial downsampling is set to 1 (i.e. no spatial downsampling). However, if I use 7 for example (as the files are too big), I get a wrong origin in the new image. Interestingly, the origin is at the exact voxel coordinates of origin of the non-downsampled image. Hence, it is off by a mile as the downsampled image now contains much fewer voxels that are part of the brain.

Merci et bon courage,

Sorry for the reponse delay, I had no idea how far this apparently simple bug was going to take me...
I ended up completely reorganizing the way the volumes were downsampled, and how the transformation matrices (sform/qform) from the .nii files were generated from Brainstorm. I was painful to do, but very much needed...
Thank you for reporting it!

I hope this is already working better, but there might still be some +/-1 voxels or millimeters errors in the conversions between the different coordinates systems.
You can update Brainstorm and try again.
Please keep on checking carefully the coordinates you observe in the .nii files generated with Brainstorm and let me know if you find anything suspicious.

1 Like

Wow, thank you for the still very rapid debugging Francois! All these improvements should make Brainstorm even better :slight_smile: I am looking forward to testing the SPM export and will let you know if anything might still be amiss...
Cheers, Tomas

Hi Francois, just tested the export to SPM and I think the output is kosher, provided one does not tick cut empty slices.

On another note, you did say please report anything else that might be suspicious :slight_smile: In this case, I wanted to test how the EEG downsampled image overlaps with the original, but equally downsampled anatomical MRI (i.e. are the new origins in the same place). So I therefore tried to equally spatially downsample the ICBM 152 template resolution to 7mm (see attached) . The image produced (if you double click on it) was tiny, given that the number of voxels is still from the original (non-downsampled) space.

Many thanks again for all your efforts!



If you multiply the voxel size by 7 and keep the same number of voxels, then the total volume size increases by 777. Within this very large volume, the size of your brain remains the same, but it is now displayed in an ocean of padded zeros.

If you want something that "looks about the same": divide the number of voxels by 7 in each direction.

OK got it.

One last thing (hopefully!): I just tried exporting the hilbert-transformed source magnitude data to 4D SPM and I don't succeed when usually it worked. I get the attached error:

Not sure if this is related to the new code changes....



Many thanks, Tomas

This error, I don't understand.
It means that the index of the frequency band "broadband" (3) does not exist in the timefreq file.
I don't think this can be related with the previous changes, as this error happens even before the conversion of the surface results.

Maybe there is a combination of options to generate the input files that leads to having a wrong list of frequency bands...
Can you post screen captures of the database (showing the file you want to export) + the options of the Hilbert process (including the advanced options panel)?

I manage to open the Hilbert-transormed data directly by double clicking on it and the source-space data is definitely there.


When exporting a file with only one frequency band after exporting a frequency band with an index > 1, it was trying to reuse the previous index instead of resetting it to 1... very specific bug... fixed here:

Thanks for this very thorough debugging session you're doing here :slight_smile:

Hi Francois,

I don't think this is a bug but I wanted to run it past you so I can maybe learn how EEG is processed in Brainstorm.

I tried comparing the source maps between the raw sLORETA data samples and their Hilbert magnitude transformed data samples (both at the same sampling frequency). Interestingly, when I bring up two simultaneous windows and scroll sample-by-sample, the umages are sometimes very similar and sometimes very dissimilar. Could you tell me why this is so? I am wondering how this pertains to calculating/combining the magnitudes of the XYZ orientation vectors. I imagine it might have something to do with the positive/negative polarity of the vectors but can't put my finger on it. I attach screen shots of similar and dissimilar samples at the same time stamp, with the second screenshot being 25 ms later. Upper window is raw sLORETA and lower window is Hilbert magnitude of sLORETA data.
Thank you!


The sLORETA signals oscillate around zero, with 3 signals per source point.
The Hilbert envelope is the envelope of the signal filtered in a given frequency band, only one value per source point.
There is actually very little chance that the values of the two match.

To explore better the temporal dynamics of the various signals: create a volume scout, maybe with one point only from the source grid, and plot the time series (option RELATIVE) for the two files.

OK thank you, yet the SPM export contains one value for the sLORETA signals at each voxel (i.e. ticking "absolute value", not relative). This is the norm value correct? So I am wondering what is the mathematical relationship between this norm value and the Hilbert magnitude (which will also be positive)?

Yes. Everything you extract from this file goes through to bst_source_orient.m or process_source_flat.m with the option 'rms'.

This is the norm value correct? So I am wondering what is the mathematical relationship between this norm value and the Hilbert magnitude (which will also be positive)?

Once you've computed the norm of the three signals, you can't go back to the original signals and compute the Hilbert transform.
The other way around: the signals are filter in various frequency bands, then the envelopes of the Hilbert transform are summed, you can't can't get back to a norm of the broadband signal.
So you can't establish a direct link between the two.

Am I misunderstanding your question?

Hi Francois,

Sure its clearer now, thank you.

Regarding the spatial downsampling again: I think I may have unfortunately found another bug.

After 4D export without spatial downsampling (i.e. downsample factor = 1), the *.nii file contains only positive entries (as should be since I ticked "use absolute values of the sources"). Entries outside the brain are set to zero.


However, when 4D export with spatially downsample (e.g. downsample factor = 4), the *.nii file now contains also (small) NEGATIVE entries mostly outside the brain.



Many thanks in advance,

I used a spline interpolation for resampling the volume. It creates sharper and possibly more accurate low-resolution images, but it tends to create unwanted oscillations close to the sharp discontinuities (e.g. transition brain/background). These negative values you observe are these "rebounds" of the spline interpolation.

I did not realize they were going to be as many and as important as these.
I replaced the spline with a linear interpolation: smoother and with less surprises, probably more appropriate.

Thanks for your exhaustive validation of the .nii export! :slight_smile:

:v:t2: it also speeds up the export considerably !

Thanks, Tomas

1 Like