Wishlist

[satra]

As part of the integration with dbic/reproin i think a few fundamental things have shifted. the intent of this issue is to start discussing return/augmentation/deletion of features. i'll list the ones we have interest in:

• parallel processing of participants (should be able to launch individual participant conversions in parallel)
• dicom connection to original dicom location instead of tarball (via hardlink)
• optional dicom linkage
• updated provenance model (dependent on nipype fix)
• nibabel handling of dcmstack work
• anonymization of dicom metadata when minmeta is not used
• anonymization of images across modalities (not just T1)
• crawling and grouping of dicom directories (not organized like a prisma output)

@yarikoptic @mih @mgxd - please add any other wishlists to this thread.

[yarikoptic]

Re crawling/groupping -- isn't it doing it already? I thought it does and even is "configurable":

  -g {studyUID,accession_number}, --grouping {studyUID,accession_number}
                        How to group dicoms (default: by studyUID)

Overall to me it is not clear which feature is return (let's use R), which is augmentation (A, and what kind?) or which deletion (D) or may be even a new (N, was I too young when may be heudiconv didn't use dcmstack? ;))... so I was to state the high-level wishes/what I would like to see

• A harmonize naming/specification of "heuristics" API:
  • document functions are mandatory for heuristic to have and what are optional (see e.g. Heuristic's infotoids is required with --files, but effectively isn't #197 for recent failure)
• N extend "heuristics" API to
  • make it possible for heuristic to inform heudiconv about its "optional modes" to use (currently exposed in cmdline options). E.g. heuristic might state that it is a BIDS heuristic, so there should be no need to specify --bids every time reproin heuristic is used
  • allow passing in cmdline or otherwise specifying (e.g. --heuristic-config somefile.yaml/json) heuristic specific options for any given conversion. I started to collect some which I see needed to be provided eventually for reproin, but might be implemented heudiconv wide I guess as well.
• A extend the list and functionality of auxiliary commands provided by heudiconv
  • e.g. --command ls could be super-useful to report additional dicom fields from "groupped" DICOMs (see above)
• A/N With the above in mind may be consider making heuristics into "plugins" of some kind, so multiple could be composed together, where some could provide some portions of the desired API (anonimization), while others the others (naming conventions)? (just a wild idea)
• A possibly get back to saving of hidden files that are not updated with changes to heuristic #84 and WiP Convergence on the use-cases analysis #134 and make choice of the mode (which stage, either to ignore previously created info files) available explicitly (not just automagically deciding on changed environment/sources, might be infeasible)

But what we IMHO really need is

• Tests -- more of unit and integration testing, because any of the above changes, if left not represented with intended use-cases in the tests, would just keep pulling the rope back and forth and would be counter productive

[yarikoptic]

As #200 shows, groupping issue is not entirely "solved'. An analysis and discussion will be done in #200 regarding that aspect

[mgxd]

adding #261 to this

Given a --subject (and --session) in a BIDS dataset, reconvert that subject/session using data in sourcedata/ (so .heudiconv/ info to not be used and recreated as well)