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!
Meg
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
try
tri = delaunayn([vox_corner.ā; [VoxOffs(1) VoxOffs(2) VoxOffs(3)]]);
catch
disp([vox_corner.'; [VoxOffs(1) VoxOffs(2) VoxOffs(3)]]);
end
and look if some of the displayed values doesnāt make sense (Inf or NaN).
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:
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.
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:
I uploaded both rda and twix files to Google Drive in case you also want to take a closer look: MAG_MRSFiles.zip - Google Drive
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?
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?
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.
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.
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.
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!
@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.
