Yes, good idea.

Why not default to ScalarVolume and give opt-in to use other available plugins? If a plugin is selected, then examination could be done. I think something other than ScalarVolume is a relatively rare case and should not penalize the common use case.

Not to mention, the list is confusing because the ScalarVolume plugin makes individual entries for each contentTime within the same series.

We need plugins for any RT data set reading (structure set, dose, etc.), so it's not a rare case at all.

But I agree that the splitting based on content time is a rare use case (I've never come across anything that would have needed that), so maybe that could be disabled by default.

Relatively rare use case for some, but others use other importer plugins every single use.

What's the problem with keeping the way it was? The plugins return confidence values, and the plugin with the highest confidence gets to examine each loadable first. If you have regular volumes, then they will be assigned to the scalar volume by default. If you have other types of data, then the most suitable plugin will be selected. I think this mechanism works really well.
I don't understand why it would be better to default to the scalar volume plugin in case of RT structure sets for example.

@Andras: The content time separation indeed clutters the list a little, but as they are unselected by default, and as they are at the bottom, it doesn't bother me much.

I guess Isaiah mentioned disabling plugins because it would make the examine faster, so auto-examine would not slow down the user interface that much.

The content time splitting maybe not just clutters the screen but it might also have a performance impact.

If the examination is made automatic then please keep the option to disable plugins. You are right, everyone will have a different set of defaults.

But more fundamentally, shouldn't the examination be run on import and cached in the database? yes there is the case where other plugins are available that were not installed at import time, but the "Examine for loading" could still be provided as a fallback.

Thanks for the thoughts on this. I agree we can rework this.

Yes as some background thoughts:

• the multiple content time breakouts of the scalar volumes was a mainly for 4D data before the multivolume plugin existed. But there are still times when people get a dual-echo acquisition and want to split it. It doesn't add to the time since it's just a different sorting of the same data.

• I would like to move to a place where the examine step goes on in the background and/or gets cached to the database.

• the priority mechanism of the plugins is still being used so it should adapt to whatever you currently select.

• it would make sense to have the state of the plugin selection stored in the qsettings so that people who only wanted scalar volumes would have a fast path.

Alireza and I are meeting tomorrow afternoon to review the dicom redesign so please add any additional input.

Storing the plugin selection would be simple to implement and could help a lot (and people kind of expect that this selection is stored).

Caching the examine results would help a lot but also very complex to implement. Mostly because some plugins internally store additional information that they obtained during examine and they use during loading. All the plugins should be rewritten to not rely on any of these private information during the loading phase.

Please take a look at the video at the following link:

http://youtu.be/cZZPFw1uwC0

I added an advanced option for users who want to examine with plugins before loading. The general users will use the non-advanced mode which gives more space for the tables and also auto-examine with just scalar volume plugin.

This is a work in progress so please give your feedback on design and usability.

Very nice, I like it! Thanks!

It looks good. Please integrate it ASAP, because the current browser is practically unusable.

Topic pushed to https://github.com/mehrtash/Slicer/tree/3587-allow-auto-examine-dicom-browser

Great, thanks, looking forward to trying it!

I've tried the new browser.

It's great that clicking on examine is not needed anymore.

Remaining issues:

• Clicking on the patient then clicking on load has no effect, while it should load all the data available for that patient (similarly, clicking on a study then on load should load the whole study).
• “Load” button is still small and hard to find. If we keep the button so small then give it some different color or place it in a more prominent position.
• It would be great to be able to load a single patient, study, or series by double-clicking on it.

There is a profound problem with the way the "Advanced" option can be used.
If you want to use a "non-core" DICOM import plugin, then without checking the Advanced checkbox, the plugin is not used, but when you check the Advanced option, then all the plugins are marked as used.

The problem with this, is that clicking the Advanced option actually changes the settings, instead of just showing the advanced section. There are two options here that I see:

1. Don't use the non-core plugins without Advanced, but add a warning message (if there is at least one such importer present) that those are not used without checking them in the Advanced section. When you click on Advanced, then those plugins should not be checked, and allow the user to check the ones needed
2. Use all importer plugins by default. Is there a good reason not doing so?

I completely agree with Csaba. Having a different behavior just because the Advanced option is chosen is not a good idea and also disabling plugins when the basic GUI is used would cause problems to many users.

A possible solution:

• Always use all the non-disabled plugins for loading.
• Allow disabling plugins using the Advanced interface.
• The list of disabled plugins are stored persistently in settings (ini) file.

I just built the latest and noticed that I could not load any of the RT data.

I was able to make it work by forcing a re-scan of the data types.

I don't think that disabling external plugins by default is the right choice as it breaks any extension based Slicer usage by preventing them from loading data. It seems unreasonable for extension developers to ask users to tick the advanced box just to make an extension work.

My vote would be to have an optional checkbox for disabling plugins.

Exposing some of the options programatically would be nice too, so developers that don't want external plugin readers could disable them from code.

Steve, can we increase the priority of this issue? Our extension is virtually unusable on the nightly until we handled this issue.

Thanks everybody for your feedback. I fixed the issues based on your inputs and it is ready to merge in Slicer here:
https://github.com/Slicer/Slicer/pull/122

Great, thanks!
Can you please summarize your decisions based on the feedback you got?

Can you please summarize your decisions based on the feedback you got?

Hi Csaba,

The default behavior would be that the scalar plugin is activated and all others are deactivated. Changing the plugins in advanced mode would be saved in Slicer qsettings (Slicer.ini). As Andras suggested I can change the behavior to all-activated by default but I would like to have everyone's view before changing that. You can give feedback at Github:
https://github.com/Slicer/Slicer/pull/122

Thanks

Fixed and Merged to slicer svn r23109

Hi Alireza,
I tried the browser and now the plugins work well without having to check the Advanced button. Thanks for the fixes!

I have found two (not huge) issues though:

1. When you change to horizontal tables, and make the window larger, then you'll end up having a lot of unused space:
   https://dl.dropboxusercontent.com/u/3143581/screenshots/20140424_DICOM_Browser_Horizontal_Tables.png
   The height of the tables don't change, which results a very wasteful window layout especially on larger resolutions.
2. When you open the DICOM browser without changing any settings, it looks like this:
   https://dl.dropboxusercontent.com/u/3143581/screenshots/20140424_DICOM_Browser_Default_Appearance.png
   Not a big deal, but the user won't be able to see anything by default but some cramped UI elements.

Should I create Mantis issues for one or both?

Any thoughts about the last comment?

Hi Csaba,

I fixed the the issues here:
https://github.com/Slicer/Slicer/pull/128
Hopefully it is going to be merged soon.

Thanks,
Alireza

Thanks, auto-examine works now as expected.