I think I find a coding fault that may create error while utilising OspreyFit, and I’d like to share it.
OspreyFit has a section around line 130 that starts with “%% Delete redundant resBasiset entries” and rewrites one struct called “MRSCont.fit.resBasisSet.” It accesses water and metabolite data using FitNames{sf}(sf=1, sf=2), but only acquires metabolite data via “MRSCont.info.metab.”. To be more explicit, it uses the spectralwidth of metabolite to rename both cells (“w” and “metab”) in the struct (“MRSCont.fit.resBasisSet”).
So when another function named “osp_fit_Quality” requires these two cells again using the spectralwidth from water and metabolite respectively, the intended water spectralwidth can’t match with the cell name of water information ( because it names by metabolite spectralwidth), and it will shows the error “unrecognized field name np_sw_actual water spectralwidth” (for my data, it shows “unrecognized field name np_sw_4130_2400”, and the water is named “np_sw_4142_2400” by metabolite information)
I tried adding a pause before and after the part “%% Delete redundant resBasiset entries” to analyse my data, which clearly demonstrates that the water is named by the spectralwidth of metabolism (it is “np_sw_4142_2400”, but should be “np_sw_4130_2400”)
Although there could be a more elegant solution to this problem. By changing MRSCont.info.metab to MRSCont.info.(FitNames{sf}) according to the first screenshot i shared, the problem can be fixed quickly.
I have checked that the recent OspreyFit code they update recently and they haven’t make change to these codes. If anyone meet the similar situation, you can save your time by editting these codes.
The new users are restricted to upload more than one picture, so I will upload the OspreyFit code screenshot here, so that it may be easier for you to fix it.
I have a quick question: Why is the number of points different for your metabolite and water reference data? Not that this couldn’t be the case but I am curious whether this was set intentionally on the scanner or whether the load function is accidentally removing a wrong number of points before the echo for one of the scans.
Would you be able to share the data so that I can push a bug fix for this?
Thanks for your reply. I have checked the data again by Gannet, and found that the number of points are still different for metabolite and water reference data. This is because seperate acquisition was done for metabolite and water. However, as the the number of points are the same for metabolite in Gannet and Osprey, it is different for water, so there should be something wrong with the Osprey load function.
I may need to ask for the permission whether I can share the data with you. But I will try to fix it this weekend first.
By the way, can you share the “op_iterativeFatFilter” file? It is required by the “op_SignalFilter” function, but can’t find it in the files.
@Helge I think I got more information about why the bug I found above would happen. ( information for metabolite datapoints can’t get water files)
MEGA-PRESS will store some data points before the actual acquire, so the data analyse for calculating number of useful data points for PRESS and MEGA-PRESS would be different.
However, the acquired metabolite information and water information I used are acquired in separate scans for each individual, MEGA-PRESS for metabolite and PRESS for water.
I try to use Gannet and Osprey to analyse the data separately.
Gannet identifies the sequence type of input files separately for water and metabolite so it calculate number of data points right. While Osprey default that the metabolite and water files use the same sequence( so Osprey naturally default that the data points for water and metabolite should be the same, which is understandable, but will get error in such situation).
For my data using Gannet, the data points is 4190(Total points stored in the water twix files) -0 (because it’s PRESS sequence)=4190 for water, and 4160(Total points stored in the metabolite twix files) -18( data points before the actual acquire because of the MEGA-PRESS sequence) =4142 for metabolite.
However, when using Osprey. It just accepts that the sequence for water and metabolite are the same (MEGA-PRESS). So when calculating data points using Osprey, the data points for metabolite are the same, but it’s wrong for water:4190(Total points stored in the water twix files) -62 (use wrong information)=4130 for water(Wrong).
The code that generate wrong information about the data points number that needed to be delete (leftshift) occurs around the lines 563 in “io_loadspec_twix.m files”. I am still trying to find the right way to fix it now, but it’s good to know where the errors comes at least.
Thank you for the detailed description and for figuring out the bug.
Could you tell me which software version the data was acquired on? The readout of PRESS data from Siemens should work quite reliably for stock PRESS or at least it was tested for numerous datasets.
Also, while using Gannet as a comparison to see whether the data is a good approach it may also use the wrong number of points. The only way to conclusively know the number of points is to look at the sequence settings on the scanner or the exam card.
Again, I would greatly appreciate it if you could share the data so that we could figure this out together.
I am currently running the preprocessing of acquired (.SDAT) MRS data from a Philips scanner, using a unedited PRESS sequence. I would like to use the LC model for fitting.
I am able to run through the GUI in a LINUX computer via Matlab, the preprocessing of one subject (Load, process, model, coRegister, Segment, Quantify). When Quantify finishes, I get the following error:
Unrecognized field name “resBasisSet”.
Error in osp_exportParams/get_header (line 135)
*** fields = fieldnames(MRSCont.fit.resBasisSet)';***
Error in osp_exportParams (line 24) [hdr, label] = get_header(MRSCont);
Error in OspreyOverview (line 840)
*** osp_exportParams(MRSCont)***
Error in osp_onQuant (line 49)
*** MRSCont = OspreyOverview(MRSCont);***
Error while evaluating UIControl Callback.
Could you please help me figure out what this means? In my output folder ‘QuantifyResults’ I get (I think) values per metabolite.
I am not entirely sure if my error is connected to this threat. I also looked into the OspreyFit code and found that the error you mention has been fixed with the current solution explained in your conversation.
I would really appreciate any help you can provide.
the culprit is the following line in your jobfile:
opts.exportParams.flag = 1;
Could you set this parameter to 0?
The export of all parameters derived from the linear-combination algorithm is only implemented for the native Osprey model. For LCModel it is not implemented, because we have no function that finds all model parameters in the .coord/.print output from LCModel. I am unsure if you could find all the model parameters there. Is there any particular reason you need all model parameters?
Thank you very much for your help!
It did solve the problem.
No, I am unsure if I need all of them. I just wanted to have all the parameters since I am new to the topic. Thank you for your observation!!
Could I ask you another question?
What is your opinion about the corregistration step? Is this really absolutely necessary?
Also, if I am doing corregistration, should I correct it again for Creatine? I extracted the values from the metabolites and then divided them by the Creatine value. Is this a correct approach?
This depends on what quantification method you want to report in your paper. You don’t have to run the coregistration and segmentation step if you are only interested in total creatine ratios. If you want to calculate concentrations you have to run both those steps. A good summary of this can be found in chapter 4 of this paper (https://doi.org/10.1002/nbm.4257).
In Osprey you can run:
MRSCont = OspreyQuantify(MRSCont)
Or click on the Quantify button in the GUI.
Depending on your input files and the analysis steps you ran (OspreyCoreg and OspreySeg or not) it will generate creatine ratio, raw water ratio, and concentration estimates. Best to read the section about the quantification module in the Osprey paper to understand all the quantification outputs (https://www.sciencedirect.com/science/article/abs/pii/S0165027020302508). So there is no need to manually divide amplitudes in Osprey.
