One visit, four modalities, one dataset.

A participant who had an MRI, a PET scan, an EEG session and an MEG session. Four file formats, three conversion engines, and four different opinions about who was scanned. This walkthrough takes the whole thing to a validated BIDS dataset in one pass, and the work that matters is not the conversion.

The sample dataset.

Unzip it anywhere you like. You never point BIDS Manager at the zip itself; you point it at the raw/ folder inside, once, and it finds everything below.

Every file, and what to do with it.

One participant folder holding one folder per modality, which is how a great many labs actually store a visit.

Create a project, then scan once.

On the Home tab choose Create and give the dataset a folder and a name, for example multimodal_tutorial. In the Converter, press Scan and choose raw/.

Once. Not once per modality. There is no modality setting to pick, no format to declare and no separate importer to run, because the scanner decides what each file is by opening it. That is the single most important thing this page has to show, and it is over in one click.

What the scan is doing while it walks the tree

• DICOM is recognised by the DICM marker inside each file, then grouped into series by the identifiers in the headers. Both the MRI and the PET arrive this way, and nothing tells them apart in advance: the classifier reads them and works out that one is anatomical and functional MRI and the other is PET.
• EDF and FIF are recognised by their own signatures and read through MNE, which is where the channel counts, the sampling rates and the measurement dates come from.
• Nothing is recognised by its extension, so a renamed file still converts and an .img that is really DICOM is not skipped.

What you should see now: ten rows. Eight to convert, two the scan excluded on its own.

Read the table. Everything is in it.

Ten rows, four modalities, three file formats, six BIDS datatypes. This one table is the whole study, and every decision from here is an edit to a cell in it.

What each column is telling you

The two rows the scan set aside

Neither is an error, and neither is hidden. The PhoenixZIPReport is a Siemens scanner report with no image pixels in it at all, so no converter can turn it into a NIfTI; the row is marked, excluded, and carries the reason. The localizer is a scout image, useful to the radiographer and not part of the dataset. Both can be put back with a click if you disagree.

This matters more than it sounds on a multimodal run. A tool that silently skipped them would leave you unable to tell an excluded file from a file that failed to convert, at exactly the moment when several engines are running and any one of them could have gone wrong.

One participant, one visit, four opinions.

Look at the id and ses columns in the figure above. One person went through four machines on one day, and the scan came back with this:

Every one of those answers is defensible from the file it came from. Together they are wrong, and they are wrong in the way that costs the most: convert now and you get two subjects and three sessions, all valid BIDS, all passing a validator, and none of it matching your participant list.

Fixing it, which is two edits

1. Select every row. Press Bulk edit, set id to sub-001, and apply.
2. With the rows still selected, set ses to 01.

The predicted basenames rebuild as you type. Watch that column while you do it: it is the conversion telling you, before anything is written, exactly what it is about to write.

One form, four modalities.

Press Dataset metadata. On a single-modality study this form is short. Here it has a section for every kind of file the scan found, and it is worth understanding how it is organised before you start filling it in, because the organisation is the answer to a real problem.

The shared region

The institution, the department, the authors, the participants spreadsheet. You answer these once. They reach every sidecar whose datatype declares them, which is decided by the standard rather than by a list somebody typed out. Point the participants field at participants.csv from the download.

The per-datatype sections

Below the shared region there is one section per kind of file, and each asks only what that kind of file needs:

• PET asks for the radiochemistry, because BIDS requires it and no scanner records it. Fill this from dose_sheet.csv. The PET tutorial goes through those nine fields one at a time.
• EEG asks for the reference and the ground, which an EDF file has nowhere to store.
• MEG asks for the dewar position and the associated empty-room recording, and nothing that mne-bids can read out of the file itself.
• MRI asks for almost nothing, because dcm2niix already read almost everything from the DICOM headers.

That asymmetry is the honest picture of the four modalities, and it is why one form with sections beats four separate configuration files: you can see at a glance which modality is going to need work.

One conversion, three engines.

Open the BIDS preview in the bottom panel and check the tree you are about to write. Then press Run conversion.

Behind that one button, three different programs run:

You do not choose any of that, and there is no setting for it. Each row is routed by what it is.

Why one pass and not four

• Failure is contained. Conversion runs per subject into a staging folder and is committed only when the subject finishes. A backend that fails takes its own row down and leaves the rest of the dataset alone. On a four-modality run that matters: three engines are more ways for something to go wrong.
• The cross-modality work happens once, at the end. Fieldmaps get their IntendedFor, scans.tsv is written per subject across every datatype, and the shared metadata reaches all of them. Converting each modality separately means doing this by hand afterwards, on files four different tools have already written.
• Names are checked across the whole dataset, not within a modality. Two recordings that would land on the same filename are caught before anything is written, whichever engines would have produced them.

Then run the metadata step. On this dataset it writes participants.tsv from your spreadsheet, scans.tsv for the session, and the answers you gave in Step 4 into every sidecar that takes them.

Validate the whole thing at once.

Switch to the Editor, open the dataset and press Validate dataset. On this sample, with the PET dose sheet filled in:

A hundred and fifty-six warnings sounds like a lot until you notice what it is counting. The number is per finding, not per file: every recommended field, on every one of six datatypes, on a dataset assembled from four unrelated acquisitions with no shared study documentation. A real study answers most of them once in the shared region of the metadata form, and one answer there clears the same warning from every file at once.

The validator is the same one for every modality, and it reads the same schema the metadata form was built from. That is why one number covers the whole dataset rather than four reports you have to compare by hand. Details of how it reports, and what the severity filter and deep checks do, are in the GUI walkthrough.

Look at what you made.

One subject, one session, six datatype folders. The Editor's tree is the quickest way to see that the four modalities really did land as one dataset rather than four that happen to share a folder.

Every file opens in the same window

Click through them. The Editor routes by what the file is, so you do not change tools to change modality:

• The T1w, the BOLD and the PET open in the image viewer: one plane, three planes sharing a crosshair, or the GPU renderer. The BOLD gains a time-series graph because it is 4-D.
• The EEG and the MEG open as a metadata card first, then as an interactive time-series viewer when you press Load signal, with filtering, an in-application power spectrum and the events overlaid from the events.tsv beside them.
• Every sidecar opens as a schema-aware form, with each field marked required, recommended or optional, and the standard's own description on hover.
• Every table, channels.tsv, events.tsv, participants.tsv, scans.tsv, opens as an editable spreadsheet.

Worth opening in this dataset: sub-001_ses-01_scans.tsv, which lists every image in the session with its acquisition time regardless of which engine wrote it, and the MEG channels.tsv, which is where you would retype an auxiliary channel that the amplifier recorded as if it were brain data.

From the command line.

The same engine, and notably the same single scan and single conversion. There is no per-modality command here either.

# 1. Create the dataset and its project.
bidsmgr-create ~/bids/multimodal_tutorial --name "Multimodal tutorial"

# 2. One scan for all four modalities. Ten rows.
bidsmgr-scan ~/BIDS_Manager_multimodal_sample/raw \
    --project ~/bids/multimodal_tutorial --probe-convert

# 3. Reconcile subject and session in the inventory, then convert.
#    Three engines run; you do not name any of them.
bidsmgr-convert --project ~/bids/multimodal_tutorial \
    --raw-root ~/BIDS_Manager_multimodal_sample/raw

# 4. Metadata: participants.tsv, scans.tsv, and your answers.
bidsmgr-metadata --project ~/bids/multimodal_tutorial --fill-todos \
    --participants ~/BIDS_Manager_multimodal_sample/participants.csv

# 5. Validate everything at once.
bidsmgr-validate ~/bids/multimodal_tutorial

Step 3's reconciliation is an edit to the inventory TSV between the scan and the conversion: set participant_id and session on every row and the names rebuild from the entities. The PET answers live under sequence_templates["pet/pet"] in the .recording_meta.json beside the inventory, keyed by their BIDS names. Every flag is documented in the CLI reference.

What usually goes wrong in a multimodal run.

Per-modality detail

Each modality has its own full tutorial, with its own sample dataset, the specific quirks, real numbers from a complete run, and what typically needs attention: MRI, MRI advanced, PET, EEG, MEG.

The full GUI walkthrough → CLI reference