EEG.jl -> Present and Future

Could you please extend on this? Maybe …what would be the ideal open/good science Julia environment…what you have seen in the MNE env.

So we all can synchronize with what it means

Sorry, I can see how this might be a bit unclear. I’m actually referring to building infrastructure to work with things like BIDS [1], offer standardized reporting (like e.g. fmriprep [2] does), and other similar things (e.g. automatic generation of method sections, etc.) that have recently been implemented in other packages (not necessary EEG) in an attempt to make research more reproducible.

Also, there are a lot of specific conventions and recommendations in EEG literature (and most certainly other fields) that would make a specialized package go beyond “it’s just a special case of biodata”.

I’m not sure MNE does these things particularly good (albeit better than EEGLAB et al.), but I just wanted to point out that to make any EEG/MEG/whatever-related packages attractive to a wider (scientific) audience, one should definitely consider this.

[1] EEG-BIDS, an extension to the brain imaging data structure for electroencephalography | Scientific Data
[2] Outputs of fMRIPrep — fmriprep version documentation

Btw. I’m typing this on my phone so beware the autocorrect! :slight_smile:

2 Likes

Thank you!
I see what you mean. Really important indeed.

Yes reproducibility is important, but that’s pretty easy once we have our data working with the rest of the ecosystem. I spent a lot of time digging around/recreating/binding standard neuroscience processing pipelines. Once we have things working with the broader Julia ecosystem it’s pretty simple to string together a series of processing steps that have been empirically tested and create a simple package with one or two functions that run it. Give it a Manifest.toml and Project.toml and it’s fully reproducible.

By the way, I’m aware of the BIDS standard and one of the reasons I’m doing this is actually to make it so we can have a better way of interfacing with things that follow it (e.g., OpenNeuro) and still be able to have progressive solutions like Onda. If you’re interested I talked about this in my JuliaCon talk (I still need to figure out Twitch so I can go over a lot of what had to be cut).

1 Like

The Onda format specification defines a (intentionally minimal) data model for LPCM-representable sample data + a directory structure for sets of such sample data. Onda.jl (the package) implements both, but the package’s various API layers are mostly decoupled, with the data model itself acting as the thread that ties things together. The Dataset API (which implements the directory structure part of the Onda format) is actually the outermost and thinnest API layer provided by the package - the other underlying APIs/utilities comprise the bulk of the package and are intended to be useable independently. Within Beacon, we sometimes don’t even use the Dataset API unless it makes since for a given data science task.

These underlying APIs/utilities could literally be separate packages, but in the interest of keeping Onda’s “mini-ecosystem” consistent/high quality/well-integrated (and just simplifying development for ourselves) we keep it all in the same package.

What I’m proposing is something that is implemented entirely independent of the file format or dataset organization but IO routines can rely on to make imported data compatible with the larger Julia ecosystem.

If you toss out the Dataset API from Onda.jl, I’d say the package that remains would largely be well-described by this statement :slight_smile:

The point of TimeAxes.jl is that you can arbitrarily define which dimension is the time dimension

This is a good point, and is a current limitation of Onda’s data model - but only because we haven’t had much time or motivation to update it :grin: see require implementations to explicitly support planar LPCM · Issue #94 · beacon-biosignals/Onda.jl · GitHub and multidimensional samples/channels · Issue #95 · beacon-biosignals/Onda.jl · GitHub. It seems to me that composing/restructuring Onda.jl’s Samples on top of TimeAxes.jl could be a easy and nice way for us to knock off those issues :slight_smile:

3 Likes

I was super intrigued when Jake told me on slack that Beacon also uses MNE. I was wondering to what degree it can be integrated, and if the integration (i.e effectively calling functions from MNE on Julia based data types) works well, then is it even justified to build an MEG/EEG analysis package? @ararslan @palday

The two-second answer (which is all the time I have at the moment) is that MNE can be embedded really easily with PyCall. There are a couple of gotchas (e.g. MNE’s Info class is a subclass of dict, which PyCall too aggressively converts to a Julia Dict, which eats the extra methods there, but this is easy to work around), but everything works fairly smoothly.

I think Julia native EEG functionality would be great for a lot of reasons, but it’s very convenient to be able to lean on MNE and the Python EEG ecosystem when a feature isn’t available.

3 Likes

I totally think this needs to happen. I actually have my own patched together local copy that I’ve been meaning to publish.

Creating a special Type has a ton of benefits. For example, I overloaded functions in DSP.jl to correctly change the time axis after filtering and downsampling operations. There’s definitely a place for getting EEG-specific IO code in Julia. I’m relying in MNE for now, but I really hate using Python if I don’t have to (I’ve got the Julia bug hard…).

Someday I’ll publish something. Should we put together an EEG/Julia user group?

1 Like

An EEG/Julia group would be GREAT.

There is so much to do, I am not going to use MNE (never).

Maybe a meeting during JuliaCon? something else?

… I need to start going to JuliaCon.

I’m totally burnt out with these virtual conferences, though.

1 Like

Targeting Julia users would be helpful, but should we also try to reach the broader EEG community? People going to JuliaCon are already probably pretty plugged in, what about AES… or even SfN?

Maybe the first step is just putting a group together, and then we can slowly advertise it and get a critical mass of like-minded people.

I would be happy (even a little elated) to work with someone on the EEG side of things. New stuff is consistently being developed that should make Julia a killer environment for EEG now and even more so in the future.

Personally, I long to be part of a JuliaEEG community.

To me, what you @azraq27 say is the key point: let us put a group together.

Then, we will know that we are actually making JuliaEEG possible, even if we do it really slowly. We will know that we are actually working together, and we can reach out to SfN, INCF, etc.

Let us get to know each other.

1 Like

I haven’t setup a group like this before – what’s the best platform? Form a GitHub organization? Discourse group? Is there a different platform that would be a good home base to keep track of “members” and send out emails and such?

I’d say, lets get a user-base started, and get the discussion going. People can start working on developing an official EEG.jl package, or interface packages (e.g., to MNE), or whatever the community thinks is most important.

Maybe setup a Zoom meeting at some point?

I would love to be part of a JuliaEEG community. While using MNE is somewhat fine, we can probably do a lot better specially by using a lot of the packages already available in julia.
I was beginning to write something to input nicolet files natively but I got busy with other things.

1 Like

I am 100% into a zoom call with you guys.

To build up the group, I think we should just follow the example of Julia QuantEcon

They have it all, a JuliaDiscourse section, a GitHub page for the code, a beautiful page named https://julia.quantecon.org/ to gather all the different resources, etc.

Once we have our meeting, I guess we should assign ourselves some responsibilities to ensure that the momentum continues, maybe annual meetings as checkpoints, virtual parties for the JuliaEEG community (for now), etc.

1 Like

If youre interested I could facilitate this in JuliaNeuroscience

1 Like

I think that would be great.

How JuliaEEG could be integrated in JuliaNeuroscience?

Would you mind having a short meeting with the people that have expressed interest, just to understand how it could work?

I mean, MNE actually supports EEG and other neural data, so a comprehensive environment would be ideal, I guess

I think JuliaNeuroscience sounds like a good place to serve as the home organization for this kind of work!

I’d be happy to meet. Just dm me and we can get something set up.

1 Like