View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002223||Slicer4||Core: CLI infrastructure||public||2012-06-19 18:19||2017-10-03 10:47|
|Product Version||Slicer 4.0.1|
|Target Version||backlog||Fixed in Version|
|Summary||0002223: 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.
|Tags||Summer AHM 2012|
@fedorov What do you think? Don't we have better approaches now for dealing with DICOM metadata in CLIs?
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?
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?
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.
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.
|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|