Hi @alex,
Yes, I noticed in the plot above that one FID (in red) didn’t seem to be affected at all and had a perfectly flat baseline! Very interesting.
Thanks @noeskera for your response, too.
Cheers,
Georg
With this bug, it is poor luck that you get reasonable data (even at some locations in the pfile). Size of the pfile is as all coil elements were used but in the header the reduced number of coil elements is stored. But that doesn’t mean that the reduced number of frames are stored correctly at wrong locations, they can sometimes be reasonable, sometimes just constant values or “noise” at “arbitrary” locations.
I can guarantee that this wasn’t by design (@alex) but just a “surprising” bug that we fixed in the meantime but could do that just for the new upcoming releases.
1 Like
Got it – thanks 
I’ve removed my unreliable workaround.
1 Like
Thank you for your help Ralph. Using manual coil selection to select all the elements of the coil elements works and gives good quality spectra with the MEGA Press sequence, at any rate with the MRS phantom. We will have to do a couple of test scans with a healthy volunteer before we start collecting data for the planned research study.
Best regards,
Jon Hauksson, Umeå
1 Like
Nope. GE seems to be pretty cagey about sharing code that would help us figure out how to parse scan archive data. They have a tool that converts scan archives back to P-files, but they only share it with GE sites. Caused us some headaches for HBCD. @noeskera might be able to speak in greater detail to this.
Sorry I am not a spectro expert but found that thread looking about info on raw export for GE. Looking at the ScanArchive shared above, these are hdf5 files, are easy to read with any hdf5 lib, contains some data arrays and some metadata (xml…) stored as strings in byte arrays.
It is also a supported format in ISMRMRD ge converter GitHub - ismrmrd/ge_to_ismrmrd: GE to ISMRMRD converter .
Hi @bpinsard. Thanks for the link; this is interesting, but as far as I can tell it still depends on the Orchestra API (hence, is probably only available to GE sites). While the basic HDF5 structure is fairly straightforward, the implementation may encapsulate large data blobs which are less trivial to interpret.
In my opinion the best approach would be to encourage on-scanner conversion to an open standard – ie, using GE’s Orchestra libraries to import the data, then export out to NIfTI-MRS (rather like the ge_to_ismrmrd tool you linked). A major advantage of this approach is that we won’t need to update all the other tools to accommodate changes in header format, since this ought to be handled reliably by the vendor-supplied libraries.
Thanks for the precisions, I had not realized that they packaged a proprietary format inside a standard format.
Hi @alex,
Just curious: We’re still on an older GE software version, so we have yet to encounter the ScanArchive data format option. Does Orchestra allow easy conversion to NIfTI-MRS, or did you mean to convert ScanArchive to NIfTI-MRS using Python on the scanner?
Mark
We still have Pfiles available in the usual location on our newest GE systems (MR30.1), as well as the ScanArchive data.
I was thinking more along the lines of conversion using Python on the scanner – as far as I’m aware there’s no native NifTI-MRS functionality in Orchestra itself, but the SDK has python bindings which should in principle give fairly convenient access to all the ScanArchive (or Pfile) components necessary for conversion.
Since current versions of Gannet, Osprey and spec2nii can all read the 30.1 Pfiles, I guess this isn’t a particularly high priority for us.
1 Like
Gotcha!
For my (Gannet’s) part, we will continue to support P-files.
Mark
1 Like