BEP042 surface electromyography (HDsEMG/EMG)

[neuromechanist]

UPDATE April 12, 2024,
Important Links for faster access:

• BEP Google Doc

• List of HDsEMG/EMG-specific terms

• HDsEMG/EMG Element group

• Pros and cons of having HDsEMG/EMG as a single BEP

---

Good day,

Based on the BIDS Extension Proposal Guideline, I want to start the discussion to extend the BIDS to include HDsEMG.

HDsEMG involves recording multiple streams of electrical activity from the skin surface above a muscle or a group of muscles and provides a spatial representation of the muscle activity as seen on the surface (i.e., the skin).

There is a rapidly growing interest in the HDsEMG domain, especially as several blind-source separation techniques can decompose the signal array to motor-unit spike trains.

Source: Pubmed, retrieved 12/08/2022 from a search query including the phrase "high-density electromyography" and "HDsEMG"  

Also, at least three independent and public datasets are available with extensive multi-task and multi-session recordings, but they are not in the BIDS format. See Malešević et al., Sci Data 2019, Matran-Fernandez et al., Sci Data 2019, and Jiang et al., 2021 IEEE TNSRE.

HDsEMG findings closely connect to brain imaging and mobile Brain/Body Imaging by providing insights about muscular activity at the motor-unit level. Also, this modality can become easily integrated into other brain imaging studies as a standalone modality that informs about the efferent pathways or with functional connectivity to the other brain imaging methods. A great tutorial describing the basics of the HDsEMG and its decomposition is available at Del Vecchio, et al., J Electromyogr Kinesiology 2020

On the instrument/hardware side, the sooner the events, data files, and the recording information convert to the BIDS format, the less possibility for error and much greater savings in the researcher’s time. OT Bioelettronica (OTB) and its esteemed technical team, one of the leading companies in manufacturing HDsEMG instruments, expressed their interest in adopting the BIDS standard for single-subject implementation at the recording time. We hope to be able to implement a transparent recording and dataset scheme that starts with data collection.

The motor unit activations, spike trains, and the derived metrics from this information are derivatives of HDsEMG, and are usually computed using blind source separation (BSS) methods such as Convolutive Independent Component Analysis (ICA). However, the HDsEMG BSS process, much like all BSS in the biosignal domain, has many assumptions and requires tuning several hyperparameters. We hope this proposal extend the proposed guidelines in BEP021, Common Electrophysiological Derivatives to HDsEMG, and also provides transparency on the reported and provided BSS results (as reported in the derivative directory) both when the BSS is performed at the data-collection point for a single subject (by the instrument software) and when it is done as a post-processing step by the researcher.

We appreciate your comments and contribution to this potential proposal. We look forward riot hearing from you, and in the coming days, we will also reach out to the authors of the public data to request their help in this effort. If you have any questions, please do not hestiate to conact me, Simone Posella (OTB, @SPosella), or Fabio Bolognesi (OTB, @FabioOT).

[FabioOT]

Good day,
all OTB company is really excited for the development of this new EMG format, which can improve the standardization of such a growing sector like EMG research. OT Bioelettronica s.r.l (https://otbioelettronica.it/en/) is involved in this sector from many years, all of our applications span most of the biomedical signals with a dedicated attention for EMG (iEMG, HDsEMG, bipolar EMG) and EEG acquisitions. For this reason the possibility to directly work in a new standard for these types of acquisitions, represents an excellent opportunity that we do not want to miss. Actually me and @SPosella (software developers) are fully immersed in the development of our new main platform for the communication with OTB instruments, the idea is to include the Bids format in the files which can be visualizzed and processed through it (and maybe in the future use it as default format). Although our priority is the release of a new software, we'll do our best to include in the official release of next year, the first prototype structure of Bids format, in this way a lot of new contents will be included for all of our customers, not just a totally fresh new platform to have fun with, but also a new standard format to unify all the researchers under the same "flag".
Greetings from all the otb team and happy holidays to all.

[sappelhoff]

Hi @neuromechanist et al.! Nice to hear that you find BIDS valuable and want to implement support for EMG. These are busy days, so I don't expect much to happen until early next year (including a more thorough pass by me and some questions / recommendations). However I can already tell you that you'll be able to reach a much larger audience by cross-posting and advertising this issue on some of our BIDS channels such as

• the mailing list: https://groups.google.com/g/bids-discussion
• neurostars (with the "bids" tag): https://neurostars.org/tags/bids
• brainhack mattermost: https://mattermost.brainhack.org/

Once we discussed some more (soon), we can also advertise via Twitter/Mastodon and hopefully get more EMG researchers involved. I could very well imagine that there are already some people working with BIDS who also work with EMG, and it'd be valuable to get their input on what's needed in BIDS to become "nice" for EMG.

[neuromechanist]

Thanks @sappelhoff, a lot for the introduction and instructions. Of course. I will cross-post to make sure that the message reaches interested researchers.

Just to clarify, This BEP is not about EMG but about high-density surface EMG (HDsEMG). HDsEMG is recording from a single muscle (or a group of closely positioned muscles) with multiple electrodes (usually 32 or 64) to find the spatial distribution of the electrical activity over the muscle and to potentially recover motor-unit activity using convolutive ICA.

The practice, data collection, sensor placement, analysis, and use cases of HDsEMG can differ considerably from EMG. For example, while EMG is usually collected from multiple sites on the body and is bipolar, HDsEMG is mainly collected from one or two single muscles, and the collection is monopolar (i.e., reference is on the bone).

Also, as much with the EEG ICA, it turns out the decomposing HDsEMG to the motor units provides good accuracy compared to intramuscular EMG (iEMG):

This is from Del Vecchio 2020, showing successful pickup of the motor units from HDsEMG as compared to iEMG.

I believe that EMG is already included as a part of BIDS-EEG. I think this setup (i.e., EEG and EMG being together) makes sense for the brain-body recordings and makes the analysis straightforward. However, I believe that an extension of BIDS is necessary for pure EMG setups (i.e., not including EEG), biomechanics, physical therapy, and others. Still, this is out of the scope of the current HDsEMG issue 🙈.

Having said that, I am interested in BIDS-EMG, but as you said, I also believe it requires a large-scale collaborative effort from researchers across many disciplines. On the other hand, HDsEMG is rapidly on the rise but is not yet a fully streamlined and widely-used modality. So, it might be just the right time to extend BIDS to HDsEMG.

Happy holidays and see you in 2023!

[robertoostenveld]

Hi Seyed,

Let me shortly chime in here - also to ensure I get notified of new activity on this issue. Thanks for sending the email to the google group, that is what got me here.

I did my PhD research in the group of Dick Stegeman and was involved in some of the HD-sEMG research, for example this, this, and this. I think I still have a decent understanding of HD-sEMG recordings and how the data is analyzed - although I have not kept up to date with more recent work. I also happen to have a good understanding of BIDS and BEPs ;-)

Perhaps you have been contacted by others with interest in a HD-sEMG-BEP. I think it would be good to plan an online meeting to get to know each other and make some initial plans how to tackle this.

best regards,
Robert

[robertoostenveld]

Some time ago I already had a go with data2bids to convert an EMG dataset to something that resembles BIDS. See https://www.fieldtriptoolbox.org/example/bids_emg/. Note that that example is conventional EMG, not high-density. I don't know whether I still have some of our own HD-sEMG recordings in my backups/archive. If so, those could be a starting point for a better draft example. If not, I could ask the EMG colleagues with whom I did it back then.

[neuromechanist]

Hi Robert,

Thanks a lot for your input. I actually have an email going out to you and @CPernet this morning (8 am ET) about this BEP. I think I need to revise it now a little 😅.

The papers are super great and helpful, especially regarding the setup and demonstrating how HDsEMG can also help with intricate musucalr structure in the face and neck area; thanks for sharing.

Yes, probably a short startup meeting is needed at this stage. I will share the starting draft and the working group chat here in the next couple of days. I will also reach you and others via email (and also the group chat).

We have access to a good amount of HDsEMG data, including public datasets. But, most (if not all) are from OTB instruments. It would be great if we can also provide datasets from other instruments to ensure the efforts would work on as many files and datasets as possible.

All the best
Yahya

[CPernet]

tagging @GiacomoBert from BEP37NIBS for which Shokoofeh and Joona will work on an hdEMG + TMS dataset -- as a general rule, we want as much overlap with any electrophysiology if there is a way to have EMG and hd-EMG that's a plus.

[neuromechanist]

Thanks, @CPernet, for adding potentially interested researchers. I believe having EMG and HDsEMG together, or separately can make a perfect topic for the first workgroup meeting.

[neuromechanist]

Hello back,
As promised, here is the ongoing BEP draft that started a while back. We have been drafting two parallel file/folder structures as the aim is to have both per-person structures suitable for saving data files directly after recording and also multi-subject datasets, which is the traditional BIDS data structure:
https://docs.google.com/document/d/1G5_Eu2OemcZXS9xOGINPA6SUTaZOml7LBmZCMnUhTXA/edit?usp=sharing

Here is also the BIDS-HDsEMG working group invitation to the Element/Matrix platform. I have just created it, as we need to retire the Slack group and migrate to an open-source and free platform. Hopefully, the members of the Slack channel will join soon as well 😊:
https://matrix.to/#/#bids-hdsemg:matrix.org

[neuromechanist]

The call for the first meeting is up now.
Please let us know your availability at: https://whenisgood.net/bids-m1
Also, everyone can suggest agenda for the first meeting at the BIDS-HDsEMG at the meeting-minutes room of the workgroup chat.

Looking forward to seeing you there.

[neuromechanist]

Good day everyone,

The inaugural meeting for BIDS-HDsEMG will be on Monday, Jan 30th, 2023, 9 am ET, 3 pm CET.

You can join the meeting using this link: https://ucsd.zoom.us/j/97533232141
You can also find the final agenda (and minutes of the meetings) in Element.

I hope to see you all on Monday.

[neuromechanist]

To provide an update and resume discussion, the first meeting was held on Jan 30th, 2023, and we need to address the following questions:

1. List the pro and cons of having EMG and hdsEMG in the same BEP (A non-exhaustive list is available at Pros and Cons of having HDsEMG/EMG Google Doc and will be circulated through Element by 4/16 for comment)
2. List all companies that are explicitly active with HD-EMG in terms of hardware and software
   a. Hardware: possibly do a random sample from the literature to see which amplifiers are being used (just count them, total 148 papers in 2022 and 2023 (up to May 10th), first 40 sorted by year, 23 used OTB, 4 used TMSi, 1 each Intan, LSiN, Delsys, Available on Instruments used in research for HDsEMG Google Sheet Planned due 4/23)
   b. Software: mainly custom scripts being used? (Planned, due 4/23)
3. Can the current BIDS specifications/tools convert the HDsEMG to a BIDS-compatible dataset (a draft of necessary fields to describe HDsEMG that are not covered by other modalities will be circulated via Element by 4/12, and is accessible in this HDsEMG/EMG-specific terms)
4. Would it be possible to make some example datasets available through https://www.otbioelettronica.it/en/downloads? (Yes, files are available at OTB File Sturcure, an EEG-BIDS sample will be added this week, with a comparative report of which metadata is available but not reported by the OTB converter, due 4/14)

PS: Apologies for the pause in the efforts; an extended sick leave, a major grant submission, and a transcontinental move happened all in this period.

[neuromechanist]

@robertoostenveld kindly converted the sample HDsEMG (and bipolar) EMG datasets to BIDS format which is available in this BIDS folders under mne-tools/mne-bids#1129.

Here are a summary of the contents of each folder under the BIDS folders. I agree that the main issue is to make the data FAIR; otherwise, electrical signals are electrical signals:

BIDS1: Delsys Trigno Mini EMG recordings

The file contains two sensors. Each sensor has one channel EMG (bipolar) and a six-channel IMU. The location of the IMU and the EMG probes are different. Therefore, EMG and IMU (all six together) may need separate metadata regarding their location, orientation, etc. This problem is not present in the normal (non-Mini) sensors. On a separate note, should IMU channels be recorded with EMG?

BIDS2: Delsys Galileo HDsEMG recordings

The file contains recordings of two Galileo sensors. Each Galileo sensor consists of four electrodes in a diamond-shaped arrangement, with an inter-electrode distance (IED) of 5mm. The signals are recorded in monopolar mode, and the reference is at a separate site. Therefore, two sets of locations are required for each Galileo sensor: 1- for the electrodes and 2- for the reference.

BIDS3: g.tec Pangolin

Each Pangolin array has 16 electrodes (there can be up to 64 Pangolins) with IED of 8.6 mm; there can also be one additional electrode to act as a reference. The recordings are monopolar. To report the Pangolin's location, the sensor's position, the sensor, the orientation of the sensor, and the position of the reference electrode are needed.

BIDS4: OTB Sessantaquattro

The file contains a single 64-electrode hd-EMG recording using OTB sessantaquattro. Sessantaquattro is an A/D converter that connects to electrode arrays with different shapes and IEDs. The recording can also be bipolar (either in the longitudinal or transverse direction) or monopolar, with a reference far from the electrode array.

One thing common across all files is a need for grouping the electrodes/channels within an array or sensor. Each system can contain multiple arrays, which can have different features, including location, size, and IED.

Also, several other pieces of information are missing beyond the sensor location/muscle or recording mode (bi/monopolar) and reference. They include the relative position of the electrode to the muscle innervation zone, how the innervation zone is determined, which muscles are covered by the arrays, etc. I'll try to summarize them in the Google Doc under item 3 above.

[robertoostenveld]

Regarding "On a separate note, should IMU channels be recorded with EMG?", I would say yes. That aligns with how we deal with auxiliary channels in MEG, EEG, etc. However, in an XXX dataset (with XXX being MEG, EEG, NIRS, iEEG, EMG) the XXX channels are required. The optional auxiliary channels are to be sampled with the same equipment. If it were data from a different device, it should be stored as its own modality.

[robertoostenveld]

In the case of the Galileo and Pangolin the electrodes have a fixed arrangement, similar to "grids" and "strips" in the iEEG specification.

For the Pangolin I would say that _emg.json would among others contain

{ 
Manufacturer: g.tec,
ManufacturersModelName: g.HIamp,
ElectrodeManufacturer: g.tec,
ElectrodeManufacturersModelName: Pangolin
EMGPlacementScheme: "on the left and right biceps"
EMGElectrodeGroups: "pangolin1: 4x4 grid on the left biceps, pangolin2: 4x4 grid on the right biceps", 
EMGGround: "left elbow",
EMGReference: "right sternum"
}

The identifiers pangolin1 and pangolin2 would also appear in the _channels.tsv.

The anatomical locations might be too imprecise but can be made better (medical/anatomical terminology is not my expertise). This does not specify the orientation yet, I don't directly have an idea for that other than free-text in EMGElectrodeGroups.

[robertoostenveld]

For the 4th example it would be for example with this HD04MM1305

{ 
Manufacturer: OTB ,
ManufacturersModelName: Sessantaquattro,
ElectrodeManufacturer: OTB,
ElectrodeManufacturersModelName: HD04MM1305,
...
}

[robertoostenveld]

For your information, I have updated the examples here on https://drive.google.com/drive/folders/1k-PNBejOYi4JCE8iLxYhQ6R7L1kWuAbD?usp=sharing such that they use the emg directory rather than the beh directory

[neuromechanist]

Thank you @robertoostenveld for adding the EMG-specific fields to the GDrive folder.

Querying hd-sEMG on PubMed for 2022 and 2023 results in 148 papers. After sorting by year and examining 40 of them, 6 did not include EMG data. from the rest 34, 23 studies were done using OTB systems (~68%), 4 using TMSi (12%), 2 using custom amplifiers and grids, and 1 using each of LSiN, Intan, and Delsys systems.

A recent paper lists the potential requirements for hd-sEMG experiment designs, including the parameters that should be taken into account in designing the protocol, sensor placement, reporting, and analysis.

Surprisingly, most studies reported IED and electrode diameter or mentioned the electrode part number. Several also provided their use of EMG problems to find the innervation zones and placement of the sensors.

Here are a couple of points that would need further exploring:

1. Sensor placement information require several more details than the name of the muscle. Innervation zones are distinctly different from the muscle belly (see the image below (from Barbero 2012), for the innervation zone of Rectus Femoris, which is in the proximal 50% of the muscle, whereas the muscle belly is at 50%). hd-sEMG would be best recorded if it captures the innervation zone, while the bipolar sMEG is recorded at the muscle belly (according to SENIAM).
   

2. Using the strip and grids from BIDS-iEEG is very helpful, but I should note the inherent anatomical variability of the cortex and limbs. Even at the skull and scalp level, the head circumference variability (max-min)/mean is ~14% for adult males (FAA report, 1993), while the for arm circumference variability is 72% for typical young male adults (Rostamzadeh, BMC Pediatric 2021). So, merely describing the electrode locations would not be sufficient to understand which muscles and what area of the muscle are covered by an hd-sEMG array. We should consider that muscle size and composition change significantly with training and even when comparing dominant and non-dominant limbs. The grid/organ size ratio is an important consideration.

3. In this context, the Revisiting space definition in BIDS (reference frames, coordsys) with respect to Motion extension #1488 is very timely. We need conventions to define reference frames and coordinate systems to determine sensor placement and the area covered by the sensor wrt the organ for FAIR hd-sEMG datasets.

4. Custom electrode arrays are particularly challenging to report and reproduce but provide the opportunity for accounting for organ size differences (e.g., an athlete or an obese person, see Ershad, PNAS Nexus 2022) or for recording intricate muscles such as neck and face muscles (see Leung, Laryngoscope 2023, and Chen, TNSRE 2023). We will likely see more of these types of research and data in the near future and should be able to define a standard that facilitates reproducible results.

5. I also have added a Google Doc for the pros and cons of having EMG and hd-sEMG together in one BEP. Overall, it boils into how many/much details each modality would require to include to present a ~FAIR dataset.

[Remi-Gau]

Had a quick look at this issue and the google doc.

Maybe I am wrong but it seems that having a single BEP for sEMG and hdsEMG still makes sense.

I suspect both methods would still share a lot common points in terms metadata, auxiliary files... And that filenames could still make it explicit which methods was used.

[robertoostenveld]

@agramfort recently showed interest in this, so he might want to chime in.

[agramfort]

Indeed. I think it will be great to have a standard way of sharing / organizing sEMG data. Meta CTLR team should soon open source large datasets and using bids is to me the best way of doing it. I am currently consulting a few people to see what is the best course of action. Please reach out to me if you want to push this effort forward.

[neuromechanist]

Thanks, @Remi-Gau, for looking into the BEP proposal (and for the earlier chat at the BIDS maintainers meeting).

Yes, the suffix (modality) still can be different while the data type is the same (suffix: _sEMG, _hdsEMG, data type: emg, BIDS Common Principles). This could also work for intramuscular/fine-wire EMG (_iEMG (i for intramuscular or invasive)) (see this recent paper as an example) (Note: 80-20 BIDS development rule).

One critical metadata difference between HDsEMG and EMG is the sensor placement. @JuliusWelzel, @sjeung, and I are converging, after almost a year, on a draft standard for sensor placement that would work very well for this purpose.

@agramfort, yes, please. We want to push this forward, Thanks. I will also reach out to some academic contributors for potential interest.

[neuromechanist]

In the BEP Google Doc, we originally had this idea of single-subject datasets/tar files that manufacturer stakeholders can use to generate their data (we called it HDsEMG .BIDS file structure).

During my conversation with @yarikoptic, it turns out that this is pretty much inline with an issue in BIDS 2.0 development:

• Allow composition of a BIDS dataset (dataset level) from smaller (subj or subj/ses) level bids-2-devel#59.

So, it might be best to separate the efforts, dedicate this BEP to EMG-BIDS, and later work on the small-dataset BIDS structure. I edited the issue title accordingly and am more than happy to remove the related parts from the BEP Google Doc. I appreciate your comments.

---

Edit 4/14: BIDS file structure is removed from EMG-BIDS BEP.

[agramfort]

@neuromechanist I am arriving a bit late in the conversation. I will start with a few naive question to see where we are.

• What existing file format are currently being considered for EMG (EDF?, BrainVision?, some vendor format eg from Bioelettronica?)
• What is the main motivation for having different modalities for EMG and hdEMG? From the BIDS perspective it seems a bit an overkill to me.
• Given that we can already have EMG channels in an EEG dataset, I imagine that what we are missing is channel definitions for EMG sensors locations. The logic of electrodes and channels is already designed for EEG so can we reuse this as much as possible?

[neuromechanist]

@agramfort, it is still early. Given that the formats and metadata structure for human electrophysiology, the EMG-BIDS BEP has a huge headstart. Yet, the EMG community is very diverse and passionate about EMG-specific phenomena and potential solutions (for example, cross-talk and using single or double differential sensors to avoid it, See Koh 1993)

What existing file formats are currently being considered for EMG

Definitely EDF/BDF (16-bit, 24bit). Bioelecttronica seems to have potential since (1) It is open source, and (2) ~70% of the HDsEMG data is being done with their instruments. I think a major issue is major EMG non-opensource formats, namely Delsys and Noraxon.

What is the main motivation for having different modalities for EMG and hdEMG?

One advantage is potentially faster convergence; engaging sEMG, HDsEMG, and iEMG communities might be a significant undertaking. Still, with the recent convo with BIDS maintainers, we'll work toward integrating the modalities and inviting different communities to provide input.

What we are missing is channel definitions for EMG sensor locations.

Sensor locations are a major concern for FAIR EMG data distribution (as it is for BIDS-Motion). The EEG logic for electrode location is pretty good. We are extending a similar format for surface anatomy with the BIDS-Motion Devs. However, there are several other metadata needed for EMG as well. I tried to summarize the currently missing metadata in the Necassary Terms Google Doc

[robertoostenveld]

@agramfort you may be interested in following the discussion in #197 regarding file formats for tabular data, including physio and stim.

[dorahermes]

@bids-maintenance Can you perhaps comment on the status/checks needed to proceed. Seems like a group of people is getting excited to move this forward?

Whether hdEMG and EMG should be in the same file or separate files/formats can then be flushed out in more detail.

[Remi-Gau]

@dorahermes
Just discussed today at the maintainers meeting and this is likely gonna get an official BEP number.

[neuromechanist]

While it is a little belated, happy to announce that the EMG-BIDS BEP is now officially BEP-042 🎉.

[neuromechanist]

Together with Motion-BIDS maintainers (@sjeung and @JuliusWelzel) we are developing a unified sensor placement specification. The main goal of this specification is to properly annotate sensor locations under a specified accuracy. We believe that this specification will increase data transparency and reusability for both Motion-BIDS and EMG-BIDS. Annotaing sensor locations precisely is crucial for EMG, especially as the muscle composition varies across people signficantly.

Also, we are working with the HED working group (@VisLab) to implement a version of this specification in HED as a partnered schema.

Please let me know if you are interested in collaboration.

[neuromechanist]

Good day all,

Thanks for sticking to this BEP. We will try to have a kick-off meeting to work on the specs more regularly. Meetings will be tentatively biweekly, on Wednesdays at 8 am PT / 11 am ET / 5 pm CET, with the start the next week, Sept. 11, 2024.

Please reach out if this time will not work for you and if you plan to participate actively. We will try to make it work for everyone.

I will share the meeting links on our Element Group under the main discussion and email the invite to everyone mentioned in this issue. Please feel free to decline, and please feel free to extend the invitation to anyone interested in contributing.

Since no specs are good without tools, I'd like to invite @arnodelorme, @drammock, and @larsoner for their support in developing import/export tools for Matlab/EEGLAB and MNE-Python.

[neuromechanist]

Although belated, the kickoff meeting was held last week with @arnodelorme, @robertoostenveld, @larsoner, @drammock, Lena Ting, Janna Protzak, and Mario Braklin, and me.

We went over the definitions, briefly discussed sensor/electrode location metadata, and compared electrode locations in _electrodes.tsv in EEG-BIDS and the placement column in Motion-BIDS. We will continue this discussion by looking at other electrophysiology specs, including iEEG-BIDS when we reconvene on September 23rd, 11 am ET.

Please reach out if you want to join the call so I can send you the invite.

[robertoostenveld]

In the zoom meeting just now we touched upon the 80/20 rule and a discussion was brought up whether high-density or regular EMG is more commonly used.

I therefore revisited the query that @neuromechanist posted above for pubmed with "high-density electromyography" or "HDsEMG", which returns 337 articles which are the ones shown above , split over years. When I search on pubmed for "EMG" not "high-density electromyography" not "HDsEMG" there are 39574 articles

I also searched for publications in Psychophysiology with "EMG" in the title and found 906 articles. Screening of the titles suggest that most of those are not high-density. For high-density I only find 4 articles in that journal.

In Muscle and Nerve the fractions appear to be similar.

Based on these, regular EMG seems to be much more commonly reported upon, with a factor of 100x or so. However, the level of detail recorded in high-density EMG is much higher, investments are larger, and therefore the value of sharing EMG data is probably larger for HDsEMG researchers. I therefore hope that we can create a BIDS extension that works for both.

[neuromechanist]

The 9/25 meeting was held with @arnodelorme, @robertoostenveld, @larsoner, @drammock, @tjeerdboonstra, Raul Simpetru, and me present. We discussed the common metadata fields from EEG. The issue of anatomical landmarks and how the electrode placement and channel locations was raised. We also discussed electrode placement and channel description of example one in the EMG-specific metadata document. We also briefly discussed the need for annotating reference electrodes in bipolar and monopolar EMG recordings.

In the zoom meeting just now we touched upon the 80/20 rule and a discussion was brought up whether high-density or regular EMG is more commonly used. ../

Thank you, @robertoostenveld. I agree that hdsEMG is far less used and support Robert's rationale for including it. I would also like to add to the rationale that the ratio of shared hdsEMG datasets to all hdsEMG research papers is much greater than the ratio of shared EMG datasets to all EMG papers. So, it seems the relatively small community using hdsEMG is more inclined to share their data than the researchers using EMG. I hope this will change with our efforts.

The 80/20 rule during this week's Zoom, in case it did not get across correctly, was about EMG examples in the EMG-specific document (not high-density) that we were discussing. I raised the point that most EMG research is carried out with EMG-specific instruments. The first example, getting most of the meeting time, had several shortcomings: a Raspberry Pi with a general-purpose ADC converter, generic electrodes with undefined function of each electrode, and unclear electrode placement, Link to the paper in discussion. I do not think this example represents EMG recordings, so I raised the 80/20 concern. Still, since this example had a very generic structure, I believe that we could generalize the electrode and channel description quite well.

The next meeting will be in Four weeks on 10/23, to avoid conflicts with SfN.

[neuromechanist]

at the EMG-BIDS meeting on Nov 6th, @arnodelorme, @robertoostenveld, @larsoner, @drammock, and @tjeerdboonstra discussed Many-to-Many mapping and Localizer concepts.

Many-to-Many mapping indicates that one or more EMG channels can target (and record) one or more muscles. It seems that our examples contain all combinations (1-M, M-1, 1-1, M-M).

We also discussed different localization methods, namely functional localizers (i.e., annotating sensor locations based on muscle function, such as specific contractions or movements) and anatomical/landmark localizers (i.e., annotating sensor locations based on measuring distance from anatomical landmarks).

We are still at Example 3. I'd be grateful if we can work on Examples 3, 4, and 5 by adding their comments in a single paragraph for each examples, so that we can discuss all comments in the next meeting on 11/20.

[neuromechanist]

During the past two sessions (11/20 and 12/4), the group (@arnodelorme, @drammock, @JuliusWelzel, and @tjeerdboonstra) reviewed the examples, removing one example and added the recently released @facebookresearch EMG2Qwerty data.

We particularly discussed:

• multi-electrode arrays, and how to describe the locations of the elements in the array.
• using acq-<label> entity for multi-instrument recording.
• reusing iEEG group and dimension metadata to describe multi-electrode arrays.

The next steps (after addressing the one remaining example) are:

• Revise the metadata and entity table in the Fields document, to capture the example discussions.
• Add the metadata to the BEP and decide on the metadata location.
• Create sample datasets for BIDS examples.
• Finalize the BEP to transition to pull request.

We hope to be able to complete at least the first two items before the year's end.

[drammock]

After last week's meeting, I've put together a summary of the EMG-specific JSON fields / TSV columns, in prep for updating #1998. There are some outstanding questions that could benefit from the groups' perspectives. Here's where I think things stand:

emg.json

• use EMGPlacementScheme when all channels/devices were placed according to the same approach. If placement scheme varied by channel/device, use the placement_scheme column in channels.tsv instead, and include a non-empty string value here (values such as channel-specific or see channels.tsv are RECOMMENDED; reserve n/a for cases where the placement scheme is not known).

• use EMGReference when all channels are referenced to the same electrode, or when all channels emanate from bipolar devices with integrated local reference electrodes (i.e., in cases where there is no electrodes.tsv file and the reference column in channels.tsv would say "bipolar" for all channels).

• use EMGInterelectrodeDistance (RECOMMENDED) when all channels have the same value. Otherwise use the interelectrode_distance column in channels.tsv. Not required because in some cases it's not needed (e.g. when IED can be inferred from x,y coordinates in electrodes.tsv)

channels.tsv

columns in parentheses aren't special / different for EMG than for EEG or other modalities.

columns: (name, type, units,) signal_electrode, reference, target_muscle, group, placement, interelectrode_distance, (description, status, status_description, sampling_frequency, low_cutoff, high_cutoff, notch)

• include a signal_electrode column when electrodes are described individually in electrodes.tsv.

• include a reference column when the reference is not the same value for all channels in the file (if it is, put in EEGReference in emg.json instead). Note that if all channels are from bipolar devices and hence the reference is "bipolar" you may record this in emg.json and omit this column, even though it's not true that the same electrode is acting as reference for each signal electrode.

• including a target_muscle column is RECOMMENDED. Use whenever it makes sense. Note that for electrode grids, one can specify groups of muscles, for example, "flexors of the left hand".

• include a group column when multiple multi-electrode devices record into a single data file. If multiple devices record to different data files, they should be treated as separate acquisitions and thus get separate channels.tsv files.

• include a placement_scheme column whenever the approach to sensor placement varied across channels. In such cases, it is RECOMMENDED to use a value such as channel-specific or see channels.tsv for the value of EMGPlacementScheme in emg.json.

• include an interelectrode_distance column when it varies by channel, such that it cannot be included as a single value in EMGInterelectrodeDistance in emg.json. Inclusion is RECOMMENDED; omitting it may make sense when electrodes.tsv exists and includes coordinates for each electrode (thus making IED inferrable / computable).

electrodes.tsv

include this file if you have data on the locations of individual electrode contacts (i.e., you're not only using sensor devices that have integrated reference contacts, AKA, "bipolar" sensors). Columns in parentheses aren't special / different for EMG than for EEG or other modalities.

columns: (name,) x, y, z, coordsystem, (type, material, impedance)

• x and y are REQUIRED (though conceivably with "strip" devices one could specify just x?)
• z column is OPTIONAL, presumably it will only be present when electrode locations were digitized.
• coordsystem column is REQUIRED because of the desire to support nested parent/child coordinate systems, as described in the next section.

coordsystem.json

REQUIRED when electrodes.tsv is present. For reference, other modalities use key prefixes like EEG, MEG, HeadCoil, and AnatomicalLandmark (for suffixes like CoordinateSystem, CoordinateSystemDescription, CoordinateUnits).

Here, we want to support "nested" coordinate systems, where a "parent" defines a coordinate system based on anatomical landmarks (presumed typically in units of percent or mm), and one or more "child" coordinate systems are used for describing device-internal electrode coordinates (presumed typically in mm and in 2D). The two coordinate systems are linked by an "anchor" (typically an electrode) whose identity (name) and coordinates within the parent system sufficient to link the two systems. Since JSON is a very flexible format, this could be done several ways, but I'm inclined toward something that mirrors what is done for MEG, where MEG*, HeadCoil*, and AnatomicalLandmark* keys are all siblings at the file's top level. Some possibilities:

option 1

{
    "EMGCoordinateSystem": "Other",
    "EMGCoordinateSystemDescription": "x: radial syloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
    "EMGCoordinateSystemUnits": "percent",
    "AnchorCoordinates": {      # mirrors AnatomicalLandmarkCoordinates
        "Grid1": [25, 50, 10],  # mirrors NAS, RPA, LPA
        "Grid2": [75, 0, 90]
    },
    "AnchorCoordinateSystem": "EMGCoordinateSystem",  # mirrors AnatomicalLandmarkCoordinateSystem
    "AnchorCoordinateUnits": "percent",               # mirrors AnatomicalLandmarkCoordinateUnits
    "AnchorElectrodes": {                             # no equivalent in other modalities AFAICT
        "Grid1": "E1",
        "Grid2": "E1",
    },
    "Grid1CoordinateSystem": "Other",  # here and below, the key prefix `Grid1` must match a key in `AnchorCoordinates`
    "Grid1CoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
    "Grid1CoordinateSystemUnits": "mm",
    "Grid2CoordinateSystem": "Other",
    ...
    }
}

Note: AnchorCoordinateSystem mirrors AnatomicalLandmarkCoordinateSystem, but with the unusual property that it refers to another coordinate system defined within this file (instead of one of the restricted set of coordinate systems like CTF, CapTrak, etc). That might be a bit of a headache for the validator.

option 2

{
    "EMGParentCoordinateSystem": "Other",
    "EMGParentCoordinateSystemDescription": "x: radial syloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
    "EMGParentCoordinateSystemUnits": "percent",
    "EMGChild1CoordinateSystem": "Grid1",
    "EMGChild1CoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
    "EMGChild1CoordinateSystemUnits": "mm",
    "EMGChild1AnchorCoordinates": [25, 50, 10],
    "EMGChild1AnchorElectrode": "E1",
    "EMGChild1AnchorSystem": "EMGParentCoordinateSystem",
    "EMGChild2CoordinateSystem": "Grid2",
    ...
    }
}

Notes/questions:

1. The main difference is whether the "anchor" keys are specified as their own thing, or are prefixed by the child coordinate system. A secondary difference is whether the key prefixes are conceptually known in advance (Child1, Child2, Parent or Parent1, etc) or are arbitrary (with the constraint that they must occur as keys of the AnchorElectrodes and AnchorCoordinates mappings).

2. Both approaches would require a coordsystem column in electrodes.tsv naming which coordsystem the xy(z) columns reflect.

3. as written above, both option 1 and option 2 assume exactly 1 parent coordinate system for a given set of grids recorded into a single data file. It seems conceivable to have, e.g., 1 grid on the forearm and one on the biceps, and want/need to anchor each grid in a different parent coordinate system (one defined with forearm landmarks, the other with humerus landmarks). Not sure if that falls in the 80% or the 20% of the 80/20 rule, but note that option 2 would be much easier to extend this way (given that you could change EMGParentCoordinateSystem to EMGParent1CoordinateSystem as is done for child systems).

4. In theory, option 1 could be modified such that AnchorCoordinateSystem and AnchorCoordinateSystemUnits were mappings instead of strings:

   {
       "AnchorCoordinateSystem": {
           "Grid1": "Parent1CoordinateSystem",
           "Grid2": "Parent2CoordinateSystem"
       },
       ...
   }

   ...but it would also need a different approach to naming the parent coordsystem keys, as currently it just uses EMGCoordinateSystem to define the (sole) parent.

5. I'll happily entertain other possibilities if someone wants to propose them.

[JuliusWelzel]

@drammock, thanks for the great work.

Have you also discussed how to label if multiple recording devices are used (similar to the tracksys- label in motion)?

[drammock]

Have you also discussed how to label if multiple recording devices are used (similar to the tracksys- label in motion)?

As I understand it, our plan is that if multiple devices go into the same data file (e.g., 2 grids going through same amplifier), then in electrodes.tsv they get distinguished by a "group" column. If 2 devices record to different data files (e.g., a grid and a bipolar sensor) then they are distinguished as different acquisitions (even if they were recorded simultaneously).

[neuromechanist]

Fantastic summary @drammock, thanks.

Regarding the coordinate systems I have a couple of questions/points that will also benefit from the community views:

1. Why should there be a coordsystem.json (and not a required coordsystem key under electrodes.json)?
   There is a single parent key in coordsystem.json for EEG and iEEG and it is required with electrodes.tsv file. So, why not require electrodes.json to have this field following the BIDS sidecar policy? Even when the electrodes.tsv is not defined for EMG (like using integrated bipolar modules) the coordsystem can be present in the channels.json (see subject 6 in [WIP] BEP042 - Emg examples bids-examples#480). I think coordsystem.json is the only orphaned JSON file in the BIDS system.
   I understand that electrodes.tsv is not present for MEG-BIDS, but that is not the case for all other ephys modalities. So, probably MEG should become the special case of having coordsystem.json.
   IMHO, we should also strive for simpler, less crowded directories, so if we can have coordsystem inside electrodes.json, why not do that?
   (This might be also related to [ENH] microelectrode electrophysiology specification (BEP032) #1705 and Formalize specification of shape(s) (AKA contour(s)) #2013, cc: @yarikoptic)

2. EMG modules are often spread across the body, so hopefully we should be able to capture that. What we jotted down on example 5 was something like this, although this is for two grids on the same body part:

{
     "Coordsystem": {
         "forearm-coordsystem":{ 
             "EMGCoordinateUnits": "percent",
             "EMGCoordinateSystemDescription": "X: RSP → USP; Y: Right-hand rule (limits: Olecranon Process → Cubital Fossa); Z: midpoint RSP-USP → LHE; Radial Styloid Process (RSP); Ulnar Styloid Process (USP), Lateral Humerus Epicondyle (LHE), Posterior Elbow (Olecranon Process)"
         },
         "grid1-coordsystem":{ 
             "EMGCoordinateUnits": "mm",
             "EMGCoordinateSystemDescription": "The location of the electrodes with respect to electrode one (1) is given in millimeters. The x-axis is from left to right, the y-axis is from bottom to top. note: the z-axis is not used.",
             "EMGCoordSysAnchor":{
                 "System": "forearm-coordsystem",
                 "AnchorElectrode": "E1",
                 "AnchorCoordinate": [10,80,80]
             }
         },
         "grid2-coordsystem":{ 
             "EMGCoordinateUnits": "mm",
             "EMGCoordinateSystemDescription": "The location of the electrodes with respect to electrode one (1) is given in millimeters. The x-axis is from left to right, the y-axis is from bottom to top. note: the z-axis is not used.",
             "EMGCoordSysAnchor":{
                 "System": "forearm-coordsystem",
                 "AnchorElectrode": "E65",
                 "AnchorCoordinate": [10,0,80]
             }
         }
     }
 }

This is more in line with Option2, I think (but with more nesting). Probably, there are two differences (which IMO are advantageous) in this example:

1. The body parts are explicitly defined as a top key, so it is more straightforward to understand where the electrodes are actually located. For example, looking at grid1-coordsystem, it is clearly anchored to the forearm-coordsystem. Also, this format provides ease of use, researchers can just copy and paste the forearm-coordsystem (or any other body part from a template) and fill in how the modules or grids are anchored to the body parts.
2. JSON keys are simpler and the same (except for the top-level key), so they can have a definition in the specifications. Both Option1 and Option 2 use grid/module-specific keys like Grid1CoordinateSystem or EMG[Parent/Chile]CoordinateSystemDescription which creates a much larger glossary than just defining certain keys as the example above and them be used under different coordinate systems.
   I understand that key names like "EMGCoordinateSystemDescription" for the forearm-coordsystem is not ideal. We might want to consider removing the EMG prefix from the CoordSystemDescription if it is allowed?

[drammock]

1. Why should there be a coordsystem.json (and not a required coordsystem key under electrodes.json)?

This is, I think, a question that is bigger than just the EMG extension proposal. For what it's worth, electrodes.json isn't mentioned anywhere in the BIDS documentation. It is presumably an OK document to include based on the sidecar principle (as you noted above), but I've never seen a dataset that had one (I've also never seen a channels.json, FWIW). So I think for now, it would be pragmatically better if we were more parallel with existing extensions for EEG and MEG and used coordsystem.json instead.

EMG modules are often spread across the body, so hopefully we should be able to capture that.

Well, we do have target_muscle for that. But I see your point; from a user perspective (whether reading or writing the .json file) it would be easier to understand if the top-level keys were something like ForearmCoordinateSystem, PalmarGridCoordinateSystem, etc. But (with my software developer hat on):

• JSON sidecars are meant to be machine readable
• allowing arbitrary keys makes the code more complicated to write and maintain
• minimizing the difference between EMG coordinate system JSON files and the already-existing JSON files for EEG/MEG coordinate systems will minimize the amount of new code that must be written

That said, perhaps the most minimal approach is to nest, as you're suggesting. Here's another proposal that I think combines the best of both of our proposals:

{
    "Forearm": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x: radial syloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
        "EMGCoordinateSystemUnits": "percent",
        "AnchorCoordinates": {          # mirrors AnatomicalLandmarkCoordinates
            "VolarGrid": [25, 50, 10],  # mirrors NAS, RPA, LPA
            "DorsalGrid": [75, 0, 90]
        },
        "AnchorElectrodes": {           # no equivalent in other modalities AFAICT
            "VolarGrid": "E1",
            "DorsalGrid": "E1"
        }
    },
    "VolarGrid": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
        "EMGCoordinateSystemUnits": "mm"
    },
    "DorsalGrid": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
        "EMGCoordinateSystemUnits": "mm"
    }
}

Here, the top-level keys are arbitary, and can refer to anatomical placement (here I've gone even further than you did, and changed "Grid1/2" to "Volar/DorsalGrid"). Then within each top-level mapping, the "standard" BIDS-style keys must be adhered to (so e.g. they all have "EMGCoordinateSystem": "Other"). I'll still push for specifying the anchors within the parent coordinate system though, as (1) it mirrors how anatomical landmarks are handled for other modalities, and (2) I've realized you can actually omit the AnchorCoordinateSystem and AnchorCoordinateSystemUnits keys (AnchorCoordinateSystem will always be "the system this key is nested within" and AnchorCoordinateSystemUnits will always be "the units given for the coordinate system this key is nested within"). For the case where we have 2 different "parent" coordinate systems it would look like this:

{
    "Forearm": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x: radial syloid process (RSP) → ulnar styloid process (USP); y: oleacranon process → cubital fossa; z: RSP-USP → lateral humerus epicondyle",
        "EMGCoordinateSystemUnits": "percent",
        "AnchorCoordinates": {
            "VolarGrid": [25, 50, 10],
            "DorsalGrid": [75, 0, 90]
        },
        "AnchorElectrodes": {
            "VolarGrid": "E1",
            "DorsalGrid": "E1"
        }
    },
    "Humerus": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "whatever",
        "EMGCoordinateSystemUnits": "percent",
        "AnchorCoordinates": {
            "BicepGrid": [40, 70, 0]
        },
        "AnchorElectrodes": {
            "BicepGrid": "E1"
        }
    },
    "BicepGrid": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
        "EMGCoordinateSystemUnits": "mm"
    },
    "VolarGrid": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
        "EMGCoordinateSystemUnits": "mm"
    },
    "DorsalGrid": {
        "EMGCoordinateSystem": "Other",
        "EMGCoordinateSystemDescription": "x-axis left → right, y-axis bottom → top, when grid is oriented with leads at the bottom",
        "EMGCoordinateSystemUnits": "mm"
    }
}

WDYT about that proposed structure for the JSON?

[neuromechanist]

This looks much more coherent 🤗, and BIDS-like. I can see the anchor being used both ways (one having the anchor to the parent, the other adding the anchor to the child).

I see how adding an anchor to the parent is more like adding the fiducials, for example, in the case of EEG/MEG coregistration. On the other hand, adding anchors to children is less commitment, adding/removing children does not change parent fields. Both work well for me.

Re: question 1 (necessity of coordsystem.json), having the coordinate system information as JSON keys is particularly useful for EMG, as we could add CoordSystem to either electrodes.json or channels.json based on the use-case (example 5 vs example 6).

[neuromechanist]

A very interesting multi-device EMG dataset was just released on Sci Data using the EMG-BIDS draft specifications for reaching and grasping objects with different shapes.

paper: https://www.nature.com/articles/s41597-025-04552-5
data: https://dataverse.iit.it/dataset.xhtml?persistentId=doi:10.48557/L6OWMM