Closed yarikoptic closed 3 years ago
Are you proposing to refactor some parts of ezBIDS / heudiconv and turn it into re-usable/sharable code (or service that runs somewhere)? Is the "heuristic code adapter" something that already exists in ezBIDS/heudiconv? Or is this the component that we will create?
hm, an interesting idea on having a service! so in some glorious utopian future if there is such a service, for which we figure out the API and data structures to exchange, we could expose various heuristics/tools as what/how they would like to have the DICOM (and possibly other) files auto-converted (or at least to give a starting point). Then users (and developers) would have ability to see how different tools (or specific optimizations, like a heuristic of heudiconv) would convert data.
Not yet sure if easily feasible though since reproin heuristic alone (the "meat" of which is here) is actually not "self-sufficient": a good amount of post-processing (handling multi-echo acquisitions, sbrefs etc) is done by general code of hediconv after using dcm2niix
to actually convert the DICOM series first. So something to think about on this as well.
And no -- there is no "adapter" yet for reproin ;) I am just exercising an idea here.
BTW how does ezBIDS handle e.g. multi-echo series, e.g. does it show to the user how those files would be named (with _echo-<index>
) if converted, or (like heudiconv) it just would enhance the name user provided with those extra echo
entities after conversion?
The only explicit naming heuristic that ezBIDS currently detects is ReproIn. This is done by checking for the expression _<entityLabel>-
within the acquisition SeriesDescription
metadata field. I'm unaware of other naming heuristics, but would be happy to incorporate them into ezBIDS. Other than the ReproIn naming heuristic, ezBIDS will search for vendor specific identifiers, for example, how Siemens uses the phrase tfl3d
to denote an anat/T1w
acquisition.
a good amount of post-processing (handling multi-echo acquisitions, sbrefs etc) is done by general code of hediconv after using dcm2niix to actually convert the DICOM series first. So something to think about on this as well.
This is also the general structure that ezBIDS uses to detect relevant BIDS information.
BTW how does ezBIDS handle e.g. multi-echo series, e.g. does it show to the user how those files would be named (with _echo-
) if converted, or (like heudiconv) it just would enhance the name user provided with those extra echo entities after conversion?
ezBIDS handles multi-echo (and other) entity labelling with the entity_labels_identification function. Regarding echo
specifically, that's done here, where the EchoNumber
value becomes the echo
entity label value. However, we exclude magnitude, phase, phasediff fieldmaps from this, as their echo numbers are irrelevant. This information is all ported to the web UI, where users can make any changes they'd like before finalizing everything into a BIDS-compliant dataset.
This is a hypothetical idea ATM, and not yet sure how to interface (from ezbids JS to e.g. heudiconv's reproin in python) but thought to initiate dialog ;)
ezBIDS performs a first-pass attempt at datatype, suffix, and entity label(s) identification through it's analyzer, which is in python. Once users make edits/modifications in the UI though, we switch over to JavaScript. So persumably there should be an avenue for interfacing the python portion of ezBIDS with heudiconv (and others).
I wonder if that would be possible to add to ezBIDS so whenever new data comes in, and a specific "naming heuristic" is chosen, ezbids would "interface" to the heuristic code adapter (e.g. provide DICOMs metadata etc), and receive target desired filenames in return.
This is a hypothetical idea ATM, and not yet sure how to interface (from ezbids JS to e.g. heudiconv's reproin in python) but thought to initiate dialog ;)