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.
