I am creating a job with appropriate settings, after consulting with a staff who is more experienced with Matlab than me. The thing is, I am getting errors that mention:
Error in read_dcm_header
Error in OspreyLoad
Error in osp_loadspec_dicom
Error in osp_onload
Error in GELoad
Error in io_loadspec_GE
I am not sure if I can post a picture as I could if necessary.
To add further information, the problem I think is occurring has to do with the p file for the MRS dataset not being able to get retrieved properly by Osprey.
Hi @arm,
Could you please include the full error message(s), which will contain more useful diagnostic information for tracking down the issue? I can’t see how the functions you list here fit together; have you combined error messages from a couple of different attempts?
Also, could you please clarify what data you are using – the sequence and the scanner version?
I think broadly there may be some confusion about which files you are selecting, but we’d need to check these details to be sure. It may also help if you upload a copy of your jobfile, provided there isn’t any sensitive information in the filenames etc.
Yes. I am entering a P file from a T1 scan, which would then go to the unedited format since it is not through Megapress. After inputting the P file and using an appropriate basis set used in other previous Matlab analysis for unedited data specifically, I am coming across these error messages.
Index in position 3 is invalid. Array indices must be positive integers or logical values.
Error in GELoad (line 316)
Error in io_loadspec_GE (Line 31)
Error in osp_LoadP (line 48)
Error in OspreyLoad (line 228)
Error in osp_onLoad (line 35)
I can ask my PI whether sharing the job file would be acceptable through here and I can invite him to respond further.
Thank you for your response Alex
Update:
The sequences we are using are sLaser (GE product sequence for version MR30.1) and jpress (we call it NFL-PRESS, and it’s a GE WIP, work in progress, spectro sequence). There is no editing involved in either of them.
The data were acquired from sequences using a phantom. I can work on uploading those files here after they are de-identified.
Thanks for the extra details.
For the sLASER: I assume you have an up-to-date version of Osprey? There were updates in Oct 2023 and Feb 2024 which should allow it to read the MR30.1 P-files.
I’ve used Osprey successfully with GE product sLASER on MR30.1 (tested last week). In a standard configuration (eg, just taken from the GE protocol template), it works well – but it’s a highly flexible sequence and can be configured in ways which defy Osprey’s expectations. So it would be good to see exactly how you have this configured (settings from the detail and advanced tabs on the console).
I’m not that familiar with NFL-PRESS; as far as I can tell it uses a different addition scheme and may only store every second frame; if the Osprey reader isn’t expecting this it’s possible that it mis-calculates the number of water reference acquisitions. Some sample (phantom) data would help to figure this out.
P52736.7 is the one acquired using slaser and the 32 channel coil and P42496.7 is acquired using the nfl-press and the 48HA coil.
The P files can be found under this folder:
https://drive.google.com/drive/folders/1bnyOGnRj1KscXB2cCttr_RFIvqlYlUHZ?usp=sharing
Thank you for your response and support so far Alex
Sending a comment to check back in.
Hi @arm,
Sorry for the delay – I was trying to replicate this issue on our local system.
Just to be sure: is this single-voxel sLASER data, or are you using spatial encoding/CSI (freq, phase > 1)? It looks like you may have the latter, in which case you won’t get water reference data as you would for the single-voxel case. I’m also not sure to what extent Osprey can work with CSI data (I’ve never tried)
No worries Alex! I appreciate the message. This is the response I received from my supervisors regarding the data:
The slaser data for your project were acquired without phase encoding. It only flips the sign of each FID in the pfile. The first eight frames are FIDs without water suppression
Hi again,
Just re-visiting this: are you certain you are using the latest Osprey version (develop branch)? As far as I can see, your sLASER data should load without error in that version:
For the NFL-PRESS – I’m not at all familiar with that sequence, and neither are the standard Osprey import functions. Without knowing what the sequence is doing, it’s difficult to be sure how to correctly interpret the data: is there supposed to be some contrast or extra variable dimension, or can all the metabolite frames just be combined together into a single averaged spectrum?
If it is meaningful to just combine all the frames, you could try using this modified version of GERead.m. After confirming that you have the latest Osprey installed, save this into your osprey/libraries/FID-A/inputOutput/gannetTools folder (perhaps take a backup of your original version first).
This version tries to guess the layout of data which doesn’t conform to its expectations. It’s an imperfect solution (there’s a ton of ways it could go wrong), but it works well for your data so might be good enough for your current needs.
GELoad.m (11.8 KB)
Hello Alex,
I just checked and I believe I had a significantly older version of Osprey. I just checked and I have the 28.0 version now based on what I could find. Is that the most current version?
I can use GELoad.m for the Osprey library as you mentioned (I can create a backup). Thank you for this!
Alex,
Can you give me a rundown of the steps involved? Did you use the DICOM folder or file?
We received this error:
exceeds the number of array elements. Index must not exceed 0.
Error in osp_combineCoils (line 47)
isSpecial = strcmpi(MRSCont.raw_uncomb{metab_ll,kk}.seq(1), ‘special’);
Error in OspreyLoad (line 287)
[MRSCont] = osp_combineCoils(MRSCont);
Error in osp_onLoad (line 35)
MRSCont = OspreyLoad(MRSCont);
Error while evaluating UIControl Callback.
We received this error when reviewing the NFL_PRESS data (unedited) and the sLASER data. We used the Osprey basissets (under the FIT folder for 30 specifically) and we also ran it without basissets. We also included a T1 DICOM folder and ran without the T1 DICOM folder.
THE GOOD NEWS: We were able to load the job itself. (time ranged but it took under 1 second, which is really nice). Any further support would be much appreciated.
On a side note, we are working on the M4 chip for Mac as well if that may contribute to any problems. We have updated to the latest SPM (works fine) and we have Osprey 2.8.1.
Thank you for your time!
Sorry, this looks like a new bug introduced on Sept 10 (so my “latest” version was actually a few days out of date when I checked this). Bad timing!
I’ll follow up, but for a quick fix for your data replace seq(1) with just seq on that line.
In terms of steps, at this stage literally just “Create Job”, choose “MRS Data”, select the P-file, “Create Job”, then load. That’s sufficient to check that the basic data import works; of course for the eventual analysis you would also want to include the structural T1, maybe choose the basis set etc – but those aren’t needed until the later steps.
Sorry, this looks like a new bug introduced on Sept 10 (so my “latest” version was actually a few days out of date when I checked this). Bad timing!
I’ll follow up, but for a quick fix for your data replaceseq(1)with justseqon that line.
Thanks for your response Alex. Our team is going to be looking into it from our end. It has been my first time attempting to work with Osprey before so you have been a big support!
In terms of steps, at this stage literally just “Create Job”, choose “MRS Data”, select the P-file, “Create Job”, then load. That’s sufficient to check that the basic data import works; of course for the eventual analysis you would also want to include the structural T1, maybe choose the basis set etc – but those aren’t needed until the later steps.
This is helpful to know. We were doing similar steps but wanted to check in to ensure we were following the same steps.
@alex You are not going to believe it (I hope you do!). We got it to work. We only ran issues with the coregistration section. We received these error codes:
Index in position 3 is invalid. Array indices must be positive integers or logical values.
Error in coreg_p (line 180)
A(1) = X(e1,e2,e3);
Error in OspreyCoreg (line 181)
[vol_mask, T1_max, vol_image, voxel_ctr] = coreg_p(MRSCont.raw{1,kk}, MRSCont.files_nii{kk}, maskFile);
Error in osp_onCoreg (line 47)
MRSCont = OspreyCoreg(MRSCont);
Error while evaluating UIControl Callback.
We messed around with the code (but reverted back to how it originally was) and found out that (e3) was 0 from the disp() function. Not sure if that is supposed to give us this error or if there is something with the data itself, or if there is an alternative that can correct for this like you provided through GE_Load.
Checking back in to see if there are any updates for the co-registration section @alex
