Intro

What is BIDS Manager?

BIDS Manager is a multimodal raw-to-BIDS conversion and curation tool. It covers the full BIDS workflow for MRI, EEG, MEG, and physiological recordings in a single integrated environment, with the official BIDS schema as the source of truth for naming, structure, and validation.

Rather than reinventing the engines that convert each modality, BIDS Manager wraps the trusted community-maintained ones:

  • dcm2niix for DICOM-to-NIfTI conversion of MRI data.
  • mne-bids for EEG, MEG, iEEG, and NIRS recordings.
  • bidsphysio for Siemens CMRR physiological data.

On top of these backends, BIDS Manager adds an integrated orchestration layer:

  • A unified scanner that reads metadata from inside every raw file across all modalities.
  • An interactive curation surface where users review, filter, and edit the planned conversion before any byte is written to disk.
  • A metadata enrichment algorithm that fills required sidecar fields after conversion, with an audit log of every decision.
  • A schema-driven validator that audits the resulting dataset against the BIDS standard.

BIDS Manager exposes this orchestration through two surfaces. The graphical user interface automates and semi-automates the decisions visually, with an interactive table, an inspection view, and a built-in NIfTI viewer. The command-line interface offers five verbs (bidsmgr-scan, bidsmgr-rebuild, bidsmgr-convert, bidsmgr-metadata, bidsmgr-validate) for scripted, headless, or pipeline use.

Both surfaces drive the same engine. A scan run from the CLI produces the same inventory the GUI populates; an edit made in the GUI is replayable from the CLI.

Why it exists

Raw datasets are rarely as clean as the conversion process assumes. Real sessions accumulate complications:

  • DICOMs from one subject can land in the wrong subject folder.
  • An interrupted run leaves behind residual volumes.
  • A bad scan is re-run on the spot, leaving both attempts in the same folder.
  • Calibration scans, localizers, and scanner reports mix with the acquisitions of interest.
  • Naming drifts when the protocol changed mid-study.
  • The expected session is missing a run, or has one extra.

Most conversion tools require the user to declare what is in the folder up front. They expect a heuristic file or a configuration that encodes the expected structure: this acquisition is the T1w; this one is the rest BOLD; ignore the localizers. That design assumes the user knows exactly what happened during every session, every run.

That assumption is fragile. Users routinely work with data they did not acquire: a colleague's project, a multi-site dataset, an archive from a former lab member. Even when the user was the operator, weeks or months later the memory of "we restarted run 02 because the subject moved" is gone. When the actual data does not match the configuration, the conversion silently mislabels rows, skips legitimate acquisitions, or worse, produces a BIDS-valid output that is structurally correct but wrong about what each file is.

BIDS Manager takes a different approach. Before any conversion execution, it scans the raw folder and presents every acquisition the way it actually exists on disk: subject, session, run, modality, file count, scanner timestamps, image type, sequence parameters. Mixed subjects show up as separate rows in the same folder. Residual volumes appear with their reduced file counts visible. Repeated sequences are listed side by side, with the timestamps that let the user pick the right take. Calibration and localizer series are marked for skipping, but the user reviews and confirms every decision before anything is written to disk.

The conversion then encodes what the user actually sees and chooses, not what a configuration file assumes about the session.

Who it is for

  • Researchers who want a "scan, review, convert, validate" loop with no scripting.
  • Lab managers who need reproducible BIDS exports across many subjects and modalities.
  • Power users who want to build or adapt their own scripts on top of the core algorithms BIDS Manager exposes through its CLI.
How it works

Eight stages, three views.

The workflow runs in eight stages that alternate between user-driven and engine-driven steps:

Raw is the unprocessed input folder. Scan walks the folder and reads metadata from inside every file. Curate is where the user reviews the inventory and decides what to convert, filter, or override. Convert runs the right backend for each modality and writes the BIDS-organized data files with their sidecars. Enrich automatically fills required sidecar fields using the captured metadata and the BIDS schema. Fix-ups is the manual stage where the user opens the Editor and adjusts anything the enrichment could not infer. Validate audits the result against the schema. BIDS is the finished, validated dataset.

Click any stage in the diagram below to read it as engine internals, data artefacts, or GUI panels.

Raw Scan Curate Convert Enrich Fix-ups Validate BIDS

rawRaw data

Click a stage in the diagram above to read about it.

Why eight stages?

Most BIDS converters collapse the middle stages into one opaque run. Splitting them is what lets the user review the inventory before any conversion runs, and review the converted result before any validation.

Enrich and Fix-ups have different drivers. Enrich is automatic: a schema-driven algorithm fills what it can. Fix-ups is interactive: the user resolves what the algorithm could not.

Next steps