Problems during Dicom import

Slicer Version 4.11.0
Windows 10

Hello, I’m having trouble when importing dicom files, specifically files that have been stored on google drive and downloaded. Let me explain:

Normally I bring dicoms over to my workstation on a usb or similar direct transfer method. When I import them, they work great, as expected.

Recently I’ve been working on a project where the images (that loaded correctly into slicer on someone else’s computer) were then uploaded into google drive (staying in their respective folders) and downloaded onto my computer, and I’m having trouble importing them.

Obviously this may be a google drive problem, but I’m wondering if there is anything I can do on the 3dSlicer end to fix this, here’s what happens:

Lets say I’m trying to import these images:
image

Everything in that folder should be just one series of coronal face CT scan images.

3d slicer reads it as one series:
image

But then splits it into a million “chunks”:
image

When I load one of those, it seems like it is a “few” of the total images, or something wrong like that:
image

Any idea how to tell 3dSlicer “No, those all go together”. Again, when imported on the original computer (before going to google drive, but in the same overall folder structure) it imports correctly.

Could you please try with latest Slicer Preview Release? We have completely reworked DICOM infrastructure recently.

The 4.11.0 that was built on 2019-11-07? Will do, and will report back.

1 Like

Well, um… that didn’t work. In fact, when I open slicer and see the welcome screen, the second I hit “load dicom data” it closes the programs. Just instant crash.

This is awesome. I’m trying to get a database that causes crash on startup (it happened to two other users). Could you zip the content of your DICOM database folder and send me in a private message (click on my name and the email icon)?

When you opened the new preview release of Slicer, was another Slicer instance still running?
If you go to menu: Edit / Application settings / DICOM section. What folder is shown as Database location?

You can fix the crash by choosing a new empty folder as “Database location”.

Haha glad I can help, but not sure I’d call it “awesome” haha.

No other instances were running. The folder that’s shown as the database location is:
C:/Users/MyName/Documents/SlicerDicomDatabase

Will zip and send you database in two seconds.

1 Like

Sent the zip in email. Choosing new empty folder for database location prevented the crash, but the new dicom system didn’t fix the original problem:
image
Still loads the one folder as a bunch of different chunks

Can you right-click on the series, choose to view metadata, and search for “ImageOrientationPatient”? If you move the slider to browse slices, the value should remain exactly the same.

It does not. When I move the slider, the numbers don’t change a ton, but they do “wiggle”.
For example:
This is 17/181: [6] 0.9999975562, 9.125343058e-05, -0.002207435435, 9.117864101e-05, 0.9965941906, 0.08246236295
This is 18/181: [6] 0.9999975562, 9.125343058e-05, -0.002207510173, 9.110382234e-05, 0.9965941906, 0.08246242255

@JoeCrozier is this a google drive file stream? If so, you might need to pin the files onto your system and wait until it downloads.

image

No I don’t believe it was a file stream. I had trouble simply “downloading” from google drive (for other reasons, it took forever to zip) so eventually the way that got on my computer was through the google “Backup and Sync” app, and I believe everything was fully downloaded.

Again, I realize this might be a google problem that scrambled something, but is there anything we can do on the 3dSlicer end to fix it?

OK, the difference in slice orientations explain why Slicer shows all those loadables separately. You can disable showing these (just to clean up the view a bit), in Application Settings / DICOM / Allow loading subseries by time.

Then, enable “Acquisition geometry regularization” and try each “DICOM reader approach”.

What software has created these files?

@pieper Does acquisition regularization can fix up series with not-exactly-parallel slices?

The files were originally exported out of Terarecon from our hospitals PACS server. I’m not sure what original scanner made them or anything. And again, when first exported out of terarecon and opened in 3dSlicer (on a different computer) they opened fine. The problem is the student who was working on them (and had 3dslicer to view them on their computer) shared them with us(a resident and I) by uploading them to google drive. I don’t believe they did anything to modify them prior besides dragging and dropping from their computer to google drive. When I simply go to google drive and click “download” I run into this problem: https://support.google.com/drive/thread/4965355?hl=en seems like a bunch of people have trouble downloading from there.
So anyhow I then finally was able to download them using the google “Backup and Sync” app, but once they are on my computer they run into the problem we’ve discussed.

To clarify your most recent suggestion:
Allow loading subseries by time was initially turned off when I first went into the menu, and i just clicked to turn it on. I’ve also attempted using each of the dicom reader approaches.

Also acquisition geometry regularization was initially on and I’ve tried it both on and off.

So far it still looks weird. Do these settings affect when I initially “import” the dicom data, or only when I load it? In other words, should I delete the scan from my database and reimport it after changing settings?

Further details: I’m not sure they’re still on our hospital server (or we can figure out who they were prior to randomization) and I know they’re not on the student’s computer for me to get via usb. So I’d love to salvage these scans in whatever way I can.

These settings only affect loading, so you don’t need to reimport, but you may need to restart Slicer for the changes to take effect.

Hmm. Restarted it each time it prompted, and kept loading weird.

Any other ideas or am I out of luck?

There are a couple of more things to try, but it is easier if we can have direct access to the data.

Just emailed you links to it. Good luck!

The reconstructed series contain an “overview” slice, which is an orthogonal cross-section of the reconstructed volume, showing each slice position. Since this cross-section image has the same series instance UID, appears to have valid position, orientation, etc. it is lumped together with all the image slices, therefore breaking the reconstruction.

The overview slice has different orientation than the other slices, which would normally be usable to weed out an outlier slice. However, in this case the 3D slices don’t have the exact same orientation either, so this mechanism could not be applied.

The only field that is clearly different between the overview image and 3D slices is ImageType (0008,0008). Since ImageType is expected to be the same among all slices and we have seen such overview images breaking DICOM import before, I’ve added ImageType field as a subseries grouping field, this will allow load the overview slice and 3D volume as two separate images.

I’ve tested it on your images and it allows correct loading of the images. This new feature will be available in Slicer Preview Release that you download tomorrow or later.

image

I’ve implemented a fix for the crash that occurs when an old database is attempted to be opened. It’ll be available in tomorrow’s preview release, too.

2 Likes

This is awesome! Thank you!