BEP: DICOM "file-format" support

[yarikoptic]

I think GitHub issues do not provide adequately powerful medium to discuss complex topics due to single threading etc. In DataLad, DANDI and other projects we adopted an idea of introducing "design documents" which take advantage from "code review" functionality of the GitHub by allowing for context-specific comments or recommended changes.
Hence I am submitting this PR to seek further discussion and improvements to the idea of such a BEP first.

Instructions for readers: click on 👍 or 👎 to express your opinion on overall idea

TODOs

• Allow for period of discussion/improvement
• File/mint an official BEP if the idea finds some support

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (03bec0e) 87.83% compared to head (b05d90f) 87.83%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1551   +/-   ##
=======================================
  Coverage   87.83%   87.83%           
=======================================
  Files          16       16           
  Lines        1356     1356           
=======================================
  Hits         1191     1191           
  Misses        165      165           

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[yarikoptic]

@neurolabusc please have a look at this BEP idea and please express yourself -- your experience and knowledge would be of the most value here!

[neurolabusc]

I am agnostic about this. The issue with DICOM is that it is like the English language, which is used differently by different individuals (e.g. pants means something different in the USA than the UK). Each manufacturer has its own definitions, can use terms like RepetitionTime differently, and uses private tags for a lot of details. This seems like an aspirational goal, but it seems like the initial work must come from harmonization efforts by the DICOM work groups.

Assuming a user wants to make a DICOM-based BIDS dataset, how does the BIDS validator work? Consider a Philips fMRI time series, where that manufacturer has no method for defining slice timing. What tool will be used to inject required details not in the raw DICOM? Do we need to define a generic set of tags to define these (presumably with the DICOM work group assigning a public tag)?

I think that dcm2niix (and dicm2nii, SPM) face the red queen problem: we must always update our code as the manufacturers change their DICOM implementation and our understanding of their usage evolves. Adopting DICOM simply shifts the burden of perpetual updating to other tools.

However, I also respect the view of @fedorov and his dcmqi does deliver on the promise of using DICOM directly for science. He started with the DICOM format, while many of the BIDS pipelines are wrappers for tools that do not support DICOM. Therefore, this would require a lot of investment.

[arokem]

This was mentioned as related in the BIDS OHBM town hall: https://github.com/ismrmrd/ismrmrd

[satra]

@arokem - i believe the scope of that file format was specifically for k-space data.

[arokem]

A clear case of "one person's raw data is another person's product"

[marcelzwiers]

The idea of dropping nifti (There should be one-- and preferably only one --obvious way to do it) and moving over sounds appealing to me, yes. But... that would require all(/most) common neuroimaging packages that even do not support BIDS out of the box (e.g. FSL) + the existing bidsapps to switch over to DICOM. I think hell will freeze over before that happens, while in the meantime we would create more chaos/incompatibilities...