View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004146||Slicer4||Module DICOM||public||2016-02-02 12:07||2018-06-11 16:07|
|Target Version||Fixed in Version||Slicer 4.7.0|
|Summary||0004146: 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.
See more details at thread https://github.com/QIICR/Reporting/pull/71
|Tags||No tags attached.|
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.
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:
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
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.
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:
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!
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.
Working version for testing:
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.
|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|