Try   HackMD

BEP020 Meetings and discussion notes

Home stretch TODO

Opening PR for review

  1. Validator and Examples PR must be solved.

  2. 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

  3. 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.

Meeting tba

Julia:

  • updates converter done:
    • delete SampleCoordinateUnits from eyelink_metadata.yml
    • insert Units for x-/y-coordinate in eyelink_metadata.yml as required metadata; user needs to enter them manually because I can only read it from eyelink-asc if there was a validation and not everyone does validation
    • delete function to read calibration positions from asc, since these are not the actual calibration positions and user should enter them manually
    • insert CalibrationPosition in eyelink_metadata.yml as recommended metadata for the user to enter manually
    • check confirmed: all messages including extra calibrations are saved in physioevents.tsv
    • update metadata descriptions in physio.json
    • update README, because it is mandatory to pass a metadata.yml file
  • updates example datasets done
  • there are some character issues in the physioevents.json example on the spec-website
  • we discussed previously that EnvironmentCoordinates should be moved from physio.json to the events.json but on the rendered spec it is still in the example for physio.json

Meeting 2025/05/01

  • CalibrationPosition issue
  • can someone explain to me what I need to do regarding SampleCoordinateSystem for the converter? How it is right now:
    • SampleCoordinateSystem is in the metadata yaml file as required metadata to fill manually by the user
    • "Units" for x/y coordinates is not yet integrated as being updated but will always be "a.u" after conversion run

Meeting 2025/04/03

  • CalibrationPosition issue –> Julia and Oscar will meet next week
  • SampleCoordinateSystem issue:
    • will it still exist as required or recommended metadata?
    • "x/y-coordinate needs to have an entry for „Units“ (=required)" means the SampleCoordinateUnits, right? –> right, only for x/y coordinate not for pupil size
  • Email for inviting the community to the manuscript: BIDS maintainers are ok with it
  • Chris suggested to open a fresh PR before opening PR to community review because there are a lot of discussion in the current PR already –> Julia will ask Chris what exactly he meant by that and if we should just open a new one or what
  • verify examples PR (using the new schema) and Schema pr if needed; these should be passing the validator
  • MS/JP/SH discussed about CalibrationPosition issue, we postoned to next meeting that we try to arrange for Thursday 11th April

Meeting 2025/03/13

  • MS/OE/JP discussed the possibility to send soon an email to the BIDS community to invite them to read our paper about the BEP and get ready to discuss its aspect when the Push Request will become public
  • JP mention a list (see above) of things missing in the converter and with the example dataset that are missing.
  • OE presented the latest change he made to allow the requiredness of visual screen settings when eye tracking data is available as as well as change in the template of the html rendered file.
  • MS mention the fact that he would like to make the change done before going to Vision Science Society in order to establish discussion with vendors and with future users.
  • Next meeting is planned to 2025/04/03

Meeting 2025/02/13

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)

  • JP still needs to take care of this for Converter:
    • everything is merged and up-to-date, except this
    • SampleCoordinateSystem will be deleted as required metadata. For this, the description of x/y-coordinate needs to have an entry for „Units“ (=required) –> delete SampleCoordinateSystem from metadata in converter as well as in example datasets and make units required in physio.json
    • calibration positions: you cannot have more than one array; if there are more than 1 calibration split this asc in different runs for separate physio.tsv
    • calibration positions: always the same for the kind of calibration, like if CalibrationType = HV9 then the calibration positions will be always the same for HV9 calibrations

Other points

  • We have no news of the EEG example (?)
  • We are waiting for the latest change of OE on the bids empty example to included it in the rendered document and to propose the BEP to review to the community.
  • We didn't make a new appointment but as a function of the reply of OE, we will send a round email.

Meeting 2025/01/23

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.

    • Q: It feels this should be accompanied by a PR to BIDS-Validator because all tests are (understandably) failing. @YhHdXTcuRDac-GPev3pRkQ (<- this is a mention to Remi) Responded
    • natImSac example has some JSON files with formatting issues
    • –> Julia took care of errors in example datasets in their original repos

  • Some resolved issues:

  • Home stretch TODO–moved to the top (OE)

  • Converter:

    • everything is merged and up-to-date, except this
    • SampleCoordinateSystem will be deleted as required metadata. For this, the description of x/y-coordinate needs to have an entry for „Units“ (=required) –> delete SampleCoordinateSystem from metadata in converter as well as in example datasets and make units required in physio.json
    • calibration positions: you cannot have more than one array; if there are more than 1 calibration split this asc in different runs for separate physio.tsv
    • calibration positions: always the same for the kind of calibration, like if CalibrationType = HV9 then the calibration positions will be always the same for HV9 calibrations

Meeting 2024/12/19

Next meeting will be discussed on Element.

Meeting 2024/10/31

  • Follow up on EyeGeometry
    • Add description in the manuscript
    • Review and accept change in Github
  • Full example dataset (with data)
    • Change in specification "Example datasets" to refer to the good ones
    • Include EyeGeometry
  • Empty example dataset (without data)
    • publish the empty dataset
  • BIDS validator

Meeting 2024/10/03

Meeting 2024/09/04

  • discuss comment on defining a unit for timestamp

    • OE will take care of this :+1: (clarify examples and respond to comment on GH)

  • 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)

Example 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/

Meeting 2024/08/01

  • Discuss about "EyetrackingGeometry" information with Sourav K.
  • Discuss about the manuscript

Meeting 2024/07/04

  • under which data_type does eyetracking data go if it is ONLY eyetracking without any other modality like MRI. Does it go then under beh or func? In one of the last meetings it was said it always goes under func ->
    • Answer: seems we miscommunicated and there seems to be full agreement on having this under beh/
  • Example datasets:
    • one is finished on openneuro: doi:10.18112/openneuro.ds004158.v2.0.2
      • eyetrack bit?
      • perhaps better: run the validator (without adding to .bidsignore) and see how it breaks.
    • another one is on GitHub: https://github.com/julia-pfarr/natImSac_BIDSexample –> need to include events.tsv/.json for trial informations besides the physioevents.tsv/.json?
      • yes, tasks require events.tsv files.
    • do we need a third example dataset for the github bids-examples?
  • open pull requests on converter:
    • please merge
    • metadata.yml
  • when can the spec be merged?

Paper draft

Meeting 2024/04/18

  • Julia would like to discuss:

    • How proceed with other eyetrackers?
    • Is there a recommendation on how to save video files in the dataset? (question form a colleague who does free-moving eyetracking plus video recordings) –> maybe there will be a separate spec for this in the future; right now there is nothing on it
    • What about this comment https://github.com/bids-standard/bids-specification/issues/1788? I need to know for the converter. –> leave compression
    • ezBIDS

  • 3D eye-trackers

    • Update admonition so that those metadata are mandatory only with gaze-on-screen ETs.

Meeting 2024/03/31

  • work to do:
    • update converter to split by eye, handle eye 3, physioevents.tsv
  • scope:
    • vergence not "explicitly" covered
  • revise spec: currently entries for the "eye3" stuff is not clear -> there are two different paragraphs on it:
    • "it is REQUIRED that recordings corresponding to each eye (and merged signals for binocular eye-trackers providing a third recording) are split into files with different recording-<label>. Therefore, the recording-<label> is REQUIRED with eye-tracking data."
    • "The labels "eye1", "eye2", and "eye3" for the recording-<label> entity are RECOMMENDED"
      -> Julia was confused; maybe change it to "the use of labels…recommended"

Update OE - 2024/03/01

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:

Meeting 2024/02/29

Discussion of OE's pull request to introduce PhysioType and physioevents.tsv

ACTIONS:

  • Oscar to finish his PR with the "old" eyetracking and the "new" physio-eyetrack
  • Let github CI build the pages
  • Everyone to compare the "new" and "old" to make sure nothing was lost on the way
  • Remove the "old" eyetrack
  • Remi opens an issue to motivate and discuss the introduction of physioevents

E-mail 2024/02/27

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:

  • The default value of "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).
  • This BEP would introduce "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:

  • Eye tracking and corresponding measurements (e.g., pupil size/area) MUST be stored in separate _physio.tsv.gz files (see the notes of the previous meeting).
    In other words, the _physio.tsv.gz file corresponding to the _physio.json file can hold data for one and only one eye/merged signal.
  • The metadata fields defined in this BEP and their OPTIONAL/RECOMMENDED or MANDATORY statuses are enforced. This is critical because of what Taylor mentions here – we cannot change the RECOMMENDED/MANDATORY status of fields unless something special is introduced.
  • Permits opinionated individuals who want more than one eye per file to keep using the current specs. However, this choice will come at a cost of software tools having it harder to interpret the data (i.e., it is really not a wise or a FAIR choice).
  • Defines a sandbox where we could propose nonregular sampling in _physio files, by enabling a new special value in "SamplingFrequency" ONLY for specific RecordingTypes 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:

  • permits a rigorous specification for eyetracking files, and
  • lays the groundwork for future BEPs working on specific physio signals that have their own domain of key metadata fields

Response 1 by RG

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.

Response 2 by RG

Remi also shared two related efforts:

OE has posted this document and the BEP in the Physiopy slack channel.

Meeting 2024/02/22

Suffix (_eyetrack) or keep the old (recording-eyetrack_physio)

Pro:

  • Quickly tells you there's ET data in the dataset

    ​​dataset.get_eyetracks()
​​> gives you a number of files
​​>

  • 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:

  • What happens with "old" _physio data? Deprecation?
    • Risk of new _eyetrack worked-around to lower the requirements to get a dataset get the BIDS-valid seal of approval.

Separating recordings by eye

Separating metadata for each eye:

  • eye-1_eyetrack.ext, or
  • recording-eye1_physio.ext

Mandatory or Recommended?

  • Julia - mandatory
  • Martin - mandatory
  • Let's go with mandatory

Non-regularly sampled data ("physioevents?")

  • _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:

    • missing timepoints (e.g., when switching recording off) can only be encoded with n/a (a lot of rows filled with them in every column)
    • cannot have two rows for a single sample - this forces "unraveling" all columns (e.g., the standard gaze position columns plus all the parameters of the saccade model in the case of eyelink)

  • 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).

    • This will likely be frowned upon since it resolves a general problem for a single data type, while the spirit of BIDS is that we need homogeneous specs across datatypes.

  • 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).

    • while trying to move _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.
    • A problem with this new file may emerge when we want to have two different 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.).
      Having "events" and "messages" together doesn't seem like a crazy restriction, though (it would require an extra column "message" filled with n/a for "events").

Naming of these "triggers"

  • This discussion seems something we will need to address as part of the above point.

Tobii

reply to https://github.com/bids-standard/bids-specification/pull/1128#issuecomment-1851492412

Last changed by 
 
Oscar Esteban
1
334

Read more

BEP 038 Review

This PR reviews BEP038 under the concerns I raised in #1281. I will open this PR as a draft and continue building on it (as well as this summary message) over the next week.

Jun 12, 2024
NiPreps Roundup (bi-monthly)

Date: Feburary 22, 2023 Time: 6.00pm CEST / 5.00pm UTC / 12.00pm EDT / 9.00am PDT Zoom link: please request to be added to the event messaging to &lt;nipreps@gmail.com&gt; Agenda Finally, official introduction of Elodie Savary, Ph.D. Elodie has been recently hired as a Research Engineer to lead the development of cross-NiPreps infrastructure, taking the governance documents and their approval to the finish line, centralize the communications flow, and, in general, be responsible for all the action items regarding the CZI funding. CZI EOSS5 award We will walk through the aspects that have been requested for funding, see what is funded by this grant and what is covered by the R01 that started in June 2021, etc. Elodie is transferring the action items from the project proposal into this GH project: https://github.com/orgs/nipreps/projects/4/views/1In broad terms, the R01 focuses on individual -Preps (fMRIPrep, dMRIPrep, ASLPrep, PETPrep, MRIQC) and underlying neuroimaging developments (e.g., SDCFlows) while the EOSS5 focuses on community building and scientific software engineering aspects.

Feb 22, 2023
fMRIPrep / NiPreps first roundup meeting

Date: April 14, 2021 Time: 6.00pm CEST / 4.00pm UTC / 12.00pm EDT / 9.00am PDT URL: [redacted] Agenda Welcome and introduction to the NiPreps concept (10min) [preparation: browse the website www.nipreps.org if you can] Ongoing NiPreps projects (5min):fMRIPrep (https://github.com/nipreps/fmriprep) dMRIPrep (https://github.com/nipreps/dmriprep) NiBabies (core utilities to build f/dMRIPreps for infants; (https://github.com/nipreps/nibabies))

Feb 6, 2023
dMRIPrep Workshop Agenda

Jan 13, 2020
Read more from Oscar Esteban
Published on HackMD