Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

a command to list DICOM attributes of interest in a pile of DICOMs #526

Open
yarikoptic opened this issue Sep 16, 2021 · 1 comment
Open

Comments

@yarikoptic
Copy link
Member

attn @loj

quite often it might be very handy to get a quick idea about some metadata within the pile of DICOMs. E.g. for establishing a heuristic or mapping into reproin heuristic like here might be relevant to quickly list values of series_id, protocol_name, image_type. ATM it requires to run -c none to get the dicominfo.tsv dump, and then inspect. That should be produced on drive for each subject(/session). For a quick "glance" I think we need some easier accessible command.

We could extend the list of the ad-hoc commands

  --command {heuristics,heuristic-info,ls,populate-templates,sanitize-jsons,treat-jsons}
                        Custom action to be performed on provided files instead of regular operation.

In principle it should be possible to add a new command but we also already have ls which takes ls function defined in a heuristic. (Only) reproin has one. And I would say that code to support ls might be a bit "overfitting" reproin use case. I think we could pretty much move most of ls code from process_extra_commands into reproin.py:ls and then extend convertall to provide its own desired listing from the kwargs it would get.

  • Problem: above commands cannot be passed some other arguments than generic heudiconv arguments (the beast grew organically ;)) ... if outputs in .json format, piping to some json handler (jq) or even just grep might be sufficient for some cases
  • thought to (ab)use fscacher here but probably should be done at a different level, not ls specific anyways.

Overall -- not yet sure about the best easiest design to proceed with or what information to output.

@satra
Copy link
Member

satra commented Sep 16, 2021

perhaps this is a better place for something like this: https://github.com/open-dicom/dicom_parser also dicom_parser is where the grouping function of dcmstack is headed, so may be worthwhile thinking of a removal of dcmstack and using dicom_parser.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants