CoRegistration Error in Osprey with NIfTI

Hi there,

Thanks so much for all of your help! We just upgraded our Siemens scanner and I am trying to look at our 3T PRESS data via Osprey. All is going well so far, but when I get to the coregistration step, I get the following error:

On the new scanner, our MPRAGE only comes out as one DICOM file (rather than a bunch like it used to). We were still able to convert it to NIfTI using heudiconv, which is what I uploaded into Osprey for the T1 nii file. I also tried loading in the one DICOM file into Osprey and that wouldn’t work either.

Can anyone provide some help here? I’m pretty stuck
Thanks so much!


  1. What’s your MRS data format? TWIX? I think in RDA files I’ve seen the geometry header fields change, but it’s odd that the error message doesn’t seem to happen in the loader.
  2. Looks like your MPRAGE is coming out as enhanced DICOM now. Can you try converting with dcm2niix instead of heudiconv?

Hi Meg,
is it always the same error? If I’ve looked correctly, the error appears at a step where only spectroscopy data are used (none of the MPRAGE or data based on it). I would guess that something with reading in the geometry data of the spectroscopy voxel went wrong. A quick way to check these values can be to replace (in coreg_siemens, line 173)
tri = delaunayn([vox_corner.‘; [VoxOffs(1) VoxOffs(2) VoxOffs(3)]]);
with something like
tri = delaunayn([vox_corner.’; [VoxOffs(1) VoxOffs(2) VoxOffs(3)]]);
disp([vox_corner.'; [VoxOffs(1) VoxOffs(2) VoxOffs(3)]]);
and look if some of the displayed values doesn’t make sense (Inf or NaN).


Hi @admin and @hraum!

Thank you both SO much for your quick responses- I’m so appreciative (so is everyone at Brown!).

To answer Georg’s question first, I am uploading rda files. I originally the Twix files (.dat) but got the following error when I pressed the “Load Data” button:

I tried uploading the rda files after using @stevehui’s script that converts the headers to be compatible with LCModel, and again, got it to work through the “Model Data” stage, but got the same error I was getting before with the non covered rda files at the coregistration stage:

To answer Heiner, it’s always one of these two errors. At least it is good to know it is not an issue with the MPRAGE. I went in and replaced those lines with what you suggested:

and got the following error:

I tried just running the coreg_siemens script and got this error:

Screenshot 2024-02-22 at 10.58.43 AM

If it would be easier for me to send the rda file over to you, just let me know.
Thanks so much for your help!!

Hi Meg,
from the many displayed NaNs (all fields of vox_corner are NaN), some data of geom.rot or geom.size must be corrupted. The error from you in @admin 's link is also very interesting (‘Unrecognized field name “VOINormalTra”.’) because it goes in the same direction.
The error from running coreg_siemens is normal without input arguments.
You can look at the .rda files in a matlab structure e.g. with
data_before =io_loadspec_rda(‘filename_before_stevehuisscript.rda’);
data_after =io_loadspec_rda(‘filename_after_stevehuisscript.rda’);
and look in the geometry structure (especially size and rot).
If there is a difference, ‘io_writerda’ makes problems. If you have a problem in both, ‘io_loadspec_rda’ has problems with XA or your data are corrupted.
It is also good to look at your ‘.rda’ files with a text editor and compare your results in matlab with fields like VOINormalSag, VOINormalCor, VOINormalTra, VOIRotationInPlane, VOIThickness.

After that, we hopefully will have narrowed down what is causing the problem (and hopefully solve it) and look if I need some test data to help.


Hi @hraum!

Thank you so much!! Something strange is going on.

I just looked at both files, and in the data_before files, all of the variables (NormCor, NormSag, NormTra, VOI_InPlaneRot, VOIThickness) are the exact same number (2.2251e-308).

With Steve’s script, NormTra is 2.2251e-308, but NormCor, NormSag, VOI_InPlaneRot, and VOIThickness are equal to 0.

So something funky is definitely going on with the scanner or the data are corrupted. Though I’m not sure why all of the values from Steve’s script are now zero except the NormTra variable.

I also tried opening the twix file with io_loadspec_twix and got that same error I got when trying to load them before:

Screenshot 2024-02-23 at 10.08.36 AM

I uploaded both rda and twix files to Google Drive in case you also want to take a closer look: - Google Drive

Thank you again!!

Hi @hraum,

I just looked at one of my rda files before the XA30 upgrade and the geometry values all look completely normal (indicates the size of the voxel, thickness, etc.). It looks like the upgrade is erasing the geometry data? Or not capturing it anymore?

Very strange.

Hi Meg,
I just had a look at .rda file from our Prisma (XA30 SP2 - I’m not 100% sure about the Service pack). It seems coordinates are a-okay.

What I use for Osprey analysis are DICOMs with spectra though - have you tried using those?

We have opted for intraoperability mode for export, not enhanced - some issues there too, but slightly fewer than enhanced (some clinical trials are for example very clear they don’t even accept enhanced mode DICOMs).

Side note, I would suggest not calling XA an “upgrade”. Siemens made too many unforced errors in development and the number of (common research) scenarios they have obviously not tested properly is alarming.

Hi @meggon,
I’m looking at the 157_GLX.rda file an seems that the nomenclature between VE and XE changes.
In VE, you have your voxel midpoint definded with VOIPositionSag/Cor/Tra and the orientation of the voxel is definded by a normal vector of the voxel and a rotation (VOIRotationInPlane) around it.
In XA, you have your voxel midpoint definded with PostionVector[0/1/2]. This point is easy to translate.
But for voxel orientation, it’s defined by the three slabs of excitation/refocusing. I think that MidSlabPosition[0,0/1/2] is analogous to the norm vector in VE, but you need also the other two because of the rotation. I would guess that a combination of this three slab norm vectors will give rotmat in line 139 coreg_siemens.m directly . But I have to think about it.
Maybe, there is already a script to read in .rda files from XA, @admin?


Hi @hraum!

Thanks for taking a look at my .rda file. Ahhh got it- that makes sense that the variables are named differently.

Any help solving this would be fantastic, especially if there is a script to read in .rda files from XA @admin.

To @peter’s point, I tried loading in the DICOMs into Osprey and that also did not work because it is in the enhanced format. I’m going to try “un-enhancing” it and retrying.

Again, huge thanks to all of you for the help :slight_smile:

Also, @hraum and @admin- would this issue be the reason why my Twix files won’t load in properly? Thanks!!

Hi @hraum and @admin- I ended up reading the geometry header information of the DICOM file using the read_dcm_header.m script and manually entered that information into the RDA file geometry headers. I did this for the reference file too. From that, I got this error:

So it looks like the header information is not being properly loaded into the rda files and there are still values missing outside of the geometry variables.

Hi @meggon,
can you test Steve Hui’s script with this modification?
io_loadspec_rda_modified.m (18.2 KB)
io_Siemens_XA2VE_modified.m (1.4 KB)
io_writedata_modified.m (6.0 KB)

A quick try to change nomenclature to VE. In io_writedata, only writing NormTra was added and in io_loadspec_rda some more adaptions.
Maybe VOIPhaseFOV and VOIReadoutFOV are swapped (too symmetric voxel to distinguish). To VOIRotationInPlane could also be prone to errors.


Hi @hraum ,

You are the BEST!! It works!!! I am so thankful for all of your patience and help (so are all of the other spectroscopy researchers at Brown). You, @admin, and @stevehui saved the day! :tada: :confetti_ball: :raised_hands:

Much thanks and gratitude,

1 Like

Just seeing this. @hraum any chance you might package the modifications to io_loadspec_rda into a PR for Osprey? that would be AMAZING.

@meggon, maybe you should try a voxel with 1 x 2 x 4 cm³ and look if phase/readout are mixed up. Best is, to control the coregistration with your voxel placement at the scanner. I haven’t tested it by my own (still VE11 here).

@admin, I hope it worked. I’ve only been a github user since yesterday. :wink: