View Issue Details

IDProjectCategoryView StatusLast Update
0002223Slicer4Core: CLI infrastructurepublic2017-10-03 10:47
ReporterAnthonyBlumfieldAssigned Tomillerjv 
Status assignedResolutionopen 
Product VersionSlicer 4.0.1 
Target VersionbacklogFixed in Version 
Summary0002223: Feature request: option to pass to CLI the full path name of a DICOM file from the DICOM series containing a volume.

Currently if slicer executes an executable CLI and passes it a DICOM volume loaded in slicer, the CLI has no access to the DICOM metadata. To resolve this problem, this proposed feature will add an option for the CLI to request the path of one (e.g. the first) DICOM file in the series containing the volume.
Details: Add a hidden parameter to --xml called DICOMReference that is associated with the CLI input volume file.

TagsSummer AHM 2012




2017-09-27 13:55

developer   ~0015191

@fedorov What do you think? Don't we have better approaches now for dealing with DICOM metadata in CLIs?



2017-09-27 14:25

developer   ~0015197

I don't think we have anything that would address this concern. There is no connection between CLI and the source DICOM dataset. We have not looked into this so far, and I don't have a good plan for this at the moment. I think adding a parameter to allow CLI to request DICOM representation for an input argument (if available) would be a useful feature. Did you have anything specific in mind when you thought about a better approach?



2017-09-27 15:28

developer   ~0015207

As far as I remember you use some CLIs in the QIICR project that use additional metadata files. Not a very clean solution but probably there was a good reason you chose it. How well that works for you?

adding a parameter to allow CLI to request DICOM representation for an input argument (if available) would be a useful feature

There is no easy mapping between a node and files. Even between mapping between a node and associated DICOM IDs is not trivial, but manageable.

We could implement passing additional metadata for nodes that contain custom attributes (such as DICOM IDs) and URL of the DICOM database. CLIs then could get some basic tags and filenames from the database. Passing the database would have the advantage that CLIs could also write into the database.

Anyway, all these solutions are quite far off, not for the upcoming stable Slicer 4.8.



2017-10-03 10:47

developer   ~0015242

We discussed this at the Slicer developer hangout. The best option seems to be to provide a URL to a DICOM-web database. This solution would be standard (Slicer-independent), generic, and scaleable enough.

Issue History

Date Modified Username Field Change
2012-06-19 18:19 AnthonyBlumfield New Issue
2012-06-19 18:30 jcfr Tag Attached: Summer AHM 2012
2012-06-19 19:04 fedorov Status new => assigned
2012-06-19 19:04 fedorov Assigned To => millerjv
2012-08-22 05:56 jcfr Target Version => Slicer 4.3.0
2013-09-02 13:03 jcfr Target Version Slicer 4.3.0 => Slicer 4.4.0
2014-05-13 20:47 jcfr Target Version Slicer 4.4.0 => Slicer 4.5.0-1
2015-11-02 11:27 jcfr Target Version Slicer 4.5.0-1 => Slicer 4.6.0
2016-10-12 14:42 jcfr Target Version Slicer 4.6.0 => Slicer 4.7.0
2017-09-27 13:55 lassoan Note Added: 0015191
2017-09-27 14:25 fedorov Note Added: 0015197
2017-09-27 15:28 lassoan Note Added: 0015207
2017-10-03 10:47 lassoan Target Version Slicer 4.7.0 => backlog
2017-10-03 10:47 lassoan Note Added: 0015242