diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index ccc89f3..3545647 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -1,14 +1,18 @@
name: Deploy website
-on: [push, pull_request]
+on:
+ push:
+ branches: [main]
+ pull_request:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
permissions:
- contents: write
-
+ contents: read
+ pages: write
+ id-token: write
jobs:
build:
runs-on: ubuntu-latest
@@ -31,11 +35,19 @@ jobs:
run: |
make html
- name: Upload site
- uses: actions/upload-artifact@v4
- with:
- name: site
- path: build/html
- - name: Publish docs to Github Pages
- uses: JamesIves/github-pages-deploy-action@releases/v4
+ uses: actions/upload-pages-artifact@v4
with:
- folder: build/html
+ path: _build/html
+
+
+ deploy:
+ if: github.event_name != 'pull_request'
+ needs: build
+ runs-on: ubuntu-latest
+ environment:
+ name: github-pages
+ url: ${{ steps.deployment.outputs.page_url }}
+ steps:
+ - name: Deploy to GitHub Pages
+ id: deployment
+ uses: actions/deploy-pages@v5
diff --git a/.gitignore b/.gitignore
index 62b3d8f..c3b01b3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
.DS_Store
-build/*
\ No newline at end of file
+_build/*
\ No newline at end of file
diff --git a/Makefile b/Makefile
index d0c3cbf..92dd33a 100644
--- a/Makefile
+++ b/Makefile
@@ -6,7 +6,7 @@
SPHINXOPTS ?=
SPHINXBUILD ?= sphinx-build
SOURCEDIR = source
-BUILDDIR = build
+BUILDDIR = _build
# Put it first so that "make" without argument is like "make help".
help:
diff --git a/README.md b/README.md
index b81b314..e198150 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,56 @@
# tee-ar-ex.github.io
-A website for the TRX file format.
\ No newline at end of file
+A website for the TRX file format, built with Sphinx and the MyST parser.
+
+## Building the documentation
+
+### Prerequisites
+
+- Python 3.9+
+
+### Local build
+
+1. Clone the repository:
+
+ ```bash
+ git clone https://github.com/tee-ar-ex/tee-ar-ex.github.io.git
+ cd tee-ar-ex.github.io
+ ```
+
+2. Create and activate a virtual environment (optional but recommended):
+
+ ```bash
+ python -m venv venv
+ source venv/bin/activate # Windows: venv\Scripts\activate
+ ```
+
+3. Install dependencies:
+
+ ```bash
+ pip install -r requirements.txt
+ ```
+
+4. Build the documentation:
+
+ ```bash
+ make html
+ ```
+
+5. Open `_build/html/index.html` in your browser.
+
+### Development workflow
+
+To rebuild automatically while editing:
+
+```bash
+sphinx-autobuild source _build/html
+```
+
+Note: `sphinx-autobuild` needs to be installed separately
+(`pip install sphinx-autobuild`).
+
+### Deployment
+
+The site is automatically deployed to GitHub Pages via GitHub Actions on
+pushes to `main`. Pull requests trigger a build to validate changes without
+deploying.
diff --git a/requirements.txt b/requirements.txt
index ba872ef..a62d34c 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1,3 +1,5 @@
sphinx
myst-parser
-pydata_sphinx_theme
\ No newline at end of file
+pydata_sphinx_theme
+sphinxcontrib-bibtex
+sphinx-design
diff --git a/source/_templates/implementation-links.html b/source/_templates/implementation-links.html
new file mode 100644
index 0000000..2b843ac
--- /dev/null
+++ b/source/_templates/implementation-links.html
@@ -0,0 +1,11 @@
+
diff --git a/source/bib.md b/source/bib.md
new file mode 100644
index 0000000..3df293c
--- /dev/null
+++ b/source/bib.md
@@ -0,0 +1,9 @@
+# Bibliography
+
+
+```{eval-rst}
+
+.. bibliography::
+ :all:
+
+```
\ No newline at end of file
diff --git a/source/capsule.md b/source/capsule.md
deleted file mode 100644
index ef05e87..0000000
--- a/source/capsule.md
+++ /dev/null
@@ -1 +0,0 @@
-
\ No newline at end of file
diff --git a/source/concepts.md b/source/concepts.md
new file mode 100644
index 0000000..7ccc685
--- /dev/null
+++ b/source/concepts.md
@@ -0,0 +1,98 @@
+# Core Concepts
+
+This page explains how the TRX format represents tractography data on disk and
+in memory.
+
+## The TRX format
+
+A TRX file is a ZIP archive (or on-disk directory) whose layout directly
+encodes its data model:
+
+- `header.json` — spatial metadata
+- `positions..` — all streamline vertices in a single flat array
+- `offsets.` — prefix-sum index from streamlines into positions
+- `dpv/.` — per-vertex metadata arrays
+- `dps/.` — per-streamline metadata arrays
+- `groups/.uint32` — named index sets of streamlines
+- `dpg//.` — per-group metadata arrays
+
+Coordinates are stored in **RAS+ world space** (millimeters), matching the
+convention used by MRtrix3 `.tck` and NIfTI qform outputs.
+
+## Positions array
+
+All streamline vertices are stored in a single flat matrix of shape
+`(NB_VERTICES, 3)`. Keeping all vertices contiguous enables efficient memory
+mapping and avoids per-streamline allocations.
+
+## Offsets and the sentinel
+
+`offsets` is a prefix-sum index of length `NB_STREAMLINES + 1`. Element *i* is
+the offset in `positions` of the first vertex of streamline *i*. The final
+element is a **sentinel** equal to `NB_VERTICES`, which makes length
+computation trivial without special-casing the last streamline:
+
+```
+length_i = offsets[i + 1] - offsets[i]
+```
+
+This design avoids per-streamline allocations and makes slicing the global
+positions array fast and uniform.
+
+## Data per vertex (DPV)
+
+A DPV array stores one value per vertex in `positions`. It has shape
+`(NB_VERTICES, 1)` for scalar fields or `(NB_VERTICES, N)` for vector-valued
+fields. Typical uses:
+
+- FA values along the tract
+- Per-point RGB colors
+- Confidence or weight measures per vertex
+
+DPV arrays live under `dpv/` and are memory-mapped in the same way as
+`positions`.
+
+## Data per streamline (DPS)
+
+A DPS array stores one value per streamline. It has shape
+`(NB_STREAMLINES, 1)` or `(NB_STREAMLINES, N)`. Typical uses:
+
+- Mean FA or average curvature per tract
+- Per-streamline cluster labels
+- Tractography algorithm weights
+
+DPS arrays live under `dps/` and are loaded as typed matrix fields. If the
+on-disk dtype differs from the requested typed reader dtype, values are
+converted during load.
+
+## Groups
+
+A group is a named list of streamline indices stored as a `uint32` array under
+`groups/`. Groups enable sparse, overlapping labeling: a streamline can belong
+to multiple groups, and groups can have different sizes. Typical uses:
+
+- Bundle labels (`CST_L`, `CC`, `SLF_R`, ...)
+- Cluster assignments from QuickBundles or similar algorithms
+- Connectivity subsets (streamlines connecting two ROIs)
+
+## Data per group (DPG)
+
+DPG attaches metadata to a group. Each group folder `dpg//` can contain
+any number of scalar or vector arrays. Typical uses:
+
+- Mean FA across the bundle
+- Per-bundle display color
+- Volume or surface-area estimates
+
+## Header
+
+`header.json` stores:
+
+- `VOXEL_TO_RASMM` — 4x4 affine mapping voxel indices to RAS+ world
+ coordinates (mm)
+- `DIMENSIONS` — reference image grid dimensions as three `uint16` values
+- `NB_STREAMLINES` — number of streamlines (`uint32`)
+- `NB_VERTICES` — total number of vertices across all streamlines (`uint64`)
+
+The header is primarily for human readability and downstream compatibility. The
+authoritative sizes come from the array dimensions themselves.
diff --git a/source/conf.py b/source/conf.py
index 55361e7..0786e5a 100644
--- a/source/conf.py
+++ b/source/conf.py
@@ -6,17 +6,35 @@
# -- Project information -----------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
-project = 'tee-ar-ex'
-copyright = '2026, TRX developers'
-author = 'TRX developers'
+from datetime import datetime as dt
+
+project = 'TRX'
+copyright = f'2021-{dt.now().year}, The TRX developers'
+author = 'The TRX developers'
# -- General configuration ---------------------------------------------------
# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
extensions = [
"myst_parser",
+ "sphinxcontrib.bibtex",
+ "sphinx_design",
]
+bibtex_bibfiles = ['references.bib']
+bibtex_default_style = 'plain'
+bibtex_reference_style = 'author_year'
+
+
+myst_enable_extensions = [
+ "colon_fence",
+ "deflist",
+ "fieldlist",
+ "html_image",
+ "tasklist",
+]
+myst_heading_anchors = 3
+
templates_path = ['_templates']
exclude_patterns = ['.DS_Store']
source_suffix = ['.rst', '.md']
@@ -32,9 +50,15 @@
html_logo = "_static/logo.png"
html_theme_options = {
- "secondary_sidebar_items": [],
+ "secondary_sidebar_items": ["page-toc", "edit-this-page", "sourcelink"],
"use_edit_page_button": True,
"icon_links": [
+ {
+ "name": "Home",
+ "url": "index.html",
+ "icon": "fa-solid fa-home",
+ "attributes": {"target": "_self"},
+ },
{
"name": "GitHub",
"url": "https://github.com/tee-ar-ex/",
@@ -49,4 +73,8 @@
"github_repo": "tee-ar-ex.github.io",
"github_version": "main",
"doc_path": "source",
+}
+
+html_sidebars = {
+ "**": ["sidebar-nav-bs.html", "implementation-links.html"],
}
\ No newline at end of file
diff --git a/source/design.md b/source/design.md
new file mode 100644
index 0000000..3a957df
--- /dev/null
+++ b/source/design.md
@@ -0,0 +1,140 @@
+# Design Rationale
+
+This page explains the motivation and design decisions behind the TRX file
+format. The TRX emerged from a
+[community discussion initiated in 2020](https://github.com/nipy/nibabel/issues/942)
+to address long-standing limitations in existing tractography file formats.
+
+## Motivation
+
+File formats that store the results of computational tractography were
+traditionally developed within specific software packages. While this approach
+facilitated many applications, it also generated insularity and limited
+standardization. As tractography datasets grew in size and complexity, the need
+for a community-driven standard became clear.
+
+## Limitations of existing formats
+
+The existing tractography file formats have several limitations:
+
+- **Lack of community-based development.** Formats were tied to specific
+ toolboxes rather than developed through community consensus.
+- **Lack of efficiency in I/O and storage.** Many formats do not support
+ efficient memory mapping or compression.
+- **Limited partial loading.** Most formats require loading all streamlines
+ at once, making it difficult to work with subsets.
+- **Non-standard spatial transformations.** For example, the TRK format uses a
+ complex and non-standard spatial mapping based on voxel corners rather than
+ world coordinates.
+
+## Design goals
+
+The community identified several key features for a new tractography format:
+
+- **Community-based development.** The format should be developed by the
+ community, not tied to any single toolbox.
+- **Cross-platform compatibility.** The format should work across Python, C++,
+ JavaScript, and other programming languages.
+- **Simplicity.** The format should be easy to implement in any language
+ without relying on external tooling. As few elements as possible should be
+ required, and conventions should be explicit.
+- **I/O and storage efficiency.** The format should support memory mapping and
+ allow direct access to data without conversion. IEEE floating-point
+ little-endian storage is preferred since it is the native format on all
+ commonly used CPUs.
+- **Independence.** The format should be self-contained and not require external
+ references. Storing streamlines in world coordinates (RAS+ millimeters)
+ eliminates the need for a user-supplied reference image.
+- **Extensibility.** The format should allow additional metadata to be stored
+ and for new fields to become part of the standard as their use becomes
+ commonplace.
+- **Seamless spatial transformation.** Intuitive metadata handling at any scale
+ — vertices, streamlines, and bundles.
+
+## Streamline storage trade-offs
+
+A key design decision is how to store streamlines, which are "jagged arrays",
+i.e., each streamline has a different number of vertices.
+
+**Approaches considered:**
+
+- **VTK-style** (explicit vertex indexing) — allows vertex sharing, efficient
+ for triangulated meshes, but leads to much larger files for streamlines where
+ each vertex is used once.
+- **Single array with separators** (TCK, TRK, PDB style) — stores vertex
+ positions and end-of-streamline markers in one array. Good for writing during
+ streamline creation, but less efficient for random access.
+- **Separate arrays for positions and offsets** (TRX approach) — stores vertex
+ positions in one array and a prefix-sum index in another. This enables
+ efficient memory mapping, random access, and block reads. Each data type
+ (float positions, integer offsets) can be read with a single block read.
+
+The TRX format adopts the **positions + offsets** approach because it provides:
+
+- Memory-mapped access to arbitrary streamline subsets
+- Efficient random access without reading the entire file
+- Clean separation of data types for SIMD and GPU compatibility
+
+**Vertex storage layout:**
+
+- **Array of Structures (AoS):** `x0, y0, z0, x1, y1, z1, ...` — intuitive,
+ matches how vertices are sent to GPUs.
+- **Structure of Arrays (SoA):** `x0, x1, ..., y0, y1, ..., z0, z1, ...` —
+ can benefit from CPU-based SIMD programming.
+
+TRX uses AoS layout for positions, matching the convention used by MRtrix3
+`.tck` and OpenGL polyline rendering.
+
+## Metadata hierarchy
+
+TRX organizes metadata into four levels:
+
+- **Per-vertex (DPV):** scalar or vector values at each streamline vertex
+ (e.g., FA along a tract, RGB colors).
+- **Per-streamline (DPS):** one value per streamline (e.g., mean FA, cluster
+ labels, algorithm weights).
+- **Groups:** named index sets of streamlines enabling sparse, overlapping
+ labeling (e.g., bundle assignments, connectivity subsets).
+- **Per-group (DPG):** metadata attached to groups (e.g., mean FA across a
+ bundle, display colors, volume estimates).
+
+This hierarchy covers the metadata needs of existing formats (TRK's
+per-vertex/per-streamline values, TCK's bundle labels) while adding the
+flexibility of group-level properties that no predecessor format provided.
+
+## Spatial coordinates
+
+TRX stores streamline vertices in **RAS+ world coordinates** (millimeters)
+rather than voxel space. This decision was motivated by:
+
+- **Independence from external data.** The file is self-contained — no
+ reference image is needed to interpret vertex positions.
+- **Consistency with MRtrix3.** The `.tck` format already uses world
+ coordinates, and TRX maintains compatibility.
+- **Reduced errors.** Requiring a user-supplied reference image to convert
+ between voxel and world coordinates creates opportunities for mistakes.
+
+The `header.json` includes a `VOXEL_TO_RASMM` affine for tools that need to
+convert to voxel space, but this field is optional to use — the data on disk
+is already in world coordinates.
+
+## Compression
+
+TRX supports optional ZIP compression:
+
+- **Whole-archive compression** (`ZIP_DEFLATE`) is simple and widely supported.
+- **Per-array compression** is possible within the ZIP structure, allowing
+ random access to uncompressed arrays while compressing others.
+- **Byte shuffling** before compression can improve ratios for structured data
+ like offset arrays, where neighboring values share most-significant bytes.
+
+The format does not mandate a specific compression strategy, leaving this as
+an implementation choice.
+
+In addition, a generic compression approach can be combined with
+tractography-specific compression approaches, such as linearization
+{cite:p}`Rheault2017`.
+
+Taken together, TRX provides multiple options to save storage space, that can
+also be combined: down-casting, generic compression algorithms, and
+tractography-specific compression.
\ No newline at end of file
diff --git a/source/history.md b/source/history.md
new file mode 100644
index 0000000..31d9b85
--- /dev/null
+++ b/source/history.md
@@ -0,0 +1,66 @@
+# Timeline of TRX
+
+## Origins
+
+File formats that store the results of computational tractography were
+traditionally developed within specific software packages. This approach has
+facilitated a myriad of applications, but this development approach has also
+generated insularity within software packages, and has limited standardization.
+Moreover, because tractography file formats were developed to solve immediate
+challenges, only a limited breadth of applications within a single software
+package was envisioned, sometimes also neglecting computational performance.
+
+Given the growing interest in tractography methods and applications, and the
+increasing size and complexity of datasets, a community-driven standardization
+of tractography have become a priority
+{cite:p}`Legarreta2026Gigascience, Descoteaux2025Millenium`.
+
+The TRX format emerged in 2020
+following [this discussion](https://github.com/nipy/nibabel/issues/942) on the nibabel
+repository, where the tractography community began conversations about a shared
+data format.
+
+## Community adoption and dissemination
+
+TRX has been developed and advocated by researchers across many institutions
+and geographies. The format has been presented at conferences, workshops, and
+through technical developments.
+
+### Conferences and workshops
+
+- **OHBM 2021** (online) — initial presentation of the format
+- **OHBM 2022** (Glasgow) — in-person poster presentation
+- **OHBM 2023** — progress presented at the Open Science Room
+- **Tract Anat Retreat, Corsica, 2024** — presented and discussed at length
+- **DIPY online workshops, 2025 and 2026** — presented to trainees
+- **BRAIN CONNECTS gathering, Austin TX, 2025** — presented to the project
+
+### Institutional adoption
+
+- The NIH-funded **BIDS Connectivity project** incorporated TRX into its
+ proposal for extensions of BIDS to represent brain tractography.
+- The **International Society for Tractography Standardization Unit** has been
+ carrying this work forward.
+
+### Community note
+
+For a community service project that is not currently funded by any agency, the
+community around TRX has been exceptionally active in disseminating knowledge
+about the format. Technical developments to ease the burden of TRX adoption
+have also been remarkable, with the format now supported by many platforms and
+languages, as described in the [Software](software.md) page.
+
+### Adoption of TRX in BIDS
+
+The [Brain Imaging Data Structure (BIDS)](https://bids.neuroimaging.io/) is a
+widely-used standard for organizing and describing data collected during
+neuroimaging experiments. As BIDS has evolved, it has shifted from a standard
+that covers only experimental data to one that also covers the outputs of
+processing pipelines.
+
+The proposal for standardization of tractography outputs (or, in BIDS jargon,
+"tractography derivatives") currently being discussed as
+[BIDS Enhancement Proposal \#46](https://github.com/bids-standard/bids-specification/pull/2333)
+focuses on making TRX the only file format that will be accepted by the
+standard. This means that standards-compliant experiments and projects will
+eventually need to adopt TRX.
diff --git a/source/index.md b/source/index.md
index 83f2fe7..fa3b24a 100644
--- a/source/index.md
+++ b/source/index.md
@@ -1,53 +1,49 @@
-# TRX: A community-oriented file format for tractography
-
-### Rationale
-
-File formats that store the results of computational tractography were typically
-developed within specific software packages. This approach has facilitated a
-myriad of applications, but this development approach has also generated
-insularity within software packages, and has limited standardization. Moreover,
-because tractography file formats were developed to solve immediate challenges,
-only a limited breadth of applications within a single software package was
-envisioned, sometimes also neglecting computational performance. Given the
-growing interest in tractography methods and applications, and the increasing
-size and complexity of datasets, a community-driven standardization of
-tractography have become a priority. To address these challenges, our community
-initiated a discussion to design a new file format and agreed to participate in
-its conception, development, and, if successful, its adoption.
-
-The goal of TRX is to become the standard amongst tractography file formats. As
-with other file formats like NIfTI, we believe that TRX will serve the
-community well and the growing computational needs of our field. We encourage
-community members to consider early contributions to our proposal so as to
-ensure the new standard will cover the needs of the wider audience of software
-developers, toolboxes, and scientists. Our long-term plan is to integrate TRX
-within the [Brain Imaging Data Structure (BIDS)](https://bids.neuroimaging.io/)
-ecosystem.
-
-## Implementations
+---
+bibliography:
+ - references.bib
+---
-[*Python*](https://github.com/tee-ar-ex/trx-python)
-
-[*C++*](https://github.com/tee-ar-ex/trx-cpp)
+# TRX: A community-oriented file format for tractography
-[*Rust*](https://github.com/tee-ar-ex/trx-rs)
+Welcome to the documentation of the TRX file format (pronounced "tee-ar-ex" or
+"tracks").
-[*Javascript*](https://github.com/tee-ar-ex/trx-javascript)
+The goal of TRX is to become the standard file format. As with other file
+formats like NIfTI, we believe that TRX will serve the community well and the
+growing computational needs of our field. We encourage community members to
+consider early contributions to our proposal so as to ensure the new standard
+will cover the needs of the wider audience of software developers, toolboxes,
+and scientists. Our long-term plan is to integrate TRX within the [Brain
+Imaging Data Structure (BIDS)](https://bids.neuroimaging.io/) ecosystem
+{cite:p}`Gorgolewski2016BIDS`.
-[*Pascal*](https://github.com/tee-ar-ex/trx-pascal)
+````{dropdown} Concepts & Specification
-```{note}
+```{toctree}
+concepts
+specification
+```
+````
-The TRX file-format started following [this discussion](https://github.com/nipy/nibabel/issues/942)
+````{dropdown} Design & History
+```{toctree}
+design
+history
```
+````
+````{dropdown} Software
-```{eval-rst}
+```{toctree}
+software
+```
+````
-.. toctree::
- :maxdepth: 2
- :caption: Contents:
+````{dropdown} Bibliography
-```
\ No newline at end of file
+```{toctree}
+bib
+```
+````
\ No newline at end of file
diff --git a/source/references.bib b/source/references.bib
new file mode 100644
index 0000000..d83b158
--- /dev/null
+++ b/source/references.bib
@@ -0,0 +1,509 @@
+@ARTICLE{Rheault2017,
+ title = "Visualization, interaction and tractometry: Dealing with millions
+ of streamlines from diffusion {MRI} tractography",
+ author = "Rheault, Francois and Houde, Jean-Christophe and Descoteaux,
+ Maxime",
+ journal = "Front. Neuroinform.",
+ publisher = "Frontiers Media SA",
+ volume = 11,
+ pages = 42,
+ abstract = "Recently proposed tractography and connectomics approaches often
+ require a very large number of streamlines, in the order of
+ millions. Generating, storing and interacting with these datasets
+ is currently quite difficult, since they require a lot of space
+ in memory and processing time. Compression is a common approach
+ to reduce data size. Recently such an approach has been proposed
+ consisting in removing collinear points in the streamlines.
+ Removing points from streamlines results in files that cannot be
+ robustly post-processed and interacted with existing tools, which
+ are for the most part point-based. The aim of this work is to
+ improve visualization, interaction and tractometry algorithms to
+ robustly handle compressed tractography datasets. Our proposed
+ improvements are threefold: (i) An efficient loading procedure to
+ improve visualization (reduce memory usage up to 95\% for a 0.2
+ mm step size); (ii) interaction techniques robust to compressed
+ tractograms; (iii) tractometry techniques robust to compressed
+ tractograms to eliminate biased in tract-based statistics. The
+ present work demonstrates the need of correctly handling
+ compressed streamlines to avoid biases in future tractometry and
+ connectomics studies.",
+ month = jun,
+ year = 2017,
+ keywords = "MI-Brain; compression; connectomics; diffusion MRI;
+ linearization; streamlines; tractography; tractometry"
+}
+
+
+@ARTICLE{Gorgolewski2016BIDS,
+ title = "The brain imaging data structure, a format for organizing and
+ describing outputs of neuroimaging experiments",
+ author = "Gorgolewski, Krzysztof J and Auer, Tibor and Calhoun, Vince D and
+ Cameron Craddock, R and Das, Samir and Duff, Eugene P and
+ Flandin, Guillaume and Ghosh, Satrajit S and Glatard, Tristan and
+ Halchenko, Yaroslav O and Handwerker, Daniel A and Hanke, Michael
+ and Keator, David and Li, Xiangrui and Michael, Zachary and
+ Maumet, Camille and Nolan Nichols, B and Nichols, Thomas E and
+ Pellman, John and Poline, Jean-Baptiste and Rokem, Ariel and
+ Schaefer, Gunnar and Sochat, Vanessa and Triplett, William and
+ Turner, Jessica A and Varoquaux, Gaël and Poldrack, Russell A",
+ journal = "Scientific data",
+ publisher = "Nature Publishing Group",
+ volume = 3,
+ number = 1,
+ pages = "1--9",
+ abstract = "The development of magnetic resonance imaging (MRI) techniques
+ has defined modern neuroimaging. Since its inception, tens of
+ thousands of studies using techniques such as functional MRI and
+ diffusion weighted imaging have allowed for the non-invasive
+ study of the brain. Despite the fact that MRI is routinely used
+ to obtain data for neuroscience research, there has been no
+ widely adopted standard for organizing and describing the data
+ collected in an imaging experiment. This renders sharing and
+ reusing data (within or between labs) difficult if not impossible
+ and unnecessarily complicates the application of automatic
+ pipelines and quality assurance protocols. To solve this problem,
+ we have developed the Brain Imaging Data Structure (BIDS), a
+ standard for organizing and describing MRI datasets. The BIDS
+ standard uses file formats compatible with existing software,
+ unifies the majority of practices already …",
+ month = jun,
+ year = 2016
+}
+
+
+@ARTICLE{Descoteaux2025Millenium,
+ title = "Millennium Pathways for Tractography: 40 grand challenges to
+ shape the future of tractography",
+ author = "Descoteaux, Maxime and Schilling, Kurt G and Aydogan, Dogu
+ Baran and Beaulieu, Christian and Borra, Elena and
+ Chamberland, Maxime and Daducci, Alessandro and Luca, Alberto
+ De and Dell'Acqua, Flavio and Dubois, Jessica and Dyrby, Tim
+ B and Farquharson, Shawna and Forkel, Stephanie and Froeling,
+ Martijn and Griffa, Alessandra and Grotheer, Mareike and
+ Guevara, Pamela and Haber, Suzanne N and Jangir, Vinod Kumar
+ and Leemans, Alexander and Lefebvre, Joël and Lin, Ching-Po
+ and Little, Graham and Zac Lo, Chun-Yi and Maffei, Chiara and
+ Mayberg, Helen S and McNab, Jennifer A and Mukherjee, Pratik
+ and O'Donnell, Lauren J and Parent, Martin and Pierpaoli,
+ Carlo and Rheault, Francois and Rockland, Kathleen S and
+ Roebroeck, Alard and Rokem, Ariel and Rushmore, R Jarrett and
+ Sarubbo, Silvio and Schiavi, Simona and Sotiropoulos,
+ Stamatios N and Szczupak, Diego and de Schotten, Michel
+ Thiebaut and Tournier, J-Donald and Vergani, Francesco and
+ Yuan-Mou Yang, Joseph and Zhang, Fan and Jones, Derek and
+ Petit, Laurent",
+ journal = "ArXiv",
+ abstract = "In the spirit of the historic Millennium Prize Problems that
+ heralded a new era for mathematics, the newly formed
+ International Society for Tractography (IST) has launched the
+ Millennium Pathways for Tractography, a community-driven
+ roadmap designed to shape the future of the field. Conceived
+ during the inaugural Tract-Anat Retreat, this initiative
+ reflects a collective vision for advancing tractography over
+ the coming decade and beyond. The roadmap consists of 40
+ grand challenges, developed by international experts and
+ organized into seven categories spanning three overarching
+ themes: neuroanatomy, tractography methods, and clinical
+ applications. By defining shared short-, medium-, and
+ long-term goals, these pathways provide a structured
+ framework to confront fundamental limitations, promote
+ rigorous validation, and accelerate the translation of
+ tractography into a robust tool for neuroscience and
+ medicine. Ultimately, the Millennium Pathways aim to guide
+ and inspire future research and collaboration, ensuring the
+ continued scientific and clinical relevance of tractography
+ well into the future.",
+ month = sep,
+ year = 2025,
+ archivePrefix = "arXiv",
+ primaryClass = "physics.med-ph",
+ language = "en"
+}
+
+
+@ARTICLE{Norton2017-yz,
+ title = "{SlicerDMRI}: Open source diffusion {MRI} software for brain
+ cancer research",
+ author = "Norton, Isaiah and Essayed, Walid Ibn and Zhang, Fan and Pujol,
+ Sonia and Yarmarkovich, Alex and Golby, Alexandra J and
+ Kindlmann, Gordon and Wassermann, Demian and Estepar, Raul San
+ Jose and Rathi, Yogesh and Pieper, Steve and Kikinis, Ron and
+ Johnson, Hans J and Westin, Carl-Fredrik and O'Donnell, Lauren J",
+ journal = "Cancer Res.",
+ publisher = "American Association for Cancer Research (AACR)",
+ volume = 77,
+ number = 21,
+ pages = "e101--e103",
+ abstract = "Diffusion MRI (dMRI) is the only noninvasive method for mapping
+ white matter connections in the brain. We describe SlicerDMRI, a
+ software suite that enables visualization and analysis of dMRI
+ for neuroscientific studies and patient-specific anatomic
+ assessment. SlicerDMRI has been successfully applied in multiple
+ studies of the human brain in health and disease, and here, we
+ especially focus on its cancer research applications. As an
+ extension module of the 3D Slicer medical image computing
+ platform, the SlicerDMRI suite enables dMRI analysis in a
+ clinically relevant multimodal imaging workflow. Core SlicerDMRI
+ functionality includes diffusion tensor estimation, white matter
+ tractography with single and multi-fiber models, and dMRI
+ quantification. SlicerDMRI supports clinical DICOM and research
+ file formats, is open-source and cross-platform, and can be
+ installed as an extension to 3D Slicer (www.slicer.org). Cancer
+ Res; 77(21); e101-3. ©2017 AACR.",
+ month = nov,
+ year = 2017,
+ language = "en",
+ DOI = "https://doi.org/10.1158/0008-5472.CAN-17-0332",
+}
+
+
+@ARTICLE{Rorden2025-zq,
+ title = "Surfice: visualizing neuroimaging meshes, tractography
+ streamlines and connectomes",
+ author = "Rorden, Christopher",
+ journal = "Nat. Methods",
+ publisher = "Springer Science and Business Media LLC",
+ volume = 22,
+ number = 8,
+ pages = "1615--1616",
+ month = aug,
+ year = 2025,
+ language = "en",
+ DOI = "https://doi.org/10.1038/s41592-025-02764-6"
+}
+
+
+@ARTICLE{Aydogan2021-ug,
+ title = "Parallel transport tractography",
+ author = "Aydogan, Dogu Baran and Shi, Yonggang",
+ journal = "IEEE Trans. Med. Imaging",
+ publisher = "Institute of Electrical and Electronics Engineers (IEEE)",
+ volume = 40,
+ number = 2,
+ pages = "635--647",
+ abstract = "Tractography is an important technique that allows the in vivo
+ reconstruction of structural connections in the brain using
+ diffusion MRI. Although tracking algorithms have improved during
+ the last two decades, results of validation studies and
+ international challenges warn about the reliability of
+ tractography and point out the need for improved algorithms. In
+ propagation-based tracking, connections have traditionally been
+ modeled as piece-wise linear segments. In this work, we propose a
+ novel propagation-based tracker that is capable of generating
+ geometrically smooth ( C1 ) curves using parallel transport
+ frames. Notably, our approach does not increase the complexity of
+ the propagation problem that remains two-dimensional. Moreover,
+ our tracker has a novel mechanism to reduce noise related
+ propagation errors by incorporating topographic regularity of
+ connections, a neuroanatomic property of many brain pathways. We
+ ran extensive experiments and compared our approach against
+ deterministic and other probabilistic algorithms. Our experiments
+ on FiberCup and ISMRM 2015 challenge datasets as well as on 56
+ subjects of the Human Connectome Project show highly promising
+ results both visually and quantitatively. Open-source
+ implementations of the algorithm are shared publicly.",
+ month = feb,
+ year = 2021,
+ language = "en",
+ DOI = "https://doi.org/10.1109/tmi.2020.3034038"
+}
+
+
+@ARTICLE{Hayashi2024-zm,
+ title = "brainlife.io: a decentralized and open-source cloud platform to
+ support neuroscience research",
+ author = "Hayashi, Soichi and Caron, Bradley A and Heinsfeld, Anibal Sólon
+ and Vinci-Booher, Sophia and McPherson, Brent and Bullock, Daniel
+ N and Bertò, Giulia and Niso, Guiomar and Hanekamp, Sandra and
+ Levitas, Daniel and Ray, Kimberly and MacKenzie, Anne and Avesani,
+ Paolo and Kitchell, Lindsey and Leong, Josiah K and
+ Nascimento-Silva, Filipi and Koudoro, Serge and Willis, Hanna and
+ Jolly, Jasleen K and Pisner, Derek and Zuidema, Taylor R and
+ Kurzawski, Jan W and Mikellidou, Kyriaki and Bussalb, Aurore and
+ Chaumon, Maximilien and George, Nathalie and Rorden, Christopher
+ and Victory, Conner and Bhatia, Dheeraj and Aydogan, Dogu Baran
+ and Yeh, Fang-Cheng F and Delogu, Franco and Guaje, Javier and
+ Veraart, Jelle and Fischer, Jeremy and Faskowitz, Joshua and
+ Fabrega, Ricardo and Hunt, David and McKee, Shawn and Brown, Shawn
+ T and Heyman, Stephanie and Iacovella, Vittorio and Mejia, Amanda
+ F and Marinazzo, Daniele and Craddock, R Cameron and Olivetti,
+ Emanuale and Hanson, Jamie L and Garyfallidis, Eleftherios and
+ Stanzione, Dan and Carson, James and Henschel, Robert and Hancock,
+ David Y and Stewart, Craig A and Schnyer, David and Eke, Damian O
+ and Poldrack, Russell A and Bollmann, Steffen and Stewart, Ashley
+ and Bridge, Holly and Sani, Ilaria and Freiwald, Winrich A and
+ Puce, Aina and Port, Nicholas L and Pestilli, Franco",
+ journal = "Nat. Methods",
+ volume = 21,
+ number = 5,
+ pages = "809--813",
+ abstract = "Neuroscience is advancing standardization and tool development to
+ support rigor and transparency. Consequently, data pipeline
+ complexity has increased, hindering FAIR (findable, accessible,
+ interoperable and reusable) access. brainlife.io was developed to
+ democratize neuroimaging research. The platform provides data
+ standardization, management, visualization and processing and
+ automatically tracks the provenance history of thousands of data
+ objects. Here, brainlife.io is described and evaluated for
+ validity, reliability, reproducibility, replicability and
+ scientific utility using four data modalities and 3,200
+ participants.",
+ month = may,
+ year = 2024,
+ language = "en",
+ DOI = "https://doi.org/10.1038/s41592-024-02237-2"
+}
+
+
+@ARTICLE{Cieslak2021-ic,
+ title = "{QSIPrep}: an integrative platform for preprocessing and
+ reconstructing diffusion {MRI} data",
+ author = "Cieslak, Matthew and Cook, Philip A and He, Xiaosong and Yeh,
+ Fang-Cheng and Dhollander, Thijs and Adebimpe, Azeez and Aguirre,
+ Geoffrey K and Bassett, Danielle S and Betzel, Richard F and
+ Bourque, Josiane and Cabral, Laura M and Davatzikos, Christos and
+ Detre, John A and Earl, Eric and Elliott, Mark A and Fadnavis,
+ Shreyas and Fair, Damien A and Foran, Will and Fotiadis,
+ Panagiotis and Garyfallidis, Eleftherios and Giesbrecht, Barry
+ and Gur, Ruben C and Gur, Raquel E and Kelz, Max B and Keshavan,
+ Anisha and Larsen, Bart S and Luna, Beatriz and Mackey, Allyson P
+ and Milham, Michael P and Oathes, Desmond J and Perrone, Anders
+ and Pines, Adam R and Roalf, David R and Richie-Halford, Adam and
+ Rokem, Ariel and Sydnor, Valerie J and Tapera, Tinashe M and
+ Tooley, Ursula A and Vettel, Jean M and Yeatman, Jason D and
+ Grafton, Scott T and Satterthwaite, Theodore D",
+ journal = "Nat. Methods",
+ publisher = "Nature Publishing Group",
+ pages = "1--4",
+ abstract = "Diffusion-weighted magnetic resonance imaging (dMRI) is the
+ primary method for noninvasively studying the organization of
+ white matter in the human brain. Here we introduce QSIPrep, an
+ integrative software platform for the processing of diffusion
+ images that is compatible with nearly all dMRI sampling schemes.
+ Drawing on a diverse set of software suites to capitalize on
+ their complementary strengths, QSIPrep facilitates the
+ implementation of best practices for processing of diffusion
+ images. QSIPrep is a software platform for processing of most
+ diffusion MRI datasets and ensures that adequate workflows are
+ used.",
+ month = jun,
+ year = 2021,
+ language = "en",
+ DOI = "https://doi.org/10.1038/s41592-021-01185-5"
+}
+
+
+@ARTICLE{Tournier2019-cq,
+ title = "{MRtrix3}: A fast, flexible and open software framework for
+ medical image processing and visualisation",
+ author = "Tournier, J-Donald and Smith, Robert and Raffelt, David and
+ Tabbara, Rami and Dhollander, Thijs and Pietsch, Maximilian and
+ Christiaens, Daan and Jeurissen, Ben and Yeh, Chun-Hung and
+ Connelly, Alan",
+ journal = "Neuroimage",
+ volume = 202,
+ pages = 116137,
+ abstract = "MRtrix3 is an open-source, cross-platform software package for
+ medical image processing, analysis and visualisation, with a
+ particular emphasis on the investigation of the brain using
+ diffusion MRI. It is implemented using a fast, modular and
+ flexible general-purpose code framework for image data access and
+ manipulation, enabling efficient development of new applications,
+ whilst retaining high computational performance and a consistent
+ command-line interface between applications. In this article, we
+ provide a high-level overview of the features of the MRtrix3
+ framework and general-purpose image processing applications
+ provided with the software.",
+ month = nov,
+ year = 2019,
+ keywords = "Image; MRI; Processing; Software; Visualisation",
+ language = "en",
+ DOI = "https://doi.org/10.1016/j.neuroimage.2019.116137"
+}
+
+
+@ARTICLE{Avants2014-ci,
+ title = "The Insight {ToolKit} image registration framework",
+ author = "Avants, Brian B and Tustison, Nicholas J and Stauffer, Michael and
+ Song, Gang and Wu, Baohua and Gee, James C",
+ journal = "Front. Neuroinform.",
+ volume = 8,
+ pages = 44,
+ abstract = "Publicly available scientific resources help establish evaluation
+ standards, provide a platform for teaching and improve
+ reproducibility. Version 4 of the Insight ToolKit (ITK(4)) seeks
+ to establish new standards in publicly available image
+ registration methodology. ITK(4) makes several advances in
+ comparison to previous versions of ITK. ITK(4) supports both
+ multivariate images and objective functions; it also unifies
+ high-dimensional (deformation field) and low-dimensional (affine)
+ transformations with metrics that are reusable across transform
+ types and with composite transforms that allow arbitrary series of
+ geometric mappings to be chained together seamlessly. Metrics and
+ optimizers take advantage of multi-core resources, when available.
+ Furthermore, ITK(4) reduces the parameter optimization burden via
+ principled heuristics that automatically set scaling across
+ disparate parameter types (rotations vs. translations). A related
+ approach also constrains steps sizes for gradient-based
+ optimizers. The result is that tuning for different metrics and/or
+ image pairs is rarely necessary allowing the researcher to more
+ easily focus on design/comparison of registration strategies. In
+ total, the ITK(4) contribution is intended as a structure to
+ support reproducible research practices, will provide a more
+ extensive foundation against which to evaluate new work in image
+ registration and also enable application level programmers a broad
+ suite of tools on which to build. Finally, we contextualize this
+ work with a reference registration evaluation study with
+ application to pediatric brain labeling.",
+ month = apr,
+ year = 2014,
+ keywords = "MRI; brain; death; open-source; registration",
+ language = "en",
+ DOI = "https://doi.org/10.3389/fninf.2014.00044"
+}
+
+
+@ARTICLE{Garyfallidis2014-el,
+ title = "Dipy, a library for the analysis of diffusion {MRI} data",
+ author = "Garyfallidis, Eleftherios and Brett, Matthew and Amirbekian,
+ Bagrat and Rokem, Ariel and van der Walt, Stefan and Descoteaux,
+ Maxime and Nimmo-Smith, Ian and {Dipy Contributors}",
+ journal = "Front. Neuroinform.",
+ volume = 8,
+ pages = 8,
+ abstract = "Diffusion Imaging in Python (Dipy) is a free and open source
+ software project for the analysis of data from diffusion magnetic
+ resonance imaging (dMRI) experiments. dMRI is an application of
+ MRI that can be used to measure structural features of brain white
+ matter. Many methods have been developed to use dMRI data to model
+ the local configuration of white matter nerve fiber bundles and
+ infer the trajectory of bundles connecting different parts of the
+ brain. Dipy gathers implementations of many different methods in
+ dMRI, including: diffusion signal pre-processing; reconstruction
+ of diffusion distributions in individual voxels; fiber
+ tractography and fiber track post-processing, analysis and
+ visualization. Dipy aims to provide transparent implementations
+ for all the different steps of dMRI analysis with a uniform
+ programming interface. We have implemented classical signal
+ reconstruction techniques, such as the diffusion tensor model and
+ deterministic fiber tractography. In addition, cutting edge novel
+ reconstruction techniques are implemented, such as constrained
+ spherical deconvolution and diffusion spectrum imaging (DSI) with
+ deconvolution, as well as methods for probabilistic tracking and
+ original methods for tractography clustering. Many additional
+ utility functions are provided to calculate various statistics,
+ informative visualizations, as well as file-handling routines to
+ assist in the development and use of novel techniques. In contrast
+ to many other scientific software projects, Dipy is not being
+ developed by a single research group. Rather, it is an open
+ project that encourages contributions from any scientist/developer
+ through GitHub and open discussions on the project mailing list.
+ Consequently, Dipy today has an international team of
+ contributors, spanning seven different academic institutions in
+ five countries and three continents, which is still growing.",
+ month = feb,
+ year = 2014,
+ keywords = "DSI; DTI; HARDI; Python; dMRI; diffusion MRI; free open source
+ software; tractography",
+ DOI = "https://doi.org/10.3389/fninf.2014.00008"
+}
+
+
+@ARTICLE{Legarreta2026Gigascience,
+ title = "What needs to be standardized for reliable, reproducible, and
+ robust tractography?",
+ author = "Legarreta, Jon Haitz and Schiavi, Simona and Tang, Wei and Banks,
+ Garrett and Cieslak, Matthew and Schilling, Kurt and De Luca,
+ Alberto and Tournier, Jacques-Donald and Kruper, John and
+ Rheault, Francois and Sotiropoulos, Stamatios N and Pestilli,
+ Franco and Veraart, Jelle and Yang, Joseph Yuan-Mou and
+ Descoteaux, Maxime and Heilbronner, Sarah and Rokem, Ariel",
+ journal = "Gigascience",
+ publisher = "Oxford University Press (OUP)",
+ volume = 15,
+ number = "giag034",
+ pages = "giag034",
+ abstract = "Tractography is a key component of efforts to map brain
+ connectivity. As a rapidly evolving field of neuroscience,
+ current tractography methods are diverse, often varying across
+ research laboratories and different software pipelines.
+ Therefore, it suffers from a lack of standardization, leading to
+ inconsistencies in results, which can limit reproducibility and
+ affect the robustness needed for research and clinical
+ applications of these methods. Variability in data acquisition
+ procedures, inconsistencies in spatial referencing schemes and
+ implementations, and anatomical heterogeneity-at the individual
+ level, across the lifespan, and across species-hinder comparative
+ analyses. Additionally, the lack of consensus on best practices
+ complicates the development of robust automated quality control
+ pipelines and limits the clinical translation of
+ tractography-based procedures. Establishing standardized
+ protocols for acquisition, preprocessing, and tractography
+ reconstruction is critical toward enabling reliable
+ tract-specific analyses, facilitating cross-study harmonization,
+ and supporting replicable large-scale population studies. The
+ present article provides an overview of the current challenges in
+ tractography standardization and identifies the key aspects that
+ require standardization for reliable, reproducible, and robust
+ tractography.",
+ month = jan,
+ year = 2026,
+ keywords = "brain connectivity; computational neuroimaging; neuroanatomy;
+ standardization; tractography; white matter",
+ language = "en"
+}
+
+
+@ARTICLE{Kruper2024HCP,
+ title = "Tractometry of the Human Connectome Project: resources and
+ insights",
+ author = "Kruper, John and Hagen, Mckenzie P and Rheault, François and
+ Crane, Isaac and Gilmore, Asa and Narayan, Manjari and Motwani,
+ Keshav and Lila, Eardi and Rorden, Chris and Yeatman, Jason D and
+ Rokem, Ariel",
+ journal = "Front. Neurosci.",
+ publisher = "Frontiers Media SA",
+ volume = 18,
+ pages = 1389680,
+ abstract = "Introduction: The Human Connectome Project (HCP) has become a
+ keystone dataset in human neuroscience, with a plethora of
+ important applications in advancing brain imaging methods and an
+ understanding of the human brain. We focused on tractometry of
+ HCP diffusion-weighted MRI (dMRI) data. Methods: We used an
+ open-source software library (pyAFQ;
+ https://yeatmanlab.github.io/pyAFQ) to perform probabilistic
+ tractography and delineate the major white matter pathways in the
+ HCP subjects that have a complete dMRI acquisition (n = 1,041).
+ We used diffusion kurtosis imaging (DKI) to model white matter
+ microstructure in each voxel of the white matter, and extracted
+ tract profiles of DKI-derived tissue properties along the length
+ of the tracts. We explored the empirical properties of the data:
+ first, we assessed the heritability of DKI tissue properties
+ using the known genetic linkage of the large number of twin pairs
+ sampled in HCP. Second, we tested the ability of tractometry to
+ serve as the basis for predictive models of individual
+ characteristics (e.g., age, crystallized/fluid intelligence,
+ reading ability, etc.), compared to local connectome features. To
+ facilitate the exploration of the dataset we created a new
+ web-based visualization tool and use this tool to visualize the
+ data in the HCP tractometry dataset. Finally, we used the HCP
+ dataset as a test-bed for a new technological innovation: the TRX
+ file-format for representation of dMRI-based streamlines.
+ Results: We released the processing outputs and tract profiles as
+ a publicly available data resource through the AWS Open Data
+ program's Open Neurodata repository. We found heritability as
+ high as 0.9 for DKI-based metrics in some brain pathways. We also
+ found that tractometry extracts as much useful information about
+ individual differences as the local connectome method. We
+ released a new web-based visualization tool for
+ tractometry-``Tractoscope'' (https://nrdg.github.io/tractoscope).
+ We found that the TRX files require considerably less disk
+ space-a crucial attribute for large datasets like HCP. In
+ addition, TRX incorporates a specification for grouping
+ streamlines, further simplifying tractometry analysis.",
+ month = jun,
+ year = 2024,
+ keywords = "MRI; Open Data; brain; data visualization; diffusion MRI;
+ heritability; predictive modeling; tractometry",
+ language = "en"
+}
diff --git a/source/software.md b/source/software.md
new file mode 100644
index 0000000..c31a8e7
--- /dev/null
+++ b/source/software.md
@@ -0,0 +1,95 @@
+# Software
+
+TRX is integrated into several software libraries:
+
+## TRXViz
+
+[TRXViz](https://github.com/tee-ar-ex/TRXViz) is a tool for visualization and
+processing of diffusion-MRI based tractography. Implemented in Rust, it
+supports fast visualization and basic processing of TRX-based tractography.
+
+## pyAFQ
+
+[pyAFQ](https://tractometry.org/pyAFQ) is a Python library for automated
+white matter tractography and tractometry. It uses TRX to parallelize and
+accelerate tractography, as well as to perform batched operations over
+groups of streamlines in ways that allow handling very large tractograms
+(>100M streamlines) on standard hardware. See [this PR](https://github.com/tractometry/pyAFQ/pull/208).
+
+## Trekker
+
+Trekker implements parallel transport tractography for generating geometrically
+smooth streamlines {cite:p}`Aydogan2021-ug`. It uses the TRX C++ implementation
+for I/O.
+
+## DIPY
+
+[DIPY](https://dipy.org/) is a library for the analysis of diffusion MRI
+data {cite:p}`Garyfallidis2014-el`. DIPY supports I/O in many different
+file formats, including TRX. See [this PR](https://github.com/dipy/dipy/pull/3587)
+
+## QSIPrep & QSIRecon
+
+QSIPrep is an integrative platform for preprocessing and reconstructing
+diffusion MRI data {cite:p}`Cieslak2021-ic`. QSIPrep and its post-processing
+pipelines, implemented in QSIRecon advance the use of TRX as an interchange
+format, because they knit together functionality from many different software
+libraries.
+
+## Surfice
+
+Surfice is a tool for visualizing neuroimaging meshes, tractography
+streamlines, and connectomes {cite:p}`Rorden2025-zq`.
+
+## SlicerDMRI
+
+SlicerDMRI is an open source diffusion MRI software, implemented as an
+extension of 3D Slicer {cite:p}`Norton2017-yz`. It now supports use of TRX,
+through its C++ implementation. See [this PR](https://github.com/SlicerDMRI/SlicerDMRI/pull/250).
+
+## FSL
+
+[FSL](https://fsl.fmrib.ox.ac.uk/fsl/) is a comprehensive library of tools
+for functional MRI, structural MRI, and diffusion MRI analysis. The FSLeyes
+viewer includes support for TRX as of its 1.20 version release. See [this PR](https://git.fmrib.ox.ac.uk/fsl/fsleyes/fsleyes/-/merge_requests/504).
+
+## COMMIT
+
+COMMIT (Convex Optimization Modeling for Microstructure Informed Tractography)
+is a framework for microstructure-informed tractography. TRX support in
+COMMIT using its C++ implementation is currently work-in-progress (see [this PR](https://github.com/daducci/COMMIT/pull/163))
+
+## brainlife.io
+
+[brainlife.io](https://brainlife.io) is a decentralized and open-source cloud
+platform to support neuroscience research {cite:p}`Hayashi2024-zm`. It uses
+TRX for streamline I/O.
+
+## Niivue
+
+[Niivue](https://niivue.com/) is a WebGL-based visualization library for
+neuroimaging data, including tractography streamlines. It uses features of TRX
+to display different groups (e.g., tracts) and their distinct properties. See
+[this PR](https://github.com/niivue/niivue/pull/841)
+
+## DWI2TRX
+
+The [DWI2TRX](https://tee-ar-ex.github.io/dwi2trx/) web application uses
+WASM-based dcm2niix and niimath as well as WebGPU-based NiiVue, mindgrab and
+GPUstreamlines to perform a minimal processing pipeline that generates a TRX
+tractography from NIfTI/bval/bvec files or from a directory of DICOMs. All
+computations are conducted client-side on the user's computer, and no data is
+uploaded to any remote server. It works on any web-enabled device that supports
+the full WebGPU standard.
+
+## Insight ToolKit (ITK)
+
+ITK is an open-source framework for image analysis. TRX has been integrated as
+an external module, making it available for users of the ANTS registration
+framework {cite:p}`Avants2014-ci`. See [this PR](https://github.com/InsightSoftwareConsortium/ITK/pull/6687).
+
+## MRtrix
+
+[MRtrix3](https://www.mrtrix.org/) is a fast, flexible and open software
+framework for medical image processing and visualisation {cite:p}`Tournier2019-cq`.
+Integration of TRX support is currently in progress (in [this PR](https://github.com/MRtrix3/mrtrix3/pull/3415)).
diff --git a/source/specification.md b/source/specification.md
new file mode 100644
index 0000000..4bd6d9d
--- /dev/null
+++ b/source/specification.md
@@ -0,0 +1,175 @@
+# TRX Specification
+
+This page defines the TRX file format specification. The authoritative
+specification is maintained in the
+[trx-spec](https://github.com/tee-ar-ex/trx-spec) repository.
+
+## General
+
+- Uncompressed ZIP file or simple folder architecture
+- File architecture describes the data
+- Each file basename is the metadata's name
+- Each file extension is the metadata's dtype
+- Each file dimension is in the value between basename and metadata
+- 1-dimensional arrays do not have to follow this convention for readability
+- All arrays have a C-style memory layout (row-major)
+- All arrays have a little-endian byte order
+- Compression is optional
+ - Use `ZIP_STORE` if no compression is desired
+ - Use `ZIP_DEFLATE` if compression is desired
+ - Compressed TRX files will have to be decompressed before being loaded
+
+## Header
+
+The header is primarily for human readability, read-time checks, and broader
+compatibility.
+
+- Dictionary in JSON
+ - `VOXEL_TO_RASMM` — 4 lists of 4 floats (4x4 transformation matrix)
+ - `DIMENSIONS` — list of 3 uint16
+ - `NB_STREAMLINES` — uint32
+ - `NB_VERTICES` — uint64
+
+## Arrays
+
+### positions
+
+- Written in world space (RASMM), like TCK files
+- Always float16, float32, or float64 (default: float16)
+- Stored as contiguous 3D array `(NB_VERTICES, 3)`
+
+### offsets
+
+- Always uint32 or uint64
+- Contains the index where each streamline starts in the positions array,
+ beginning at 0
+- Two ways of knowing how many vertices there are:
+ - Check the header
+ - Positions array size / dtype / 3
+- To get streamline lengths: append the total number of vertices to the end of
+ offsets and take the differences between consecutive elements
+ (`numpy.ediff1d`)
+
+### dpv (data per vertex)
+
+- Always of size `(NB_VERTICES, 1)` or `(NB_VERTICES, N)`
+
+### dps (data per streamline)
+
+- Always of size `(NB_STREAMLINES, 1)` or `(NB_STREAMLINES, N)`
+
+### groups
+
+Groups are tables of indices that allow sparse and overlapping representation
+(clusters, connectomics, bundles).
+
+- All indices must satisfy `0 <= id < NB_STREAMLINES`
+- Datatype should be uint32
+- Allow efficient extraction of a predefined streamline subset from memmaps
+- Variable sizes across groups
+
+### dpg (data per group)
+
+- Each subfolder is named after its corresponding group
+- Not all metadata need be present in all groups
+- Always of size `(1,)` or `(N,)`
+
+## Accepted datatypes
+
+- int8, int16, int32, int64
+- uint8, uint16, uint32, uint64
+- float16, float32, float64
+- bit (for binary/boolean arrays)
+
+## Example structure
+
+```
+OHBM_demo.trx
+├── dpg
+│ ├── AF_L
+│ │ ├── mean_fa.float16
+│ │ ├── shuffle_colors.3.uint8
+│ │ └── volume.uint32
+│ ├── AF_R
+│ │ ├── mean_fa.float16
+│ │ ├── shuffle_colors.3.uint8
+│ │ └── volume.uint32
+│ ├── CC
+│ │ ├── mean_fa.float16
+│ │ ├── shuffle_colors.3.uint8
+│ │ └── volume.uint32
+│ ├── CST_L
+│ │ └── shuffle_colors.3.uint8
+│ ├── CST_R
+│ │ └── shuffle_colors.3.uint8
+│ ├── SLF_L
+│ │ ├── mean_fa.float16
+│ │ ├── shuffle_colors.3.uint8
+│ │ └── volume.uint32
+│ └── SLF_R
+│ ├── mean_fa.float16
+│ ├── shuffle_colors.3.uint8
+│ └── volume.uint32
+├── dpv
+│ ├── color_x.uint8
+│ ├── color_y.uint8
+│ ├── color_z.uint8
+│ └── fa.float16
+├── dps
+│ ├── algo.uint8
+│ ├── algo.json
+│ ├── clusters_QB.uint16
+│ ├── commit_colors.3.uint8
+│ └── commit_weights.float32
+├── groups
+│ ├── AF_L.uint32
+│ ├── AF_R.uint32
+│ ├── CC.uint32
+│ ├── CST_L.uint32
+│ ├── CST_R.uint32
+│ ├── SLF_L.uint32
+│ └── SLF_R.uint32
+├── header.json
+├── offsets.uint64
+└── positions.3.float16
+```
+
+## Example code
+
+```python
+from trx_file_memmap import TrxFile, load, save
+import numpy as np
+
+trx = load('complete_big_v5.trx')
+
+# Access the header (dict) / streamlines (ArraySequences)
+trx.header
+trx.streamlines
+
+# Access the dpv (dict) / dps (dict)
+trx.data_per_vertex
+trx.data_per_streamline
+
+# Access the groups (dict) / dpg (dict)
+trx.groups
+trx.data_per_group
+
+# Get a random subset of 10000 streamlines
+indices = np.arange(len(trx.streamlines._lengths))
+np.random.shuffle(indices)
+sub_trx = trx.select(indices[0:10000])
+save(sub_trx, 'random_1000.trx')
+
+# Get sub-groups only, from the random subset
+for key in sub_trx.groups.keys():
+ group_trx = sub_trx.get_group(key)
+ save(group_trx, '{}.trx'.format(key))
+
+# Pre-allocate memmaps and append 100x the random subset
+alloc_trx = TrxFile(nb_streamlines=1500000, nb_vertices=500000000, init_as=trx)
+for i in range(100):
+ alloc_trx.append(sub_trx)
+
+# Resize to remove the unused portion of the memmap
+alloc_trx.resize()
+```