events.json
<- original conversation disappeared (??)
bids-standard/bids-specification@abe6036
bids-standard/bids-specification#1781
forward so HTML blocks can be replaced when that PR is merged.SampleCoordinatesUnits
onset
column of physioevents
should allow definition of units other than the default (s)SampleCoordinateSystem
an enum?CalibrationPosition
assumption
CalibrationUnits
& CalibrationPosition
definition: looks like having the columns require units this metadata should not be present anymore.Validator and Examples PR must be solved.
Open a new PR. Close old one and open a fresh PR for community review. Potentially use https://github.com/flows-network/github-pr-summary
Email to BIDS mailing list with request to review PR. Join mailing list. This is an example email from the BIDS email list:
Subject: [BEP042] EMG-BIDS Call for Comments, Please review by April, 30th 2025
Dear BIDS Community,
The EMG-BIDS Extension Proposal (BEP042) provides a standardized framework for organizing and describing electromyography (EMG) data, including high-density EMG recordings, within the BIDS format. This BEP addresses the need for consistent representation of EMG data to enhance reproducibility and data sharing.
Key features of the proposal include:
Standardized directory structure for EMG data organization
Comprehensive metadata schema for EMG acquisition parameters
Support for both conventional and high-density EMG recordings
Specifications for sensor/electrode positions and channel information
Integration with existing BIDS modalities and annotations
The full proposal is available for review at:
Pull Request: https://github.com/bids-standard/bids-specification/pull/1998
HTML Preview: https://bids-specification--1998.org.readthedocs.build/en/1998/modality-specific-files/electromyography.html
Example Implementation: https://github.com/bids-standard/bids-examples/pull/480 (The examples are work in progress and may not be updated to the latest changes in the specifications)
We welcome feedback from the community in any of the following ways:
Comment directly on the GitHub pull request (or the corresponding issue)
Email the moderators (shi...@ieee.org)
Respond to this thread
Your input is crucial in ensuring that this specification meets the needs of researchers working with EMG data across various disciplines.
MS made a mistake on the github header and put that the meeting was on the 14th while it was actually on thursday 13 as we agreed, only Martin and Julia was present.
TODO
MS should change the html render to point towards the latest openneuro dataaset (https://openneuro.org/datasets/ds004158/versions/2.0.5)
MS should put the BIDS example in html file when it get pushed
JP will write to OE to see what's going on with the validator (file naming issue)
Other points
Do we have a new dataset example with EEG, if yes we need a link to it and a brief explanation alike the one used here.
Scott is dealing with it.
Should we put the link the the empty datasets or the real one, or both ?
We will use both, but we need to merge the example first to have the link.
Example datasets PR: bids-standard/bids-examples#478.
Some resolved issues:
EnvironmentCoordinates
-> StimulusPresentation.ScreenOrigin
events.json
files iff there are physio.json
files defining PhysioType
=eyetrack
Home stretch TODO–moved to the top (OE)
Converter:
Next meeting will be discussed on Element.
EnvironmentCoordinates
> make part of events.json
?
discuss comment on defining a unit for timestamp
did we already decide that the "EyetrackingGeometry" as proposed by Sourav will be implemented? (it's already in the paper, I thought we wanted to first ask in the BIDS-PR; need to know for the converter)
EyeTrackerDistance
(and possibly rename) to also allow a list of three valuesExample of dependency between metadata
https://github.com/bids-standard/bids-specification/blob/7c93b9c67188f5c5d496a250a8cbaf37f475ebf6/src/schema/rules/checks/func.yaml#L82
did anyone look at the example dataset? If it's fine like this I can go on and take care of the bigger dataset on OpenNeuro
if anyone has more testfiles to share (eyelink edfs), please put them on OSF (eyelink folder -> make new folder -> put edf file)
started to write some doc for the converter: https://eye2bids.readthedocs.io/en/latest/
beh/
.bidsignore
) and see how it breaks.Julia would like to discuss:
3D eye-trackers
The PR including both old eyetrack
suffix and new PhysioType
is now available.
Oscar is holding off some changes, until after the "old" eyetrack can be removed if everyone signs off.
This is the TODO list:
Discussion of OE's pull request to introduce PhysioType and physioevents.tsv
ACTIONS:
UPDATE 2024/02/29: OE submitted a PR jotting down these ideas https://github.com/mszinte/bids-specification/pull/8/files
OE sent an email proposing a simple idea that could (i) allow this BEP set limitations such as separating eyes and, at the same time, (ii) keep legacy datasets compatible and passing new versions of the validator.
Proposal: the definition of a new OPTIONAL metadata field for _physio.json
files called "RecordingType"
.
Implementation:
"RecordingType"
would be "custom"
(or "unspecified"
or "n/a"
, whichever majority likes the most). If not explicitly defined in the metadata, "RecordingType"
is "custom"
(this is important for tools like pybids as querying for "custom"
or None
/null should return the same)."eyetrack"
as a new "RecordingType"
. Future BEPs may introduce other values (e.g., "ecg"
), but that would be defined as out of the scope for us.Advantages: Now, by having a "_physio.json"
file with { "RecordingType": "eyetrack" }
, all the aspects we have been discussing become active:
_physio.tsv.gz
files (see the notes of the previous meeting)._physio.tsv.gz
file corresponding to the _physio.json
file can hold data for one and only one eye/merged signal._physio
files, by enabling a new special value in "SamplingFrequency"
ONLY for specific RecordingType
s such as "eyetrack"
(i.e., this way we can keep the old tsv.gz
files untouched).Context: This idea, in addition to adding the new _physioevents.[tsv.gz|json]
files we set out to draft would put together a very solid framework that:
In addition to some general comments to the proposal above, RG also noted:
probably worth checking existing BIDS datasets with alledgedly valid eyetracking/physio data to see if they do not already suffer from this "non continuous sampling", which very well may be the case if they used the approach of record ON / record OFF approach that we mentioned last meeting.
Remi also shared two related efforts:
OE has posted this document and the BEP in the Physiopy slack channel.
_eyetrack
) or keep the old (recording-eyetrack_physio
)Pro:
Quickly tells you there's ET data in the dataset
Lifts the limitations to add entities: without new suffix, separating recordings by eye (e.g., eye-1_eyetrack
) is perhaps less straightforward to implement in the specs.
Cons:
_physio
data? Deprecation?
_eyetrack
worked-around to lower the requirements to get a dataset get the BIDS-valid seal of approval.Separating metadata for each eye:
eye-1_eyetrack.ext
, orrecording-eye1_physio.ext
Mandatory or Recommended?
_physio.tsv.gz
files MUST be regularly sampled in BIDS, that is, eye tracking and all other physio recordings struggle with this. This brings two problems:
n/a
(a lot of rows filled with them in every column)A new suffix (_eyetrack
) could drop the requirement of regurlarly sampled data / but it doesn't resolve the issue of spawning huge numbers of columns (i.e., having "triggers"/messages and saccade model on a separate file).
A separate file _physioevents.tsv.gz
(or _eyetrackevents
?) would be a neat solution to this problem, while being representative of what people are doing today (keeping the eyetracking primary information separate from other metadata such as messages).
_physio
away from enforcing regular sampling seems a bit of a heavy lift from this BEP (as it affects BIDS more widely), proposing _physioevents
could actually be relatively straightforward with zero backward compatibility issues.recording-eye1_physioevents.tsv.gz
annotating a single recording-eye1_physio.tsv.gz
file (e.g., with EyeLinks you get two of these files, one would be "events" with the saccade/blink model and "messages" with calibration, validation, triggers, etc.).n/a
for "events").reply to https://github.com/bids-standard/bids-specification/pull/1128#issuecomment-1851492412