What dataset is needed?

[jcohenadad]

Hi,

I'm very excited by this tool. I started a similar project, before realizing yours existed, so I'm going to invest some time testing your project instead.

Just to clarify, from the README (5a6ae3e):

We need YOUR datasets to improve robustness.

What do you mean exactly by "datasets"?

• Full DICOM files (incl. image)?
• Pseudonimyzed DICOM metadata? More details here
• How about the desired BIDS tree structure (ie: to be used as ground truth for training your model)

[yiyiliu-rose]

Hi,

Thank you for your interest and for pointing this out. I should clarify this soon in the README.

1. Full DICOM files can be helpful, especially for testing real-world conversion cases. De-identified datasets are of course welcome when they can be shared appropriately.

2. Pseudonymized or de-identified DICOM metadata is also very useful. In many cases, metadata plus the original folder/file organization is enough for us to understand how AutoBIDSify should handle a dataset.

3. The expected BIDS tree structure would be especially helpful. Since many real-world datasets are messy and may not already have ground-truth BIDS labels, this can be a BIDS-compatible structure created during testing, either manually designed or manually corrected after running the tool.

We would be very happy to hear any feedback or testing experience you may have with AutoBIDSify.

[jcohenadad]

I'm sorry but I'm a bit confused as to what your project requires exactly. I'm reading that all of the above (ie: 1, 2, 3) is "very helpful", but there is no clear indication as to how the data will be used, and what level of "helpfulness" each represent.

Obviously, sharing DICOM data from patient is out of the question for the majority of the centers. Yet, these are the data we want to challenge AutoBIDSify with, because this is currently where most issues lie (various protocols, practices of MR techs for naming scans, etc.).

I think that 2 and 3 are feasible, but could you please clarify exactly in what format/structure we should share these data? An "example" folder with expected data would be useful for future contributors.

Thank you

[yiyiliu-rose]

Thank you for the clarification. README should be more specific about what kind of data we need, how it would be used, and how contributors should prepare it.

Full DICOM image data is not required in most cases. We understand that sharing patient DICOM data is usually not feasible for many centers. For AutoBIDSify, the more practical and recommended contribution would include the following:

1. The original file/folder structure
   For example, the output of a tree command, or a simplified representation of the raw dataset organization. This helps us test how AutoBIDSify handles irregular real-world dataset structures.

2. De-identified or pseudonymized DICOM metadata
   This does not need to include image data. It helps us understand scanner/vendor conventions, protocol names, series descriptions, and scan naming patterns.

3. An expected BIDS-compatible output structure
   This can serve as a reference for testing and debugging. It does not have to be an existing official ground truth. Since many messy datasets do not already have ground-truth BIDS labels, this structure can be manually designed during testing or manually corrected after running AutoBIDSify.

A possible contribution format could be:

example_dataset/
├── raw_tree.txt              # Original file/folder structure, e.g., output from the tree command
├── dicom_metadata/           # De-identified or pseudonymized DICOM metadata, without image data
│   ├── series_001.json       # One metadata JSON file per series
│   ├── series_002.json       # Include fields such as ProtocolName, SeriesDescription, Modality, etc.
│   └── ...
├── expected_bids_tree.txt    # Expected BIDS-compatible output directory structure
└── notes.md                  # Mapping decisions, ambiguous cases, manual corrections, or other notes

Your suggestion about adding an example folder is very helpful. I will add a contribution template/example folder to the repository so future contributors can follow a clearer format.

Thanks again for reaching out, and we would be very happy to hear any feedback or testing experience you may have with AutoBIDSify.

[AlexVCaron]

I'm working in tandem with @jcohenadad. Thanks a lot for the precisions. Note that most conversions I've attempted (against other tools or curated BIDS) have been successful, flawless even, very optimistic !

I'm preparing minimal datasets to seed our use-case in your model, given the format you gave above. Not sure I'll have the actual BIDS though (will take a little more time to manually craft), but I'll try when possible. Else, might take a little more time getting them sorted correctly.

[yiyiliu-rose]

Thanks Alex, that's great to hear!

There are a few types of feedback that would also be especially useful to us, and they should not require much extra manual work.

1. The pipeline's LLM questions

When AutoBIDSify is not confident about how the input data should map to a BIDS label based on the available information, such as the protocol name or series description, it asks a clarification question instead of silently guessing.

These questions mainly appear in two stages:

• classify stage, when the modality or data type is ambiguous;
• plan stage, when the BIDS entity mapping is uncertain while building the per-file conversion plan (BIDSPlan)

The questions are printed in the run log and are also saved in the output of the corresponding stage.

2. Errors and warnings in the log

If a conversion fails, the log should contain the related errors or warnings, such as DICOM-to-NIfTI conversion failures, unmatched BIDS entities, or duplicate/missing participant IDs.

These messages are very helpful because they often point directly to the messy real-world cases you mentioned, such as different protocols, inconsistent series names, or MR-tech naming habits.

3. The dataset description

The dataset description is also very important. AutoBIDSify uses the natural-language description to give the LLM context during the classify and plan stages.

A short but clear description of the dataset, including the modality, acquisition context, and naming conventions, can make the mapping more reliable and reduce the number of ambiguous questions. This can be provided in notes.md or through the runtime description field.

This will help us look more closely at cases that failed or were unclear, and see whether the issue is with the pipeline itself or with missing information in the input description.

Looking forward to whatever you can share!

[fangq]

@jcohenadad and @AlexVCaron, I am @yiyiliu-rose's PhD advisor, I just noticed this thread.

autobidsify is (ambitiously) designed as an "any-to-BIDS" converter - it extracts the metadata from most common neuroimaging raw data files (dcm, nii/nii.gz, edf, snirf/hdf5 etc), with files organized in arbitrary naming schemes/folder structures, and use prompt engineering and LLM to map the user-custom file organization into BIDS compliant form.

LLM helps understanding the data structure, mapping existing metadata/file/folder organization into BIDS conventions, and produces a BIDSPlan.yml file as the blueprint for the actual conversion. The final step, execution of the conversion is done using pure Python code combined with data file parsers/libraries/utilities to do the actual conversion.

For dcm, the final step of autobidsify calls @neurolabusc's dcm2niix to perform the actual conversion. with proper flags, dcm2niix can anonymize dcm just like how dcm files are typically consumed.

LLM is used for input file/folder/header comprehension and mapping strategy generation. If the data contains private information, it should not be sent to public LLM (like gpt-4o), instead, you should set up your local LLM instances (ollama etc), and use OLLAMA_BASE_URL and --model to specify local LLM models. This way, metadata will not leave the box.

@yiyiliu-rose, please add a --anonymize option to force removing private information (via both prompts and utility flags, such as -ba with dcm2niix).

[fangq]

@jcohenadad and @AlexVCaron, I also want to mention a web interface for autobidsify developed by my programmer @elainefan331

this interface complements the python-based autobidsify by performing most of the metadata extraction and BIDSplan generation in the web browser (it reimplements the workflow using typescript), and leaves the final conversion step to autobidsify or a compiled GUI (i.e. the AutoBIDSify Converter)

@elainefan331 also added a "Private mode" in this interface, and requires users to configure local LLM. if the dataset is already deidentified, the web based autobidsify can save the data conversion as a project in our neurojson.io portal.

check out the video tutorial Elaine created recently:

https://neurojson.io/io/download/static/videos/autobidsify.mp4

[neurolabusc]

Qianqian Happy to meet with your team and show the progress on BIDSvue since OHBM. I have dramatically improved the dcm2niix bids-guess, and a new stable release will be out soon. It also now converts MRS and physiological data saved as DICOM to BIDS. I did also add some AI features into BIDSvue.

-c

On Jun 24, 2026, at 5:46 PM, Qianqian Fang ***@***.***> wrote: fangq left a comment (NeuroJSON/autobidsify#2) @jcohenadad and @AlexVCaron, I also want to mention a web interface for autobidsify developed by my programmer @elainefan331 this interface complements the python-based autobidsify by performing most of the metadata extraction and BIDSplan generation in the web browser (it reimplements the workflow using typescript), and leave the final conversion step by autobidsify or a compiled GUI @elainefan331 also added a "Private mode" in this interface, and requires users to configure local LLM. if the dataset is already deidentified, the web based autobidsify can save the data conversion as a project in our neurojson.io portal. check out the video tutorial Elaine created recently: https://neurojson.io/io/download/static/videos/autobidsify.mp4 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

Chris Rorden, PhD Endowed Chair of Neuroimaging Scientific Director, McCausland Center for Brain Imaging Department of Psychology University of South Carolina Columbia, SC 29208, USA email ***@***.*** web www.mricro.com

[AlexVCaron]

@fangq @yiyiliu-rose Tahnk you for all the precisions. The web-based interface is a nice touch ! I think we'll keep most of the processing local though, at least for sensitive datasets. Not a problem, the CLI works really well !

@neurolabusc Is BIDSVue available publicly ? I tried to find it on your lab Github. I'd be really interested in testing it and giving feedback as well !