Alignment of MEGA-sLASER spectra

[hmonsivais]

Hi @Helge,

I have a set of GABA-edited data from the MEGA-sLASER sequence that I am trying to pre-process using Osprey. However, the alignment is way off (see images below). Any ideas as to why this is happening? From what I understand, for GABA-edited MEGA data, Osprey uses the residual water signal for alignment. Is there a way that I can specify a different peak for the alignment of these data (3.0 ppm, for example)?

We’d be happy to share our data with you if needed.

Thank you and I appreciate any answer you could provide.

Humberto

[Helge]

Hi @hmonsivais,

Thanks for reporting this issue. Osprey is performing the alignment in the time-domain by optimizing the individual frequency and phase shifts of the transients compared to the transient with the highest similarity (Robust Correction of Frequency and Phase Errors in Edited MRS Data, Mikkelsen et al. 2018, ISMRM Proceedings).
The initial guess of this fit is based on the cross-correlation of groups of 10% of the transients with two delta functions at 3.01 and 3.22 ppm.

Could you share your data, so that we could find out where the processing goes wrong.

Best,
Helge

PS.: Did you manage to integrate your LCModel basis set into Osprey (from your other thread)?

[hmonsivais]

Hi Helge,

Thanks so much for your reply. I will share our data via email.

As for the LCModel basis set, I just updated my folders to most recent update in the develop branch. I was able to import the basis file into the Osprey format using the io_LCMBasis function. I used this new file for the fitting and it worked! I just had to add an if statement for the Siemens case in osp_fitInitialise, so that it would load the correct basis set.

I will have to look into the results more closely, but this is a great start.

I did get an error towards the end when calculating the correlations between metabolites and SNR/LW in the overview tab:

Unrecognized function or variable ‘lgamma’.
Error in betapdf (line 60)
+ lgamma (a + b) - lgamma (a) - lgamma (b));
Error in betainv (line 87)
h = (betacdf (y_old, a, b) - x) ./ betapdf (y_old, a, b);

Error in finv (line 58)
inv(k) = ((1 ./ betainv (1 - x(k), n/2, m/2) - 1) * n / m);
Error in regression_line_ci (line 59)
Yoff = (2*finv(1-alpha,2,N-2)*SE_Y).^0.5;

Error in osp_plotScatter (line 152)
[~, ~,~] = regression_line_ci(0.05,b,x_tmp,y_tmp,cb(g,:));

Error in osp_iniOverviewWindow (line 293)
[temp] = osp_plotScatter(MRSCont, gui.quant.Names.Model{gui.quant.Selected.Model},
gui.quant.Names.Quants{gui.quant.Selected.Quant},MRSCont.quantify.metabs{gui.overview.Selected.Metab},MRSCont.QM.SNR.A’,gui.overview.Names.QM{gui.overview.Selected.Corr});

Error in OspreyGUI (line 408)
osp_iniOverviewWindow(gui);

Any ideas as to why this happened? I don’t remember running into this issue before.

Thanks again!

Best,
Humberto

[hmonsivais]

I actually made a mistake when loading the new basis file and it fitted using the press30 basis file… sorry about that. Now when I try to fit using the new basis file I get many errors:

Error using lbfgsb (line 92)
x0 and l have mismatchig sizes

Error in fit_Osprey_PrelimReduced>fit_Osprey_PrelimReduced_Model (line 269)
[ampl, ~, ~] = lbfgsb(fun, l, u, opts );

Error in fit_Osprey_PrelimReduced>@(x)fit_Osprey_PrelimReduced_Model(x,inputData,inputSettings) (line 127)
= LevenbergMarquardt(@(x) fit_Osprey_PrelimReduced_Model(x, inputData, inputSettings),x0,lb,ub,opts);

-Humberto

[Helge]

Hi Humberto,

The error in the scatter plot is a known issue which is haunting me for a long time :). The problem is that SPM12 fieldtrip toolbox includes functions with the same names as MATLAB internal functions. For that reason, I was moving SPM12 in and out of the path during the use of Osprey. I have now added a fix, which is just removing the filedtrip folder at Osprey startup. This seems to work in our testing framework.

During my last update I accidentally uploaded my SPMpath.mat variable on GitHub and removed it later. I suspect that you have downloaded the repository when it was still online. I have added a fix to avoid this bug in the future.

Let me know if this fix works for you.

I’ll reply to your basis set import issues in the other thread.

-Helge

[hmonsivais]

Hi Helge,

I updated the repository and now I am getting an error Undefined function or variable 'spm'. on the segmentation module. For some reason the spm path is removed either after coregistration or when I try to do the segmentation.

-Humberto

[Helge]

Hi Humberto,

This must have slipped our testing. I’ve tested the GUI and command lines on my machine and it should be fine now.

Helge

[hmonsivais]

Awesome, thanks again!

-Humberto

[hmonsivais]

Hi Helge,

Just wanted to check if you’ve had a chance to look at our data and where does the processing goes wrong?

Best,
-Humberto

[Helge]

Hi Humberto,

I have had a look at your data and was able to identify the problem, which is the residual water signal. There are several ways to fix this:

1. I assume you did not use the ‘Weak Water Suppression’ Option during the acquisition on the scanner, which leads to this ‘ugly’ residual water. If these are just pilot data set I’d always use the weak water suppression for edited MRS on the Siemens scanner, because in this case you won’t have problems with the spectral registration.

2. I’ve a quick fix implemented into Osprey. You can turn spectral registration off for now by adding a 1 as the last argument into the function call [raw, fs, phs, weights, driftPre, driftPost] = op_robustSpecReg(raw, 'unedited', 0,refShift_ind_ini); % Align and average like [raw, fs, phs, weights, driftPre, driftPost] = op_robustSpecReg(raw, 'unedited', 0,refShift_ind_ini,1); % Align and average. This will at least not mis-align your data.

3. I could integrate a frequency restricted spectral feature into Osprey. If we agree on that I would appreciate to be considered in a potential manuscript, as this project would go beyond normal bug fixing.

4. You could implement the function yourself and commit your new feature to GitHub

I will also keep you posted on the import of your basis set next week.

Helge

[hmonsivais]

Hi Helge,

Thanks a lot for looking into this! We truly appreciate your time.

1. We actually are using neither “weak” nor “normal” (Siemens) water suppression, but VAPOR which (as expected) does a really good job in water suppression. Turning on weak water suppression when acquiring edited MRS should be an easy fix - we will definitely look into it!

2. I will look into this and see what results we get. Thanks for adding this!

3. This sounds like a great idea, although we don’t really have any manuscript in mind at the moment. These data come from a big collaboration and the study is still ongoing (currently halted due to COVID-19). My advisor would need to talk to the rest of the collaboration, but we don’t think that should be a problem.

4. While I would love to implement this function myself, I fear it is just out of my current skill set (first year master’s student ).If it is of enough interest to you, I would be happy to provide different test data for implementing this and possibly give a manuscript of its own? Not sure if this is doable (I’m still fairly new to all of this ).

Looking forward to the import of basis set.

Best,
-Humberto

[Helge]

Hi Humberto,

I have finally found the time to look into some of your stuff again.

3. Great! This whole halted in vivo research situation is kind of annoying, but we will hopefully get past this at some point :).

4. I’ll try to implement this stuff, if I find some spare time, as this may be helpful for some other datasets as well. As this is just a re-implementation of an already published method I do not see this as an potential manuscript itself.

The main reason for this post is that I’ve managed to import your .BASIS file into Osprey and got a very nice fit result (the measured MM baseline is ignored for now). If you want to test this out for yourself you’ll have to type [BASIS] = io_LCMBasis('/Users/helge/Downloads/sead3T_30ms_03Nov2016.BASIS', 1, 'unedited', 'none') into the console with the path to your .BASIS file. Then you’ll have to follow the instructions in the console. Afterwards you should be able to fit your sLASER data. At least it worked for the test data you send me.

Let me know whether this worked for you.

Helge

[hmonsivais]

Hi Helge,

Thanks so much for the update! I will give it a try and let you know if I get it to work for me. This may be a silly question, but will I be able to run the quantification as well?

Best,
-Humberto

[Helge]

Hi Humberto,

You’ll be able to run the quantification as well. Cr ratios are always available after fitting successfully and absolute quantification with different corrections depend on a water reference and structural images.

Best,
Helge

[hmonsivais]

Hi Helge,

I was able to upload a couple basis sets with the io_LCMBasis function and got very nice fits! However, I wasn’t able to get absolute quantification even though I provided water reference files. I noticed that the preloaded basis sets have water data (column named H20), but the ones I uploaded do not. Is this why I am not getting absolute quantification?

-Humberto

[Helge]

Hi Humberto,

Your idea about H2O being the problem is right. So far I did include a H2O reference, which was loaded from one of Osprey’s basis sets, apparently this did not work for the water fit. It slipped my testing as I did tCr quantification only. The updated Osprey will now add a Lorentzian water peak to the basis set automatically, if no H2O is in the basis set by default. You will have to rerun io_LCMBasis and then your absolute quantification should be working.

-Helge

[hmonsivais]

Thanks, Helge! Just gave it a try and I am
now getting absolute quantification results.

[Yushan]

Hi Humberto,

Sorry to disturb you, given that this is a post from nearly 3 years ago. I am currently encountering a similar issue and came across this post. May I ask how you eventually resolved the issue of spectral alignment?

Best wishes,
Yushan

[Yushan]

My data is from GABA-edited MEGA-sLASER sequences, and I employed three different spectral registration methods: RobSpecReg, ProbSpecReg, and RestrSpecReg, with the following results，
1.RobSpecReg

2.ProbSpecReg

3.RestrSpecReg,with the fit range [0.5 4]

It appears that ProbSpecReg performs better than the other two methods, although it is not optimal. Additionally, I noticed that my Cr peak is at 2.98 ppm rather than 3.02 ppm, and it shows a decreasing trend as the average increases.

[hmonsivais]

Hello Yushan,

It’s been a while since I worked with MEGA-sLASER data, but I remember that my solution was to not perform any kind of spectral registration, or restrict it to a very narrow frequency range (either the NAA peak or the Cr peak depending on where you see the least amount of frequency drift).

I hope this helps!

Humberto