search

mne-tools / mne-python

MNE: Magnetoencephalography (MEG) and Electroencephalography (EEG) in Python
https://mne.tools
BSD 3-Clause "New" or "Revised" License
2.74k stars 1.33k forks source link

support negative times for CTF files #9653

Open bloyl opened 3 years ago

bloyl commented 3 years ago

So I didn't know this but it seems like CTF has the ability to start its recordings with negative times by using a sync trigger and asking the scanner to include a baseline period.

Other packages Brainstorm (and presumably fieldtrip) respect this field and adjust their time arrays accordingly.

MNE reads in the required field https://github.com/mne-tools/mne-python/blob/855edbf48835bcee80e773eb7047d0a4caa14a1c/mne/io/ctf/res4.py#L126

and adjusts annotations and bad_segments to account for it. https://github.com/mne-tools/mne-python/blob/855edbf48835bcee80e773eb7047d0a4caa14a1c/mne/io/ctf/ctf.py#L147-L156

That MNE shifts other stuff and not the time array leads me to believe that MNE can't have negative time values in raw objects. Is that true?

This cropped up because I was doing some custom event marking for an experiment using mne and the resulting events were read into brainstorm and were all shifted by 1 second. In this particular case, I'm time shifting the events before I save them out, solving my immediate issue but it still seems a bit like a bug?

-Luke

agramfort commented 3 years ago

To me it’s related to first_samp attribute from neuromag / FIF files. Are you exploiting this first_samp attribute in CTF reader?

bloyl commented 3 years ago

I've never been very clear on the first_samp attribute, but if I recall correctly it specifies how many samples passed after the neuromag 'start' button was pressed (is this the time in meas_date?) that the actual file recording starts. Its thus always positive.

I don't think it will help in this case because I want raw.times[0] = -1 which I think would need a negative first_samp which would probably cause all types of issues.

My guess is I'll just add a big warning to the reader so users (me?) aren't surprised that the timing is different then in other software packages.

larsoner commented 3 years ago

raw.times always starts at zero even if for example you crop to remove the first second of data as raw.crop(1, None). Thus .times is always relative to whenever the current instance's data begins (and that time is raw.times[0]=0).

I would expect this CTF data to maybe have first_samp=-sfreq, but in any case raw.times is the wrong place to look for any absolute time.