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
Add option to import BrainVision files without marker types #12608
Comments
It could make sense to support a list of strings here too, wdyt? |
You mean to ignore only specific types, e.g. |
Seems to me like there's clear motivation for "ignore marker types when they're all identical" and uncertain motivation for "let me specify which one(s) to ignore". I'd suggest to assume YAGNI on the second one, and we can overload the param later (to accept list-likes) if folks ask for it. I'd also consider something like an "always/auto/never" pattern, where "auto" means "ignore them IFF they're all identical". But a simple boolean seems adequate for now --- again, we can update the param later to give more flexibility if folks ask for it. |
sounds good to me, and agreed with YAGNI for the second suggestion. |
agreed 👍 |
BrainVision markers (stored in
.vmrk
files) consist of the following fields (the last field is optional):For example:
This is a marker as exported via
raw.export()
usingpybv
from an annotation with the descriptionbad_segment
. Since theType
field must be present,pybv
usesComment
by default.However, when importing the exported BrainVision file, annotations are created from markers, and the description will be pieced together as
<Type>/<Description>
, i.e.Comment/bad_segment
in this case.This makes the round-trip inconsistent, because I'd like to recover the original annotation descriptions from markers. This simply means that I'd need an option for
read_raw_brainvision()
to ignore theType
fields when constructing annotations. This would require a new parameter, e.g.ignore_marker_types=False
(or something along these lines).Would that be an addition that everyone is OK with (pinging @sappelhoff explicitly as one of the
pybv
maintainers)?The text was updated successfully, but these errors were encountered: