I noticed that DICOM database gets re-indexed on the first launch of DICOM browser. I understand why this might be needed every time preview is launched, but if this re-index happens both in 4.10 and in preview every time I switch between the versions (even if I don’t touch the database). It takes several minutes for a small database with ~10 subjects and <10 series per subject. Is this the expected behavior or a bug?
This is expected but I agree that the wait can be quite inconvenient when you switch between stable and preview builds frequently.
@cpinter What do you think about saving database folder to the version-specific Slicer-NNN.ini when the user chooses to create a new database (and when determining the database folder, first DatabaseDirectory key would be first searched in Slicer-NNN.ini and if not found then in Slicer.ini)? This would allow using different databases for different Slicer versions.
Yes this is an inconvenience for sure. This makes me not want to use the stable, just to avoid the DB update.
I think what @lassoan suggests would be an acceptable solution. I will touch this part of the code soon (to make sure no dialog pops up when running automatic tests), and then I will do this too if this is OK.
2 Likes
Sounds great, thanks in advance.
Yes, this would be great. I actually didn’t realize it is not possible to have separate databases until I tried that as a workaround.
Would it make sense to even prompt the user to make a copy of the database at the time it is converted?
I think it would. However, these features will only be actually useful in the next 4 months, until RSNA and 5.0. After that, I hope that we won’t have to change the database for several years again.
It would be nice, but I am not that optimistic. It takes time for the extensions to get updated, for the users to develop confidence in new release. There are extensions that have not been updated for ITK5. Speaking for the extensions I’ve been contributing to, we are still far from fixing all those that were broken by the switch to python 3. Since coverage of python code in extensions is quite limited (at least for our extensions), many of those issues go unnoticed, and dashboard can be deceptive, until someone tries to use the module. And some of those python3 changes can be very tricky (at least to me). One example is here: segmentation export broken in 4.10.2 · Issue #240 · QIICR/QuantitativeReporting · GitHub. Realistically, we should anticipate users to turn to previous stable release for the functionality they are not able to find, for whatever reason, in the latest release.
I don’t think any developer would have the capacity support anything more than the latest stable and latest preview versions. We would want users to use the latest stable and report any errors that they find, instead of letting them to use old releases.
The current DICOM database schema is very good first step, but I expect many significant improvements in the DICOM browser in the coming years and some of them will require schema update (thumbnail support, custom comments, storage of any nodes in the database, etc.).
Yes, but, realistically, it does happen that developers that contributed functionality for a specific release no longer have resources to maintain or upgrade it for the subsequent release. Especially when those upgrades are non-trivial. You won’t have to try hard to find examples. Unfortunately, it is often challenging to secure resources for maintaining existing functionality - much easier to get money to develop “new” and “innovative” stuff …
Allowing users to have separate databases for different releases seems like a reasonable compromise. From personal experience, I know users often have multiple versions of Slicer installed to be able to use tools they like.
Just sharing my experience. You guys are the ones who do the work, so it’s your call what is appropriate to implement, given the resources you have available.
Back to the separate databases.
How would we prompt the user to save the existing database? What makes most sense to me right now is that there would be a directory selection window right after clicking “Update database”, and if a sensible (non-empty, not the same as the existing folder) is made, then copy the database there before updating.
After that, it would be up to the user to know that for the previous version they used before they updated the database with a new version, they need to switch to the database copy they just made. I don’t know if we can facilitate this in any way.
2 Likes
I think this approach is sensible. Along the points made by Andras, there is only that much user can expect from developers to support the use of multiple versions of Slicer.
Please see the implementation and its explanation in this PR:
1 Like