@jcfr Very good, thanks for testing. Do you have time to implement this properly in your branch?
At least we should create beginTagCacheTransaction() / endTagCacheTransaction() methods. Maybe also update the code to do all tag cache updates in one transaction per directory or per import session - if it makes things much faster. To test, you might use a slower computer or larger data set (e.g., from http://www.cancerimagingarchive.net/), as your few-second import times are already very good.
Makes sense.
I do not have the bandwidth to address this. In the mean time, I integrated the topic and will update Slicer.
Thank you. I’ll follow up with another pull request if I find that further optimization of transactions make a significant impact.
I imported more or less 60 MR multislice images with about 1000 400x400px slices for a total of 10 Gpx and it took 2 hours.
Is it normal? Is it not?
Thank you.
A CT volume is imported and loaded from DICOM files in about 10-20 seconds on an average computer (using Slicer or most other medical imaging software). Since size of this data set is equivalent to about 600 CT volumes, 120 minutes may be normal.
Since the size of this data set is extreme, your computer will need to have extreme specifications if you want to have good performance. You would need at least 32GB physical RAM but preferably 128GB if you want to manipulate the volume. You would also benefit from fast SSD storage.
You can access the data 1-2 magnitudes faster if you store the data in nrrd format. Make sure you disable compression.
What would you like to do with this data set?