Skip to content

One BIDS intent engine for dcm2niix front ends #516

Open

Description

@gdevenyi

Problem

dcm2niix converts each series of a DICOM session on its own. This makes conversion
fast and deterministic, but dcm2niix cannot use information across series to find
the purpose of each one. For example, a reverse phase-encoding (PEpolar) fieldmap
can be identical to a DWI acquisition.

Today three separate tools try to find that purpose:

Each tool needs constant changes as sequences, DICOM and BIDS change. Three code
bases triple that work, and they can disagree on the same data.

Proposal

Make one engine that takes dcm2niix's per-series outputs (JSON sidecars,
.bval/.bvec, image dimensions) and returns a BIDS plan: datatype, suffix,
entities, IntendedFor, and B0FieldIdentifier/B0FieldSource.

  • Write it in Rust, so the same code runs as a native command line and as
    WebAssembly in the browser. This is how other tools in this repository work
    (see exes/).
  • Use ReproIn protocol names (https://npacore.github.io/reproin-namer/) when
    they are present, and use rules from the metadata when they are not.
  • Keep the user's review step in the web app. The engine suggests, and the user
    confirms.

Open questions

  1. Where does the code live: in this repository (exes/ and packages/), in a
    separate repository, or in the dcm2niix repository next to reproinx.py?
  2. Should the engine replace reproinx.py and the BIDSvue script, or start as a
    third implementation that they can move to later?
  3. Which BIDS datatypes come first? The web app now does anat (T1w, T2w, FLAIR),
    dwi and PEpolar fieldmaps. BIDSvue also handles physiological data and MRS.

Regression data

The BIDSvue tutorials include validation DICOM datasets
with advanced cases (physiological data, MRS and others). Pin them on the
Hugging Face dataset and use them as regression tests for the engine, in the
same way as the pinned neurolabusc/dcm_qa_philips_dwi data that the dcm2niix
app's browser tests use now.

Context: #382 (comment) (comment by @neurolabusc, 2026-10-20)

@neurolabusc, what do you think of this plan, and where would you like the code to live?

Activity

  1. stebo85 commented on Oct 24, 2026

    @stebo85
    Contributor

    For implementation, where should the canonical BIDS intent engine live: this repository, dcm2niix, or a new shared repository? Should the initial scope cover anatomical MRI, DWI and PEPOLAR with adapters for reproinx/BIDSvue, or replace their current engines immediately?

  2. neurolabusc commented on Oct 24, 2026

    @neurolabusc
    Collaborator

    @gdevenyi and @stebo85 I suggest deferring on this just a bit: the imminent upcoming release of dcm2niix will dramatically improve WASM performance and the amount of JavaScript glue required to use the npm package. The only roadblock are recent changes to GE DICOM images, which I hope to resolve shortly. After this, I propose a Rust-based tool that replaces the Python-based reproinx.py that comes with dcm2niix and the JavaScript wrapper in BIDSvue.

    My first instinct is that correct location for this would be the neurodesk webapps exes folder. I am happy to make the first pass at this after the dcm2niix settles. The BIDS standard is evolving, so this wrapper will need constant maintenance. Therefore, an alternative is to create a dedicated github repository that has submodules in webapps, dcm2niix and bidsvue. Happy to follow consensus on guidance.

  3. gdevenyi commented on Oct 29, 2026

    @gdevenyi
    CollaboratorAuthor

    Is this ready to address @neurolabusc

  4. stebo85 commented on Oct 29, 2026

    @stebo85
    Contributor

    open issue audit run — 2026-10-29

    P3 · Deferred design and platform exploration · team discussion

    Upstream maintainer offered first Rust implementation after next dcm2niix settles, and was asked again if ready. Repository ownership/location remains a coordination question.

    Next action: Confirm readiness and canonical home with neurolabusc; avoid starting a competing implementation while existing maintainer offer is unresolved.

    Evidence: source 1 · source 2

    Priority is an audit recommendation. Closure candidates remain open pending the stated verification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions