Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support arbitrary markers #118

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Support arbitrary markers #118

wants to merge 3 commits into from

Conversation

cbrnr
Copy link
Collaborator

@cbrnr cbrnr commented Feb 19, 2024

Fixes #103. This is a big (breaking) change, I decided to tackle this as follows:

  • If the passed events is an np.ndarray, the previous conversion magic is still happening (i.e. type is set to "Stimulus" and integers are converted to "S 1" etc.).
  • If the passed events is a list of dicts, markers are written as is.

This means that if someone needs to write "old-style" markers with custom types (such as "Response", "Comment", etc.), they must manually create a corresponding list of dicts.

I'm not sure if we need to change anything in MNE-Python, but I don't think so. It reads descriptions and types and combines them to "Type/Description", which I think should continue to work. The events from annotations heuristics will only work for "old-style" annotations, but that's OK I think.

Copy link

codecov bot commented Feb 19, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e1a6c79) 100.00% compared to head (bd0bb13) 100.00%.
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #118   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines          634       625    -9     
=========================================
- Hits           634       625    -9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@sappelhoff
Copy link
Member

Thanks Clemens, I will have time to review this later this week!

@cbrnr
Copy link
Collaborator Author

cbrnr commented Feb 19, 2024

Here's something to consider: pybv can already export arbitrary markers as type Comment, so maybe there is no need for such a big change? Coming from MNE, the private _export_mne_raw() function already does the job (it sets the type of all markers to Comment).

"Comment"}`` (defaults to ``"Stimulus"``). Additional types like the
known BrainVision types ``"New Segment"``, ``"SyncStatus"``, etc. are
currently not supported.
The type of the event (defaults to ``"Stimulus"``).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stimulus, Response, and Comment are "standard" BrainVision types. I would not cut them out of the description here but rather relax the language from MUST to MAY or similar.

The description of the event. Must be a non-negative int when `type`
(see below) is either ``"Stimulus"`` or ``"Response"``, and may be a str
when `type` is ``"Comment"``.
- ``"description"`` : str
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may also be int, IMHO

else:
# if cannot convert to int, we must use this as "Comment"
etype = "Comment"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think removing this would result in some lines that are not pretty, like:

Mk2=Comment,Stimulus/S253,487,0,0

when it could also (more sensibly, as currently done) be:

Mk2=Stimulus,S253,487,0,0

When passing a list of dict to `events`, the event ``type`` that can be passed is
currently limited to one of ``{"Stimulus", "Response", "Comment"}``. The BrainVision
specification itself does not limit event types, and future extensions of ``pybv``
may permit additional or even arbitrary event types.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine to remove this, but I would somewhere keep a documentation that "Stimulus", "Response", and "Comment" are the classic types in a BrainVision file that is written by BrainVision Recorder.

@sappelhoff
Copy link
Member

Coming from MNE, the private _export_mne_raw() function already does the job (it sets the type of all markers to Comment).

I assume you are referring to this?

pybv/pybv/_export.py

Lines 126 to 130 in 79dceaa

if etype in ["Stimulus", "Response"] and description.strip().isdigit():
description = int(description.strip())
else:
# if cannot convert to int, we must use this as "Comment"
etype = "Comment"

Here's something to consider: pybv can already export arbitrary markers as type Comment, so maybe there is no need for such a big change?

I personally am able to write all data that I want to write. I thought your argument in #103 convincing so I am fine if you really need this change. But if the changes here are not a big advantage for you, then we should just leave it as is IMHO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support strings for marker descriptions
2 participants