View Issue Details

IDProjectCategoryView StatusLast Update
0004146Slicer4Module DICOMpublic2018-06-11 16:07
ReporterpinterAssigned Topieper 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in VersionSlicer 4.7.0 
Summary0004146: Discover DICOM support provided by uninstalled extensions

There have been discussions at the 2016 winter project week about letting the user know which extension to install if they want to load a DICOM study that is not supported by Slicer core, but is by an extension.

  1. have an external project (like MultiVolumeExplorer or SlicerDMRI) to host all DICOM plugins
  2. update all plugins so that they have checks whether the module handling the logic implemented outside the python code is installed
  3. if the logic is not installed, give a guess whether the plugin can load the examine file, and notify the users which extension needs to be installed to proceed with the guess and try to interpret the series better
Additional Information

See more details at thread

TagsNo tags attached.


related to 0002779 resolvedjcfr Mechanism to keep track of the installed extensions across version 
related to 0004483 acknowledgedpieper Hint for helpful extensions during DICOM import is confusing 
related to 0004360 closedpieper Two popups after DICOM import 




2016-04-06 10:00

administrator   ~0013855

Yes, agreed there needs to be a good way to handle this.

I'm thinking that we don't want to have a single project for all dicom plugins since that would create an extra administrative step for an extension developer to go through when adding a new dicom plugin.

Instead I'm thinking that we might let extensions 'advertise' or 'declare' the types of operations they can perform using some kind of tagging infrastructure. In the case of DICOM this could be very explicit such, such as saying that it can interpret a particular SOPClassUID. Or it may list some tags that it thinks would indicate that it is able to interpret particular data. The DICOM module could query the extension manager before examining the files and detect if there is a likely extension for the data being examined and prompt the user to maybe install it.



2016-04-25 11:48

developer   ~0013861

Yes the external project approach would be additional burden, similar to how it works with ExtensionIndex.
It would be great if the extension manager could provide this information, but then we need to make sure that it's quick (cache it maybe) because examining the DICOM files by each plugin already takes a bit long.



2016-04-25 23:19

developer   ~0013862

Missed this discussion since I was not monitoring the issue.

I am not convinced reducing developer burden at the expense of imposing extra burden on the user (extra query time, internet connection) is a good idea. DICOM plugins are not added or modified as often as extensions. I think the idea of tagging extensions is a good one, but for operations like DICOM parsing is not optimal. I will think about this and discuss with Steve on Thu.



2016-05-06 13:51

administrator   ~0013865

Notes to file: Andrey and I had a discussion about the use cases, priorities, and complexities of various options. We decided that the simplest useful chunk of functionality should be implemented first and then we can see what needs to be expanded.

Here's my summary of the currently proposed feature set:

1) examine the dicom database to find the SOPClassUIDs of instances

2) look at a 'mapping' of those IDs to extensions

3) offer the user the option of installing the suggested extensions.

Tor the first feature, there's a question of when this happens. Is it during import, or examine, or after a failed examine, or failed load?

For the second should that have a plugin mechanism like the DICOMPlugin? Should the information be queriable based on attributes of in the ExtensionManager? Should it be hard-coded somewhere, like in a new repository?

As a first pass then, here is what I propose:

  • add a section to the DICOM Module's widget panel called Database Contents.
  • In there have a button called Examine Database.
  • When that is clicked, iterate through the instances in the database can check their SOPClassUIDs and present the user with a list of the SOPClasses in the database and and for each of the SOPClasses display a list of extensions that might help.
  • Offer a button that when clicked brings up the extension manager with those extensions offered for installation.

Because there are only a few extensions currently that offer DICOMPlugins, this mapping can be performed manually in the DICOM Module source code. Later it may make sense to create a convention for flagging extensions but that is overkill for now.



2016-05-06 14:18

developer   ~0013866

Steve, thanks for the summary, this is very helpful!

As a comment on the first pass - why not look up matching extension on examine, instead of your proposal to Examine Database? My doubts are that your plan will add new interface elements, and that the user will need to trigger the examine explicitly.

I am also thinking that even for the first pass it would perhaps be beneficial to match plugins by calling a function, and from the beginning have a capability to extend the lookup and make sure it can be done not only based on SOPClassUID, but any additional information plugin might need (I am specifically thinking about matching plugins to specific SR templates, which will have the same SOPClassUID).



2016-05-06 14:20

developer   ~0013867

Oh, another idea - instead of doing this at examine time, or adding a new interface elements, maybe we can do lookup at the time new data is imported into the database? This way it is done once, without explicit trigger, and at the right time.

Of course, practical limitation is that user will lose all extensions and plugins at the version upgrade, and database could be manually set from another instance. But perhaps even with those caveats examine for suitable plugins on import is a good thing to do.



2016-05-06 16:06

administrator   ~0013868

Thanks for the ideas! I like the idea of doing it at import time. This could also be augmented with a callback tied to the right-click context menu so if you wanted to do it after the fact you would have an option that wouldn't over-complicate the user interface.

The problem with Examine is that it's now hidden under the 'Advanced' feature so it would be weird for slicer to suggest extensions when it's just loaded something (i.e. for a PET file it would load fine by default but then we would be suggesting that they download the PETCT extension). Seems like an odd behavior.

Agreed about SOPClasses not being definitive, but the other use cases become wildly complicated very quickly, like an SR may have lots of templates inside and 4D volumes may come in many variants, which are conceivably manageable but still, there's a limit somewhere.


Regarding the issue of re-installing extensions with new slicer versions is being worked on by Denis of MeVis under Ron's direction. Jc and I did a hangout with him to discuss options




2016-05-09 17:58

administrator   ~0013869

To make things more concrete I checked out all the current extensions and looked for DICOMPlugin instances.

The results are compiled by hand in this json file.

There is not a lot of data here and it's not particularly hard to update this list as plugins are added and removed. I don't see a good way to automate this task unless the extension developers manually declare the Modalities or SOPClassUIDs they support, which ultimately is not much different than updating this file.

As I look at this file I wonder if it shouldn't just go into the DICOM Module source code directly for now. Once we have the rest of the features implemented (checking values during import) and if we see a need to make the data more current we could fetch the latest version of the file on the fly.



2016-05-09 19:56

developer   ~0013870

Thanks for working on this!

I support all the decisions above: do the check on import and add a context menu action for doing it explicitly, manual maintenance of the list (for the time being).

Looking at the json file I see the SRO missing from SlicerRT support:

  • SpatialRegistrationStorage: SOPClassUID (0008,0016) : 1.2.840.10008.
  • SpatialFiducialsStorage: SOPClassUID (0008,0016) : 1.2.840.10008.
  • DeformableSpatialRegistrationStorage: SOPClassUID (0008,0016) : 1.2.840.10008.
    Steve, can you please add these too?

Thank you!



2016-05-10 09:26

administrator   ~0013871

Thanks Csaba! List is updated.



2016-05-10 11:32

developer   ~0013872

I think this is a reasonable initial plan, looks good to me to proceed with the implementation. Thank you Steve and Csaba!



2016-05-18 15:31

administrator   ~0013882

Implementation notes:

  • can connect to directoryImported() from ctkDICOMBrowser

  • can add SOPClassUID to the list of tags to precache

  • For now the SOPClassUID can be assumed to be the same for all instances in a series. In general I'm not sure this is true though, since only the modality needs to be the same and some modalities might put two classes in the same series (PET/CT or some kind of ultrasound for example? although I don't think I've seen that in practice and it seems unlikely). See:

  • After directory import it should be enough to:
    -- go through all series in the slicer.dicomDatabase and getting the classUID and modality for the first instance in each series.
    -- compare that to the metadata in the json file linked in the earlier note
    -- collect a list of extensions that might help
    -- if nonempty ask the user if they want to go to extension manager and load these
    -- do so if requested


2016-05-18 17:34

administrator   ~0013883

Work in progress branch is here:

Currently is is able to create the list of extensions that match the descriptors in the json file.

Problem is that ctkDICOMBrowser generates two directoryImported() signals so the dialog is presented twice. Probably only fix is to add a new signal from the browser when the indexing is actually complete.

Also need to look at extension manager provide API that pre-fills the search box or otherwise selects just the matching extensions.



2016-05-19 20:09

administrator   ~0013884

Working version for testing:



2018-05-31 10:13

developer   ~0015866

Closing this issue, as the feature works - with some limitations.

There is a good summary of further developments that would make this feature much better, tracked in this issue:

Issue History

Date Modified Username Field Change
2016-02-02 12:07 pinter New Issue
2016-02-02 12:07 pinter Status new => assigned
2016-02-02 12:07 pinter Assigned To => pieper
2016-04-06 10:00 pieper Note Added: 0013855
2016-04-06 10:00 pieper Status assigned => acknowledged
2016-04-25 11:48 pinter Note Added: 0013861
2016-04-25 23:19 fedorov Note Added: 0013862
2016-05-06 13:51 pieper Note Added: 0013865
2016-05-06 14:18 fedorov Note Added: 0013866
2016-05-06 14:20 fedorov Note Added: 0013867
2016-05-06 16:06 pieper Note Added: 0013868
2016-05-09 17:58 pieper Note Added: 0013869
2016-05-09 19:56 pinter Note Added: 0013870
2016-05-10 09:26 pieper Note Added: 0013871
2016-05-10 11:32 fedorov Note Added: 0013872
2016-05-10 11:33 fedorov Relationship added related to 0002779
2016-05-18 15:31 pieper Note Added: 0013882
2016-05-18 17:34 pieper Note Added: 0013883
2016-05-19 20:09 pieper Note Added: 0013884
2017-04-06 14:57 pieper Relationship added related to 0004360
2017-12-20 17:22 pieper Relationship added parent of 0004483
2018-05-31 10:11 lassoan Relationship deleted parent of 0004483
2018-05-31 10:11 lassoan Relationship added related to 0004483
2018-05-31 10:13 lassoan Status acknowledged => resolved
2018-05-31 10:13 lassoan Resolution open => fixed
2018-05-31 10:13 lassoan Note Added: 0015866
2018-06-11 16:07 pinter Status resolved => closed
2018-06-11 16:07 pinter Fixed in Version => Slicer 4.7.0