julianeuroscience / neurocore.jl Goto Github PK

Right now there's just CoordinateSystem. The following functions and types still need to be created.

1. A single coordinate point.
2. A labelled set of coordinate points
3. A conversion method between coordinate systems.
4. A coordinate system that interacts with an array's axes.

I'll flesh some of my ideas for this out more in soon, but I'm leaning towards using GeometryBasic PointMeta for coordinate points. It would give us a simple high performance type that could incorporate metadata and be native plotting capabilities with Makie.jl. 3 really just needs a logical method name because conversion between coordinate systems is pretty well documented in the literature (and fairly simple). Incorporating the coordinate system in axes is a lot more complicated and may involve more work outside of this package first.

@JuliaRegistrator register

ColorChannels refers to RGB-type channels, while electrophysiology.jl refers to electrode channels (though only in comments).

It seems like electrophysiology.jl should only refer to electrodes for the sake of clarity.

There are several packages that I think belong in JuliaNeuroscience. Some of these are just ideas and others I've been waiting for NeuroCore.jl to get in place first. All names should be considered suggestions at this point (not final).

• NeuroGraphs: Graph theory/connectome stuff. I have a lot of code already put together for this but just need to finalize the array interface here.
• NeuroSignals: There needs to be a package for processing signals (which are usually time series related). I know there's a strong ERP signal processing community but a lot of the methods are similar to fMRI signal processing. If possible it would be nice to unify this.
• NeuroDatadeps: Interface for neuroscience related datasets a la Datadeps.jl. The difference between this and just using Datadeps.jl would be additional enforcing criteria on how the data is formatted. It would allow users to have some degree of consistency so things like meta analyses would be more straight forward. There are multiple steps to implementing something like this and it would likely take several people to do it right, so if people are interested in this it should probably become a dedicated discussion before it becomes a package.
• NeuroStats: formal methods for statistical analysis of neuroscience data. In addition to implementing neuroscience specific statistical techniques this could act as a binding to packages in JuliaStats.

Is this under active development and what needs to be done here? (I expect a lot :)

General Approach

In the absence of a formal write up (which I will upload shortly before JuliaCon) the strategy for development throughout this org is this: Write the code we need to do neuroscience research and do it well. Any code that ends up being useful to a wider community (e.g., plotting, stats, etc.) may eventually become part of a different ecosystem (e.g., JuliaPlots, JuliaStats, etc.).

From a pure user perspective this means that if code move from this org to another it won't be noticeable. From a developer perspective it means that code developed here might end up somewhere else eventually if it means it will be maintained by a more appropriately focused team of developers. Therefore, we use the commonly used MIT license to make this sort of thing easy and we play nice with our peers.

For example, at the time of writing this I have a substantial PR providing data type (time, space, observation, etc.) methods. Instead of waiting for the entire Julia community to agree upon a standard for referring to time data we can move the code to a broader community once it appears stable and useful. This means some packages may end up simply end up being short scripts that bind a variety of packages together in a useful way (see Makie.jl for an example) or just formal documentation on how to perform analyses with a few convenience functions for learning (see StatisticalRethinking.jl).

The end result should look the same to users, a Julian approach to neuroinformatics.

Public Release

These are things that need to be taken care of before a wider public release of the package can happen.

• Basic types
  • AbstractArray subtype
• Comprehensive testing: This is a core package that I anticipate very few new types being a part of. Therefore, I anticipated code coverage to be crucial and measured accurately by Codecov measures.
  • Type stability: Where appropriate we should ensure that users don't have to worry about NeuroCore.jl causing type stability issues. (Resolved using FieldProperties.jl)
  • Sensible defaults: I don't anticipate many to be implemented. Right now the default is to error unless it's part of a dictionary look-up for the property.
  • User level named dimension manipulation: There is some important user level functionality dedicated to manipulating named dimensions that are important to neuroscience data.
• Documentation:
  • Document all user facing methods
  • Formal documentation manual
  • Readme/introduction with intention/purposes/goals of NeuroCore.jl

File Format Support

I plan on getting the following supported (mostly because I regularly use these):

• NIfTI
  • I will be personally taking care of this one (will be ready very soon after NeuroCore is ready for wide public use)
• CIFTI
  • Requires geometry and graph types. This will come as an extension on NIfTI support
• GIFTI
  • There is limited support exist in GIFTI.jl.
• Some DICOM conversion
  • A lot of this could be accomplished by simply loading DICOMs into a format that's compatible with NeuroCore and then mapping various scanner model's data to properties
• BDF/EDF
  • This exists but we need to either 1) make some changes to the existing packages so that files load into structures that conform NeuroCore or 2) heavily rely on FieldProperties to map NeuroCore properties

Here are some other formats that may be worth supporting but would require someone else to take the lead.

• .vhdr
• .vmrk
• .eeg
• .set
• .fdt
• .mef
• .nwb
• .fif

Type Interfaces

AbstractArray support

We need an AbstractArray subtype with the following features:

1. Flexible metadata storage
2. Named dimensions
3. Indexing by units/keys

This is largely accomplished by AxisIndices.jl. I've been heavily testing it and hope to have it at a point where we can simply perform things like PCA and ICA on types present through this.

Geometry Types

I'm leaning towards using GeometryTypes.jl, which will provide support for plotting with very little effort.

Graph Types

Connectomes and potentially data access patterns.

Plotting and Visualization

The backend for this will likely be all or mostly Makie.jl.

Note that work for this specific objective will start rolling out after March 16th (after VizCon 2). This will ensure that developments in this area are in harmony greater harmony with future directions of Julia's various plotting ecosystems.

• Plot specific recipes for visualizing neuroscience data
• Integration with ImageView.jl/Tinker.jl

Use the new "Extended Documentation" feature for properties.

I have an EEG recording with 20 channels. At the moment, I have no information about the arrangement of these electrodes in physical space. Should the 1:20 dimension of electrodes still fall under SpatialAPI?