A browser-only diffusion-MRI pipeline: drag in a DWI, fit the diffusion tensor, track white-matter streamlines, and save a TRX tractogram. Everything runs client-side (WebAssembly + WebGPU) — no data ever leaves your machine — and the whole app is a static page: no install, no upload, no server.
Live demo: https://rordenlab.github.io/dwi2trx/
- Select input — drag-drop a DWI (a NIfTI + bval + bvec triple, or a folder of DICOMs converted in the browser). You can download sample DICOMs 17_DWI_dir80_AP or sample NIfTI trios 17_DWI_dir80_AP from the web.
- Tensor maps — fit the diffusion tensor and view the principal eigenvector (V1) coloured by direction and modulated by fractional anisotropy (FA). The fit applies a @brainchop/mindgrab brain mask when WebGPU can run it, falling back to an unmasked fit otherwise.
- Streamlines — track white-matter streamlines on the GPU, render them over the FA in a clipped 3D view, and save a
.trxtractogram. Seed/stop FA thresholds, step size, turn angle, and seed density are all adjustable.
Two vector tools sit alongside the pipeline. Show vectors renders the loaded DWI's gradient scheme (bvec/bval) as a NiiVue ball preview — a b0 at the origin and each direction placed at unit(bvec)×√(b/bmax), sized by repeat count and coloured by b-value — so you can eyeball whole- vs half-sphere and single- vs multi-shell coverage. Generate Vectors designs a uniform multi-shell scheme (editable shells, uniformity α, b0-every-N) and exports Siemens DVS, GE tensor DAT (within GE's documented 6–300-volume range), or Philips dti_vectors_input.txt. Its two optimization modes are simultaneous (Winkler), for the strongest whole-scan uniformity and duty-cycle-balanced ordering, and incremental (Caruyer), which preserves construction order so truncated scans retain useful coverage. Optimization runs off the main thread in a Web Worker. Both modes are polarity-balanced (whole-sphere symmetric, for FSL Eddy) and canonically oriented before saving. Because each shell is optimized separately, the directions differ between b-values — Philips FiberTrak requires the same directions for every b-value, so process these acquisitions with an external pipeline. Verify any generated table on your scanner before acquisition.
Needs a recent desktop Chrome or Edge (WebGPU with subgroup support). Or just open the demo and drop in your data.
- qform-only NIfTI — FSL-preprocessed DWI is frequently stored qform-only (
sform_code = 0). dwi2trx and its vendored niimath now derive the voxel→world geometry from the qform when the sform is missing, so the brain-masked fit and the streamlines stay aligned with the image. - Large datasets — the constraint is working memory, not file size. Inputs above ~2 GB are rejected up front (before anything is read) with an explanatory dialog, because JavaScript/WebAssembly need contiguous in-memory arrays. Below that, a gzipped DWI still expands several-fold when decompressed, and tracking then allocates float copies, GPU buffers, readback windows, the TRX, and the 3D mesh on top — so a large DWI (e.g. ~800 MB / 129 volumes) can exhaust browser memory well below any 2 GB file ceiling. The tracker reads streamlines back in bounded windows and retries with smaller batches, and once tracking and TRX serialization succeed the
.trxstays downloadable even if only the 3D preview runs out of memory. (Memory can still run out earlier — during input decompression, tracking, or TRX assembly — which fails the run.) For big data, start with higher Seed/Stop FA thresholds and lower Density to keep the streamline count (and memory) down.
npm install
npm run dev # local dev server
npm run build # static build → dist/
npm run lint # Biome (lint + format check)
npm test # unit + DIPY golden tests (Node 22+)
npm run test:e2e # real-WebGPU browser smoke (local-only; needs a GPU)dev and build first stage mindgrab's wasm into public/brainchop/ (gitignored), so brain masking 404s if you run bare vite instead.
This web page is a lean TypeScript wrapper around composable building blocks. It illustrates how AI-assisted coding can create useful tools by orchestrating proven, modular components. The current implementation is edge-based, with all processing running in the user's web browser. This preserves privacy (no data leaves the user's computer) and scales easily to many users (each provides their own compute). The trade-off is that every stage needs a lightweight, self-contained tool. The interface could also be extended with cloud resources for heavier processing, as illustrated in our full-stack demo.
- NiiVue — WebGPU visualization
- dcm2niix — in-browser DICOM → NIfTI (paper)
- niimath — image processing & tensor fitting (paper)
- @brainchop/mindgrab — mindgrab brain extraction (paper)
- GPUStreamlines — GPU tractography