osl icon indicating copy to clipboard operation
osl copied to clipboard

plotting options with EEG?

Open pwendiggensen opened this issue 1 year ago • 7 comments

I want to run source-reconstruction on the mni template using rhino. Despite use_headshape=False, use_nose=False, I still got a FileNotFoundError on polhemus_headshape.txt. In this regard I think I have found a potential bug in coreg.py as loading the Polhemus files is not contained within if use_headshape: https://github.com/OHBA-analysis/osl-ephys/blob/548b7def8fcbd427f8121bfeb0e15d7fe75376b3/osl_ephys/source_recon/rhino/coreg.py#L198-L219

Indenting the lines seems to work as indicated by Using known MNI fiducials. Nevertheless, I subsequently get stuck at https://github.com/OHBA-analysis/osl-ephys/blob/548b7def8fcbd427f8121bfeb0e15d7fe75376b3/osl_ephys/source_recon/rhino/coreg.py#L250 as [...]/rhino/surfaces/mni_mri-trans.fif does not exist in the subject folder (or anywhere else for that matter). Any advice on how to obtain this or how to circumvent this issue would be very much appreciated.

pwendiggensen avatar Mar 19 '25 10:03 pwendiggensen

I made some progress on this myself today, so I am posting this here in case someone is interested in it: I indented the polhemus_headshape lines (208,209) and left the others untouched. Following the instructions in doc/source/tutorials/source-recon_coreg.py, I saved the MNI default coordinates (see below) as corresponding .txt-files. https://github.com/OHBA-analysis/osl-ephys/blob/548b7def8fcbd427f8121bfeb0e15d7fe75376b3/osl_ephys/source_recon/rhino/coreg.py#L244-L248

For mni_mri-trans.fif, source_recon.rhino.compute_surfaces needs to be run prior to co-registration. This way it is possible to follow the steps of above mentioned tutorial. It is, however, not possible to plot the EEG sensors in neither source_recon.rhino.coreg_display nor source_recon.rhino.bem_display, since they seem to be solely written for MEG. Is there a way to visually check the electrode alignment with the headmodel (and also check that everything else worked as intended)?

pwendiggensen avatar Mar 19 '25 17:03 pwendiggensen

have you tried setting include_eeg_as_headshape=True:

https://github.com/OHBA-analysis/osl-ephys/blob/main/osl_ephys/source_recon/wrappers.py#L60

?

cgohil8 avatar Apr 22 '25 21:04 cgohil8

thank you so much for your response! It seems that I completely missed this despite the function being applied in the reference code. The coregistration ends up looking like this (see below). while the shape generally seems to match up, I think the coregistration could be better (i.e., the electrodes could be closer to the scalp at the sides, while the front should be further out). Im am wondering whether this is due to the positions - would removing some of them produce better matching results?

Image

Image

pwendiggensen avatar May 07 '25 12:05 pwendiggensen

That's due to the EEG electrode positions in the fif file. I added an argument to scale the x, y, z coordinates of the EEG positions. You could try:

config = """
    source_recon:
    - extract_polhemus_from_info:
        include_eeg_as_headshape: True
        rescale: [0.9, 1.1, 1]  # doesn't move sensors in fif
    - compute_surfaces:
        include_nose: False
    - coregister:
        use_nose: False
        use_headshape: True
"""

and play around with rescale. The above will shrink the sides (x-coordinates) and elongate the front (y-coordiantes).

After you find the scaling you want you can move the sensor in the fif using:

https://github.com/OHBA-analysis/osl-ephys/blob/main/osl_ephys/source_recon/wrappers.py#L39

cgohil8 avatar May 07 '25 12:05 cgohil8

Hi Chetan, thank you for the help - this worked nicely. It took me a while to figure out that I needed to change to the development branch (that was before the version bump to v.2.2).

I have, however, run into another problem since. I'll post it here but can make this a seperate issue if preferred. I have been working with data that I had previously preprocessed in BrainVision. Since I want to run HMMs on the data using osl-dynamics, I think it would be better to do the entire preprocessing in osl-ephys. I have used the scripts from Cho et al. (2024) as a reference, but it seems that my pipeline is not excluding any channels. The logging shows the detection of bad channels, however, as far as I can tell, they are neither rejected nor marked in the data (see screenshot below - although I am new to osl/mne and not sure of this is where they would end up?). They also do not show up as removed electrodes in the preprocessing subject report (and the power spectra strongly hint to their presence)

Image This is the config that I used as I don't know whether I am missing something there. In that regard, is there like a list of parameters that can be used in the config during batch processing?

config = """  
     preproc:  
        - filter: {l_freq: 0.5, h_freq: 50, method: iir, iir_params: {order: 5, ftype: butter}}  
        - notch_filter: {freqs: 50 100}  
        - resample: {sfreq: 250}  
        - bad_channels: {picks: eeg}  
        - bad_segments: {segment_len: 500, picks: eeg}  
        - bad_segments: {segment_len: 500, picks: eeg, mode: diff}  
        - interpolate_bads: {}  
        - set_eeg_reference: {projection: true}  
        - ica_raw: {n_components: 50, picks: 'eeg', l_freq: 1}  
"""

pwendiggensen avatar May 15 '25 14:05 pwendiggensen

The logging shows the detection of bad channels, however, as far as I can tell, they are neither rejected nor marked in the data (see screenshot below - although I am new to osl/mne and not sure of this is where they would end up?)

They should appear in the bad_channels attribute of the Raw object.

I have been working with data that I had previously preprocessed in BrainVision

Are you saying you detected/marked bad channels in BrainVision? Are there any bad channels in the <outdir>/<subject>/<subject>_preproc-raw.fif file? You can load the fif file and print raw.bad_channels or look at the preproc report from osl-ephys. If there are bad channels in this fif file everything might fine.

Note, to do the source reconstruction you will need to use average referencing:

https://github.com/OHBA-analysis/OHBA-Examples/blob/main/lemon/1_preprocess.py#L117

cgohil8 avatar May 16 '25 11:05 cgohil8

The reason the bad channels don't appear in the data or report are because you've interpolated the bad channels. By default, this resets the annotation (which is also used by the report). In order to retain this information, use - interpolate_bads: {reset_bads: False}. We will probably make this a default in a future release.

matsvanes avatar May 16 '25 13:05 matsvanes