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.

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.

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.

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.

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).

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.

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

https://www.slicer.org/slicerWiki/index.php/Documentation/Labs/AutomaticUpdateAndInstallationFramework

]]

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.

https://github.com/pieper/SlicerDICOMAdvisor/blob/master/DICOMExtensions.json

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.

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.5.1.4.1.1.66.1
• SpatialFiducialsStorage: SOPClassUID (0008,0016) : 1.2.840.10008.5.1.4.1.1.66.2
• DeformableSpatialRegistrationStorage: SOPClassUID (0008,0016) : 1.2.840.10008.5.1.4.1.1.66.3
  Steve, can you please add these too?

Thank you!

Thanks Csaba! List is updated.

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

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: http://dicom.nema.org/medical/dicom/current/output/html/part03.html#sect_A.1.2.3

• 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

Work in progress branch is here:

https://github.com/pieper/Slicer/tree/4146-add-dicom-advisor

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.

Working version for testing:

https://github.com/Slicer/Slicer/pull/504

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: https://issues.slicer.org/view.php?id=4483.