I have been attempting to analyze .rda files (2000/68 TR/TE) but each processing pipeline seems to have it’s own set of issues with our data files. I know .rda are already time averaged files, but the data didn’t seem to agree with Gannet.
Therefore using Osprey I am attempting to load through the jobRDA.m example with my own folder of one participant and one voxel located within (ON, OFF, and DIFF files all in folder). It loads the files fine however no data appears in the raw plots, despite seeing the headers with all the scanner parameters loaded properly. We are able to see the actual outputs on the scanner PC and with limited success using Gannet so I know there is data in there. I can’t advance past loading since nothing appears, but coregistering the voxel with the patient’s T1 works just fine.
Thanks for getting in touch. We have not implemented single-file RDA processing for MEGA data yet since it’s clearly recommended against using pre-averaged data. They are much more prone to cause subtraction artefacts that you can’t retrospectively correct for.
If you don’t have TWIX data at all, we can certainly make Osprey work with your data. Just be mindful that this is not recommended.
Thanks for the quick response, I was just attempting to replicate the steps from your youtube tutorial but with the .rda files I mentioned. The Gannet team (Richard/Mark) also suggested to avoid using .rda files.
We could move to TWIX moving forward but we are collecting data in a limited population of 20 MCI patients with scans pre/post intervention and we are currently halfway through our second participant so switching now would make the 1.5 participant’s MRS data a different format which isn’t ideal. That is why I am trying to make the .rda files work, which is what the Siemens tech suggested we use and we didn’t question that until I ran in to difficulties getting reliable outputs. We don’t have TWIX files saved out on these scans unfortunately.
Okay, then we’ll see that we’ll make this work in Osprey. Is there any particular reason you’re looking to move away from Gannet, e.g. can you clarify what you meant when you said “… but the data didn’t seem to agree with Gannet” in the opening post? Can you provide an example output what the data look like in Gannet and what you would expect them to look like? Osprey won’t magically save compromised data.
I have some old single-file RDA data that I can use to implement the function (may take a few days), so no need to share data at this point.
There isn’t a particular reason I just want a pipeline that would provide reliable numbers. I ran in to some fitting errors using the .rda files for some voxels using Gannet, probably due to the file type, and they simply errored out. The Gannet team mentioned our shimming may not be great, although we are using the automatic shimming option in the scanner our MRI tech thought was best as opposed to manual and longer options (we are slightly time limited shooting for T1/T2, resting state, 2-3 MRS voxels, and DTI when time permits). The save output has separate ON, OFF, and Difference rda files it saves out, which we can also see visualized on the scanner right after collection.
Thanks again, this is our first time collecting MRS data so looking for the proper methods in the literature has returned a lot of differing parameters. For example knowing what a ‘correct’ value of GABA/Glx should look like is not as easy we we had envisioned.
Yes, looking at this output, the shim is by unfortunately by far not sufficient enough to provide reliable estimates. MRS requires some attention to the shim quality - which can mean spending extra time getting it right, especially on older Siemens systems this may sometimes even include manually optimizing the shim currents. If all datasets look like this, I would not recommend placing too much trust into the outcome. Poor data quality is also quite a likely explanation why Gannet fails to properly process or model your data. The display on the console is not really a great substitute for looking at your data (or judging the quality), since its options are relatively limited.
The desire to get as many datasets as possible out of an hour of scan time is understandable, but the risk is always that all datasets end up with sub-optimal quality. An additional complication can arise from running edited MRS immediately after fMRI or DTI acquisitions, since these can induce drift on some systems, and that drift can’t be corrected properly depending on its extent.
I recommend that you eat up the loss of 1.5 datasets (which very likely won’t be usable at all) and save the next 18.5 by spending more time on the shim, and exporting TWIX data. I’m also happy to assist reviewing or setting up future protocols that you may want to design. MRS is tricky, edited MRS even more so, and it’s easy to get tangled up in the (not necessary consistent or helpful) literature, especially when it’s the first time venturing out into MRS world. For MEGA-PRESS of GABA, the classic Mullins paper is a good starting point; for MRS in general, I’ll gladly point you to the list of consensus papers that has come out over the last couple of years. We’re currently working on an evidence-based “Beginner’s Guide to MEGA-PRESS of GABA”, but that will take a few more months, I expect.
Do not hesitate to ask any further questions that you may have - providing a path for MRS newcomers to reach out for advice was one of the main motivations to create this forum.
I certainly wish I would discovered this forum sooner but that is my bad. I was so concerned with rda v TWIX formats I never considered shimming as a factor that would need customizing.
I’m going to look through these articles and another I found (MRS Shimming: An Important Point Which Should not be Ignored) and even if we end up not being able to use the first two patient’s MRS data, the current lull in recruitment will give us time to make adjustments as needed. Thanks again in advance for the questions I will certainly have.
