GSoC 2026: Use mffpy for EGI Reader

[PragnyaKhandelwal]

This is the meta-issue to track the milestones for my GSoC 2026 project replacing the internal EGI reader with the mffpy backend.

Phase 1: Core Refactor & CI Hardening

• Purge existing internal helper functions from tests
• Make sure all tests pass on all platforms
• Replace internal event-reading helper with calls to mffpy MRG: Use mffpy for EGI MFF event reading #13932
• Replace internal metadata-reading helper with calls to mffpy MAINT: Use mffpy for EGI metadata reading and add PNS shim #13945
• Replace internal data-sample-reading helper with calls to mffpy MAINT: Replace internal EEG sample-reading helper with mffpy #13973
• Migrate _get_ep_info and _get_signalfname in general.py to mffpy-backed parsing MAINT: Replace defusedxml with mffpy in _get_ep_info and _get_signalfname #13991
• Migrate _get_gains to mffpy, remove _extract, and drop defusedxml entirely
• Migrate EEG calibration to mffpy-native scaling and remove _get_eeg_calibration_info

Phase 2: PNS & Annotations integration

• Replace PNS binary block reader (_block_r) with mffpy-backed reading and clean up remaining legacy helpers
• Add cel# condition mapping for event codes MRG: Use mffpy for EGI MFF event reading #13932 (follow-up)
• Add full PNS annotation support
• Refactor _get_montage for custom sensor layouts

Phase 3: Validation and parity testing against legacy reader

• Conduct side-by-side parity testing against legacy reader

Phase 4: Read optimization and memory management

• Optimize memory consumption for preload=False
• Benchmark reading speeds and implement chunk-caching if needed

Phase 5: Documentation, gallery examples, and final polish

• Add gallery examples and final code cleanup

[drammock]

given my feedback in #13914 (about making each PR smaller / less ambitious) I think it makes sense to have this checklist be more fine-grained. For example, something like:

- [ ] purge existing internal helper functions from tests
- [ ] make sure all tests pass on all platforms
- [ ] replace internal event-reading helper with calls to mffpy
- [ ] replace internal metadata-reading helper with calls to mffpy
- [ ] replace internal data-sample-reading helper with calls to mffpy
- [ ] add support for PNS reading
- [ ] etc etc

[PragnyaKhandelwal]

given my feedback in #13914 (about making each PR smaller / less ambitious) I think it makes sense to have this checklist be more fine-grained. For example, something like:

Thanks @drammock, that makes perfect sense! I have updated the checklist above to be much more granular for Phase 1 as you suggested. As I move on to the later phases over the summer, I will make sure to expand those into smaller, granular checkboxes as well.

[drammock]

I have updated the checklist above to be much more granular for Phase 1 as you suggested

Great, thanks. Just to be clear: I haven't immersed myself in the MFF code recently, so the checklist I suggested is just a guess. You (and @scott-huberty) should adjust that list based on your knowledge of what the code does and how much work each step will be

[scott-huberty]

I have updated the checklist above to be much more granular for Phase 1 as you suggested

Great, thanks. Just to be clear: I haven't immersed myself in the MFF code recently, so the checklist I suggested is just a guess. You (and @scott-huberty) should adjust that list based on your knowledge of what the code does and how much work each step will be

@PragnyaKhandelwal and I met today, we reviewed the mne.io.egi.tests module. It doesn't look like the test suite relies on any internal functions or attributes, there are no xfail/skipif marks, and the test suite passes on main. So we agreed that this week @PragnyaKhandelwal can work on a micro-PR to use mffpy to read EGI events. if the existing test suite fails, we will investigate the failures together.

[scott-huberty]

Phase 3: Validation and parity testing against legacy reader

• Conduct side-by-side parity testing against legacy reader

Since we have an existing EGI test suite, I think this "parity testing" happens with every PR, as opposed to being its own dedicated step. Unless by "validation and parity testing", you are suggesting to carry out a more comprehensive parity benchmark (e.g. using a publicly available dataset) that goes above and beyond our test suite?

[PragnyaKhandelwal]

Since we have an existing EGI test suite, I think this "parity testing" happens with every PR, as opposed to being its own dedicated step. Unless by "validation and parity testing", you are suggesting to carry out a more comprehensive parity benchmark (e.g. using a publicly available dataset) that goes above and beyond our test suite?

You are exactly right, @scott-huberty! The standard parity checks are covered by the CI on every micro-PR via mne.datasets.testing.
Phase 3 is meant for exactly what you suggested: a much more comprehensive parity benchmark using real, publicly available datasets that go beyond the lightweight test suite. To avoid any confusion, I will rename Phase 3 to 'Extended Validation & Edge-Case Benchmarking'.
Let me know if that sounds like a good plan!

[PragnyaKhandelwal]

Should I check the boxes for event-reading and metadata part of phase 1 @scott-huberty?