[Synchronization] use approximation when large std

[Edouard2laire]

Hello,

This is a PR to use the approximation when std is detected to be large:

Before:

Lag difference between @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-eeg_run-02_band_notch_resample and @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-physio_run-02_resample : 91683.58 ms **(std: 83872.79 ms)**
Lag difference between @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-eeg_run-02_band_notch_resample and @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-nirs_run-02 : -277246.51 ms (std: 125.73 ms)

The events are no longer synced with the analog trigger

After:

Lag difference between @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-eeg_run-02_band_notch_resample and @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-physio_run-02_resample : 108628.00 ms (std: 0.00 ms)
Lag difference between @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-eeg_run-02_band_notch_resample and @rawsub-PA13_ses-EEGfNIRS02_task-sleep_mod-nirs_run-02 : -277228.00 ms (std: 0.00 ms)

(synchronization are well aligned with the analog trigger)

[rcassani]

I made few aesthetic changes cb58a53

It may be good to have the information about the two approaches in the process GUI.

EDIT: @Edouard2laire, can your draft that legend explaining both approaches, and the use of xcorr for std > 1s? After that it should be ready to be merged

[Edouard2laire]

Thx. i'll try to write that during the week.

Edouard

[Edouard2laire]

hi. Sorry, i forgot to write the description...

I was thinking; since, the correlation is more robust, and overall working all the time; maybe, we should only keep that method. It would make it easier to only explain that method and not have sometimes one method; and sometimes the other.

Also; we can refer to https://www.mathworks.com/help/signal/ref/alignsignals.html which uses the same method of using cross-correlation to align two signals (here the signal we use to align is the event time course created by having a time course that is zeros everywhere; except during the event where it is 1).

if we want some diagnoses; we can check the correlation of the events signal; and yell at the user, if let's say the correlation of the two signals is less than, let's say, 0.7.

[rcassani]

Cross-correlation seems the good approach when aligning signals where at least one of them is "continuous", as in your example. However the process aligns simple events. For this it is preferable to have the same number of events to compute the mean diff. But if different number of a very bad alignment (as with very large std) the xcorr can be used as alternative.

Check this toy example:

x = [0     1     0     0     0     0     1     0     0     0     0     0     1     0     0     0];
y = [1     0     0     0     1     0     0     0     0     1     0     0     0     0     0     0];

Computing the mean lag, and using it:

lag_mean = mean(find(x)-find(y)); % 2
x_fix = [0     1     0     0     0     0     1     0     0     0     0     0     1     0     0     0];
y_fix = [0     0     1     0     0     0     1     0     0     0     0     1     0     0     0     0];

Computing xcorr lag and using it:

[c, lags] = xcorr(x,y);
[~, ic] = max(c);     % 2
lag_xcorr = lags(ic); % -3

x_fix = [0     1     0     0     0     0     1     0     0     0     0     0     1     0     0     0];
y_fix = [0     1     0     0     0     0     1     0     0     0     0     0     0     0     0     0];

[rcassani]

@Edouard2laire, after further thinking on this process to synch. To align signals using markers, the safest way would be to require the user to provide the same number of markers per file instead of assuming the alignment.

The xcorr approach would be nice if aligning with extended events, or aligning using a common analog signal (such as STIM). However, that is out of the scope of the current process_sync_recordings process

[Edouard2laire]

@rcassani Done.

Btw, i looked at the xample i shared in the begening of this thread.

The top shows the histogram of the shift. The bottom shows correlation as a function of the lag. We can see that using the mean suggests a lag of -368 seconds, when correlation is suggestion -385 seconds.

Based on the analog trigger present in the file, I am more willing to trust the correlation here. (note that we randomize the time between trigger during the acquisition so doing correlation between event should be robust)

Note that if we look at the mode of shifting instead of mean then we end up with the same lag as the correlation method

[rcassani]

Note that if we look at the mode of shifting instead of mean then we end up with the same lag as the correlation method

That makes sense, right? xcorr "counts" the number of coincidences in the two event series for all the delays, and the larger number is selected.

[Edouard2laire]

Note that if we look at the mode of shifting instead of mean then we end up with the same lag as the correlation method

That makes sense, right? xcorr "counts" the number of coincidences in the two event series for all the delays, and the larger number is selected.

yes, I think so too.