Dear comunity,
I would like to request your assistance regarding a problem affecting spectroscopy files generated by our Siemens scanner after upgrading the software to syngo MR XA60.
Since the update, we are experiencing difficulties opening and processing the data using Osprey. The files appear to be incompatible or are not being correctly recognized by the software.
Could you please advise whether there is an updated workflow, patch, or recommended configuration to ensure compatibility with the new Siemens format?
We would greatly appreciate your guidance on how to proceed.
Thank you so much for your email. I will try to provide more details regarding the error I am encountering in Osprey.
Until recently, I have been working with data from a Siemens syngo MR E11 release without any issues, successfully performing loading, analysis, and quantification. However, our scanner was recently updated to syngo MR XA60.
Since this update, Osprey is unable to load the new data. As shown in the attached screenshot, the process fails during the OspreyLoad phase with the following error:
âUnable to perform assignment because the indices on the left side are not compatible with the size of the right side.â in io_loadspec_rda (line 101).
It appears to be a header parsing issue, specifically when the function tries to read the PositionVector. I have already tried some basic troubleshooting, such as checking for decimal separators (commas vs. periods), but the error persists.
I have attached the specific spectra files I am trying to load in this example so you can take a look at them and see if you can reproduce the error on your end.
Could you please let me know if you have encountered this with XA60 data or if there is a specific patch or configuration needed for this software version?
I am reaching out to you because we have been trying again to work with our Syngo X60 data. We have loaded a tested your script io_Siemens_XA2VE.m (developed about 3 years ago to handle XA-to-VE format transitions) on our new Siemens Magnetom XA60 data, but unfortunately, we havenât been able to make it work for our current RDA exports.
We have also performed extensive testing today to troubleshoot the issue, and I wanted to share the results with you to see if you have any insights or an updated version of the patch:
Failure with XA60 Exports: When applying the io_Siemens_XA2VE.m logic to the new XA60 files, the script fails to recover a coherent signal. We observe astronomical amplitude values (orders of 10^30 to 10^38) and the FID lacks any natural exponential decay, showing only isolated digital spikes.
Attempted Workaround via jMRUI: In a desperate attempt to rescue the data, we tried to manually export the raw binary data into a 2-column TXT format to see if jMRUI could interpret it. Our goal was to re-save it in a format that Osprey could eventually read. However, even with various bit-depth interpretations (Float32, Float64, Int32), jMRUI only renders flat-line noise.
Binary Mismatch: It seems the XA60 platform has changed the way it writes the binary block in the RDA files (possible encryption, compression, or a different header offset), as none of the standard encoding interpretations are yielding a physical signal.
Since we do not have the original Twix (.dat) files or spectroscopy DICOMs for these sessions, we are trying to find a way to fix the RDA reading process.
Have you encountered this behavior with the XA60 version of Syngo MR? Do you think the io_Siemens_XA2VE.m script needs a specific update for the newer XA line offsets or data types?
Any help or guidance you could provide would be greatly appreciated.
Tahnks again for your help. Here you have a copy of our whole MR protocol. MRS protocol is specified from pages 11 to 23 as we perform several measurements in the brain (Hippocampus and vmPFC). The protocol is in Spanish, so please tell me if you need any help with the translation.**
**As I mentioned before, we suspect the binary data block in the RDA file is not being mapped correctly by the current scripts, possibly due to a change in the XA60âs data header or offset.
Looking forward to hearing your thoughts after you check the PDF.
@Angela_Bernabeu, the protocol looks fine to me. The header in XA60 is slightly different from VE but Osprey should be able to handle it. Are you using the latest version of it on Github? I would suggest testing your protocol with a phantom (best with braino). Remove the saturation bands and set TE to 35 ms with a bigger isotropic voxel (30x30x30mm^3) and see how things work.
Of note, Osprey doesnât come with a basis set for TE 32 ms. The modeling maybe suboptimal or you can generate one for your data.
Thanks for the clarification. I should note that I am not using raw Twix (.dat) files. Due to our hospital workflow, the data is always exported from the clinical radiological workstation as .rda files.
We have been using this exact workflow with previous Siemens versions (VE line) for a long time without any issues. However, since the upgrade to XA60, Osprey is failing to load these new .rda files.
It seems that the XA60 software update has also modified the header structure within the .rda format, causing the Osprey RDA reader to crash.
Since we cannot modify the clinical export workflow to get Twix files, is there any chance the .rda reader can be updated to support the new XA60 header format?
Sorry to hear that you canât use twix.
But how about trying .DCM files?
They are exported from the scanner in a similar fashion as .RDA (first taken out to the scanner filesystem and then transferred outside). I expect it to agree with your clinical export workflow.
I just checked that XA60 .DCM are read-in correctly:
The only thing is, whether the sequence that you use supports resolving individual averages that are saved as .DCM, but the same is applicable to RDA.
In my understanding, RDA never resolves individual acquisitions (another reason to switch to DICOMs if twix is unavailable).
Thank you for your suggestion. Unfortunately, the technical staff told me that exporting spectroscopy data as .DCM is not possible in our current setup.
In addition, I already have a large number of patient datasets exported as .RDA files. I also asked whether it would be possible to reload the complete studies into the scanner console and re-export them in another format, but apparently this is not possible either.
So at the moment, RDA seems to be the only format available to us. Do you think there could still be a way to work with these files despite the limitations regarding individual acquisitions?
Unfortunately seems like these RDAs are corrupted. Even if you rewrite the code to read these RDA files (Iâve seen the commas in the header when exporting using SyngoVia station), the values are weird.
Just a quick update. I have identified the problem with the Siemens data: the technician anonymized the RDA files manually by opening them as text files. This process is likely the cause of the issue, as it may have corrupted the data.
I have checked the dataset, and with syngo MR XA60 Siemens RDA files there is still a problem when loading the spectra directly. However, this issue is resolved by converting the files into NIfTI format using the spec2nii software.
