[ANN] Niivue.jl: Interactive 3D/4D Neuroimaging Visualization

Hello Julia Community,

I created a new package, Niivue.jl, which is a Julia wrapper to Niivue.js, a WebGL-based neuroimaging viewer.

It uses Bonito.jl for communication with JavaScript. Because of this, the viewer renders directly within Julia-native environments like Pluto and Jupyter notebooks, the VS Code plot pane, the browser, or a standalone Electron window.

Example

It is possible to mix filepaths and in-memory arrays in the volumes list:

using Niivue

random_array = rand(50,50,50);

volumes = [
    "https://niivue.github.io/niivue-demo-images/mni152.nii.gz",
    random_array
];

nv = niivue(volumes)
nv.colorbar = true

Key Features

  • Visualization: Display a large number of different neuroimaging file types (from URLs or local paths), 3D/4D Julia arrays, and mesh formats (e.g., GIfTI, VTK) simultaneously in the same viewer instance.
  • Programming: Modify the viewer layout, settings, colormaps, and displayed volumes with Julia code. Bidirectional communication is also possible (e.g., reacting to user clicks/ voxel location in Julia).

Package Design

Architecturally, Niivue.jl is a thin wrapper built on Bonito.jl. Bonito.jl functions as the reactive web framework, managing the web server, WebSocket connections, and data synchronization between the Julia backend and the JavaScript-based Niivue library.

  • Julia can execute arbitrary JavaScript in the frontend (e.g., Niivue.Bonito.evaljs).
  • Julia can receive values from JavaScript with Niivue.Bonito.evaljs_value.

Package Development and Questions

The package is still in its early development. Part of the NiiVue API is not yet captured with “syntactic sugar” and still needs JavaScript. I’m not set on the style of the syntactic sugar yet.
Since it is executing JavaScript code, it might make sense to use a macro syntax instead, maybe

@nv colorbar = true

I’m interested to hear your thoughts on syntactic sugar. I’m also not 100% sure if the thin wrapper approach, which directly gives access to the JavaScript API makes sense, or if individual wrapper function for each method and property of the js objects makes more sense. I also want to keep the package maintainable with little time.

The repository (GitHub - korbinian90/Niivue.jl) is not a registered package yet. I’m making this “pre-announcement” to gauge interest and gather feedback on the core design before making a public release. This is a personal hobby project with currently no funding, so development is paused from time to time.

4 Likes