Provide support for "naming heuristics" like ReproIn?
yarikoptic opened this issue · comments
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 ;)
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).