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.
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.
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.
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.
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