Help improving fitting for FSL-MRS

FSLMRS Error Documentation.docx (814.2 KB)
I am working with MRS data for my PhD and have difficulty getting the fitting right.

Another student and I have tried every solution that we have been able to find online. We’ve detailed our process in the attached document, and I can provide the data and/or basis set we are using to generate this result if necessary. Any help in this matter would be appreciated.

Kind regards,

1 Like

Hi @ThomasCawood,

I am not particularly familiar with FSL-MRS or the basis set from Christoph’s group so I can’t comment on that. But the TE setting and seems to be fairly common and the data quality is also ok.

Have you ever tried fitting the spectrum with Tarquin (Analysis & Quantification Software - MRSHub), LCModel (Analysis & Quantification Software - MRSHub), or Osprey (Analysis & Quantification Software - MRSHub). Or have you tried another basis set, e.g., generated with FID-A (Data Simulation & Basis Set Generation - MRSHub), MRS-Cloud ( or exported from Osprey?


Hi @ThomasCawood,

@Helge’s suggestions are all good… however, specific to the FSL-MRS case: just glancing through your document, I think the problem lies in your original basis set conversion. You should be seeing an NAA peak around 2 ppm, and a Cr peak around 3 ppm – but your figures (reproduced here) show NAA around 3.4 and Cr around 3.8. To me this indicates an incorrectly specified dwell time somewhere in the process.


See also the comment thread here

When running basis_tools convert, the --bandwidth parameter should describe the bandwidth of the input basis set (it’s not contained in the lcmodel RAW file headers), not your target data. So, try this:

basis_tools convert RawBasis_for_PRESSSiemens_TE_35_BW_2500_NPts_1024 --bandwidth 2500 --fieldstrength 3.0 basis_converted

A secondary issue, your reduced basis set is missing NAA. This isn’t your main problem right now, but it should be fixed before you go too much further.


You also mention in the document,

MRI scanner data processed using (done in a shell script):
• Conversion of dicoms to nifti [spec2nii dicom -f converted_${b} *.dcm]

If you’re starting with DICOM files, a number of the other preprocessing steps may be redundant… this would explain some of the other preprocessing issues you mention therein. You’ll have a lot more flexibility if you work with TWIX (.dat) files instead. Again, it’s not your main issue at the moment but it could be something to look into…


@Helge We have been able to fit the spectrum using LCModel, and the results looked much nicer. We were planning on using it anyway to validate our results from FSL-MRS. We haven’t tried using any other basis sets, so thank you for those links; we will try them and let you know if we succeed.

@alex Thank you for your help. After converting the basis set with the provided command and running the fsl_mrs command we get the following error messages:

fsl_mrs.utils.misc.InsufficentTimeCoverageError: Input data covers less time than is requested by interpolation. Change interpolation points or dwell time.

fsl_mrs.core.basis.BasisHasInsufficentCoverage: The basis spectra covers too little time. Please reduce the dwelltime, number of points or pad this basis.

Could there be an issue with the data itself? Comparing the info for the data and basis we get:

NIfTI-MRS version 0.5
Data shape (1, 1, 1, 1023)
Dimension tags: [None, None, None]
Spectrometer Frequency: 123.261637 MHz
Dwelltime (Bandwidth): 8.334E-04s (1200 Hz)
Nucleus: 1H
Field Strength: 2.90 T

------- Basis Object ---------
BASIS.NMetabs = 34
BASIS.timepoints = 1024
BASIS.centralFreq (MHz) = 127.728
BASIS.bandwidth (Hz) = 2500.0
BASIS.dwelltime (s) = 4.00000e-04

Metabolites: [‘2HG’, ‘Ace’, ‘Ala’, ‘Asc’, ‘Asp’, ‘BHB’, ‘Cho’, ‘Cr’, ‘Cr391’, ‘CrNo391’, ‘Cys’, ‘Eth’, ‘GABA’, ‘GPC’, ‘GSH’, ‘Glc’, ‘Gln’, ‘Glu’, ‘Gly’, ‘Homocarnosine’, ‘Lac’, ‘NAA’, ‘NAAG’, ‘PA’, ‘PCho’, ‘PCr’, ‘PE’, ‘Tau’, ‘Thr’, ‘Try’, ‘Tyr’, ‘Val’, ‘mI’, ‘sI’]

The bandwidth * dwelltime is 1.00008 and 1, respectively. Could this incongruency lead to the errors we see?

Kind regards,
Thomas Cawood

Hi @ThomasCawood, thanks for giving FSL-MRS a go, and thanks for jumping in to help @Helge and @alex.

Getting your basis set right is definitely the hardest part. The errors reported arise from the fact that you need a basis set that has at least the time coverage of the data FID to fit that data. The basis object has a total time coverage of 1024 points * 4e-4 s which is less than the data: 1023 points * 8e-4 s.

So you could try finding another basis set or generating one as Helge suggests. MRS-Cloud is a very nice resource for this. Or you can try padding the basis sets to have more time points (just add zeros tot he end of each FID). This is a bit of a fudge (I think it’s what LCModel does under the hood), but should work sufficiently well.

Thank you all so much for your help.

Padding the basis was unsuccessful. We tried changing the basis to a range of time points from 1022 -1025 and still got the same error each time.

However, simulating a basis set with MRS-Cloud and converting it to an LCModel set with osprey before converting it again to an FSL-MRS basis set was successful, and it is, without a doubt, the finest one we’ve had so far.

Now it is just a question of refinement. Do you have any advice on how to improve the fit further? The attached images show the fit without any processing or MMs.

Kind regards,
Thomas Cawood.

Hi @ThomasCawood,

At first glance your basis set looks much better now, but you will need to incorporate MM/Lipid components too – you data has some quite noticable components (eg to the right of NAA) which aren’t accounted for by your current basis set, and can’t be easily accomodated by FSLMRS’s polynomial baseline model (you might get away with this in another algorithm with a more flexible baseline model, but that comes with its own risks).

The data isn’t remarkably good – I assume this is healthy tissue? What region are you acquiring from? You say “without any processing” – ECC (if you have a water reference available) and phasing might clean things up a bit. You could also try truncating the first few points (-leftshift in fsl_mrs_proc) to remove some of the broad undulations – although it would be preferable to deal with these in the model.


Completely agree with @alex 's suggestions. It looks like there is some first-order phase in your data (equivalent to a time shift in the time domain). I think I’d try to tackle that first.