Issue on OspreyProcess in Siemens megapress twix data

I’m beginning to work with Osprey and am encountering an issue while processing Siemens MEGA-PRESS data in TWIX format (3T, Vida, syngo XA31, Siemens MEGAPRESS product sequence ‘svs_edit’, TR/TE = 3000/68, GABA editing at 1.9ppm, 96 edit-off and 96 edit-on single scans, 4096 fid points). After loading the TWIX file, Osprey processing fails with an error message:

Error using op_phaseCrCho (line 37)
ERROR: Can not operate on data with extras dimension! ABORTING!!

Error in op_measureDrift (line 46)
[in,~] = op_phaseCrCho(in, 1);

Error in op_robustSpecReg (line 63)
driftPre = op_measureDrift(in);

Error in OspreyProcess (line 258)
[raw, fs, phs, weights, driftPre, driftPost] = op_robustSpecReg(raw, seq,
0,refShift_ind_ini); % Align and average

Error in OspreyPipe_20240518 (line 10)
MRScont = OspreyProcess(MRScont);

It appears that Osprey is having trouble assigning the edit-on/edit-off data dimensions in the TWIX file. For reference, please check the example TWIX file, my Osprey Job File, Osprey loading output, and my Osprey Pipeline at this link: UKH Cloud (password: jwfHmzZS).
Thanks in advance for helping me!

Hi @AlexGussew,

Great to hear that you have picked up Osprey and thank you for reaching out.

Actually, we have been getting reports from different Siemens users in the last weeks with various XA… software versions. I have fixed the issues related to your software version (XA31) in a new version on the develop branch on GitHub just now.

Please let me know if it is working for you now.


Thanks a lot for quickly solving the issue. It works fine now. As I saw in the GitHub log, you modified the Twix load function in the FidA library (…\libraries\FID-A\inputOutput\io_loadspec_twix.m) to enable specification of the SIEMENS syngo version. That was also my initial approach when I experimented with it in my local Osprey version.

Currently, I’m still having issues running your latest io_loadspec_twix.m version, as it fails to modify the Twix header in line 58 (twix_obj.image.softwareVersion = twix_obj.hdr.Dicom.SoftwareVersions(index:index+3);). It treats twix_obj as an object (instead of a structure) and says that ‘twix_obj.image.softwareVersion’ is a ‘read-only’ property that cannot be modified. Therefore, I added an additional ‘try-catch’ sequence in my local io_loadspec_twix.m version:

Mayby you have a hint how it can be solved more in a more elegant and universal way.
Thanks a lot!

Hi @AlexGussew,

This seems to depend on the individual machine that is used.

I have now modified the code to directly write the version string into a variable (your catch statement), as we are not using the softwareVersion entry in the twix_obj downstream. I guess this was a piece of legacy code that had worked to date, but has become unnecessary in the meantime.


Hi Helge,
thank’s a lot - it works fine now.
best wishes

1 Like