Hmm, you're right - it makes sense to bypass all the other checks and go straight to the node.

Do you want to go ahead and change the scalar volume plugin to use the node instead? Feel free to do so if you want, otherwise I can do it when I have time. Speeding up the general load speed would be much appreciated.

-Steve

On Thu, Aug 9, 2012 at 11:24 AM, Andriy Fedorov <fedorov@bwh.harvard.edu> wrote:
On Thu, Aug 9, 2012 at 11:13 AM, Paul Mercea <pmercea@bwh.harvard.edu> wrote:

Makes sense and this is what I did too but I didn't set the file name of the
first file. I was setting the loadable.name as file name. It works now and
loading for single PET image is 3 times faster. Thanks.

Steve, is there a good reason why DICOMScalarVolumePlugin is not using
VolumeArchetypeStorageNode

https://github.com/fedorov/MultiVolumeImporter/blob/master/MultiVolumeImporterPlugin.py#L147

and instead uses loadFilesWithArchetype() from Volumes logic?

https://github.com/Slicer/Slicer/blob/master/Modules/Scripted/Scripts/DICOMPlugins/DICOMScalarVolumePlugin.py#L275

In my and Paul's experience, using storage node dramatically improves
load speed, and for that reason we avoid using ScalarVolumePlugin
load() functionality in our plugins.

Since in scalar volume plugin we know that we need to read a scalar
volume, I do not see why we need to go over all those checks in
volumes logic. I think we talked about this before, but I don't
remember what was the reason, or if there was one.