We just started using Slicer and ran into the following issues:
Slicer 4.10.2 Tests
-loaded image stack without overview image (both with and without “apply regularization transform”)
-get error: Irregular volume geometry detected, but maximum error non-zero but is within tolerance (maximum error of 1.34414e-05 mm, tolerance threshold is 0.001 mm).
This is very surprising, as un recent years we have not had any reports of Slicer crashing when attempting to load DICOM data.
Please try the latest Slicer Preview Release, as we continuously make improvements to the software.
If you still experience any DICOM loading issues then please send us (upload somewhere and post the link here) the application log where a crash occurred. You can retrieve application log of previous sessions in menu: Help / Report a bug. You can inspect the text before uploading and remove and patient information from it (do not remove complete messages, just replace any identifiers by some placeholder text).
I installed the latest Slicer Preview Release (5.3.0) and now sometimes the DICOM files load successfully and in about 30% of times Slicer crashes.
You can find two application logs in the link below. One is a crash log, the other a log of when it loaded successfully. The read me file describes which log is which case.
The logs shiw that the images were anonymized incorrectly (patient ID is a required field and it is not allowed to be empty). It indicates that inappropriate software or settings were used or they were used incorrectly, which may have caused unexpected errors during loading. You may consider ask for the data set again, making sure that the person is doing it has the necessary expertise.
What is the size of the image you are loading (in voxels)? Does s the crash occur when the import is finished or later, when you try to load the image?
Thank you Andras.
I am working together with Dennis on this project.
Good point about the patient ID field. I got the scan from a surgeon and I am not sure how he removed the patient ID. I will ask him to redo the deidentification and replace the patient ID with a random number instead.
The crash occurs after import, when trying to load the files.
This happens on Dennis’s machine (CPU only) and I also tested it on my work and personal laptop (both have GPU and different ones). The file size is not that large anyway. So I think we can rule out any computer specific issues.
I just used https://www.microdicom.com/ to adjust the patient ID.
(upload image, go to View > Dicom tags, edit ID, then ‘apply’ making sure ‘patient’ rather than ‘image’ is selected)
please note this operation is destructive (it will directly change your files) so make sure to first make a copy of your image stack!
The dataset now loads in 5.2.2 (I tested it with the overview image removed, but I think it would also work with the overview image).
@lassoan would it be possible to add some sort of dicom tag editing support in future versions of Slicer? I imagine this could be useful for image deidentification too.
Anonymization is an extremely complex topic, as you need to be very careful in removing all protected health information while still keeping the data sets usable. For example, you cannot simply replace the patient birth date with some random number but you need to add a random offset to the patient birth date and all study creation/series acquisition date fields, consistently in all studies of that patient. You cannot simply remove unique identifiers but you need to replace them with study-specific identifiers and store the mapping in access-controlled files. You need to inspect image content - remove all burnt-in annotations (typical in secondary captures), remove/blur patient face or other unique features that can identify a patient, all that in a way to not interfere with proper use of the inage. You need to pay close attention to private fields - simply removing them can make the data set unusable, so you need to investigate what each field contains (in DICOM conformance statements of each vendor) and consult with users of the data to determine what is needed and what needs to be changed or removed.
So, proper anonymization requires not just simple editing of some DICOM fields, but it requires complex software suite and significant expertise to operate it.
That’s likely the reason why on my machine, I can’t get the files to successfully load consistently. Neither adding a patient ID with MicroDicom nor “re-cleaning” the data with DicomCleaner (default settings) did the trick. The files were likely corrupted during the initial anonymization. We’ll make sure that we’ll get correctly anonymized DICOM files from the clinic in the future.
However, I noticed two interesting phenomena:
Immediately after testing if I could load the corrupt files consistently (crashed 40% of times), Slicer crashed while loading a publicly available DICOM dataset. After the initial crash, the dataset successfully loaded consistently.
The first time I tried to load the “re-cleaned” (with DicomCleaner) dataset, it loaded the publicly available DICOM dataset, even though I had previously deleted that from the DICOM database in Slicers “Add DICOM data” module.
Thank you @lassoan
We have spoken to the clinicans and they will ensure the anonymization is done properly in the future.
Regaring the issues loading the scans, could it be possible that some data is somehow saved in the SlicerDicomDatabase or some other cache and that is somehow trying to load a previous dataset?
Maybe that could explain the issues Dennis was having with the visible human dataset (Visible Human Project CT Datasets | Magnetic Resonance Research Facility) and the loading of the wrong files.
Yes, it is possible to pollute the database with corrupted data. DICOM is not a file format, but a distributed database. Data objects can be stored in files and cross-referenced with unique identifiers. If you modify a file (e.g., remove patient name) then you must update the unique identifier of that object in the file. If any other DICOM object referenced the modified object by UID then that object must be updated as well (and a new UID must be generated for it, and any object that referenced these modified objects must be updated as well, etc.). Slicer (and most other DICOM software) will ignore any new file that have the same UID as a previously indexed file.
If you only have images (you don’t have any segmentations, treatment plans, etc. referring to those images) then you may not need to update any references. However, you still need to replace the UIDs in all modified objects. Typically, you need to regenerate patient ID, study instance UID, frame of reference UID and use them for all the series in the study; regenerate series instance UID and use it in all files of the series; and regenerate new SOP instance UID for each DICOM file.
DICOM is very complex, but it also provides a lot of functionality (data provenance, metadata, references, etc), so it may worth investing time into learning it and setting up data processing workflows properly.
