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.
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.
Yes, in general it will do it will do that, but only if the rotational difference led to more than 1/100th of a millimeter difference at the corners between the per-frame orientation and using the constant orientation throughout the volume.
You can disable “Allow loading subseries by time” to remove all the “… - contentTime X” loadables from the list (it is not necessary for you and adds a lot of clutter to the loadable list).
Note that you had problems loading secondary captures (with series number 500, 501, 502, and not with primary images that typically have series number 1, 2, 3, …). So, check loading of secondary captures, too, which has series numbers in the hundreds and odd slice count (e.g, “302: spin” acquisition containing 73 slices).
We continued the discussion in private and it came up that there is a risk that users ignore the warning that they get at loading and may proceed with loading the mixed localizer+3D volume slices, which may result in loading with incorrect geometry (mirroring). I copy posts from that private thread here below.
Yes, it is common to have different orientations (mostly in localizer series), but different image orientations are not the problem. What does not make sense for me is allowing storage of different image types in one series.
I’ve just found section C.8.16.1 of the DICOM standard, which seems to be applicable to all CT and MRI images. My interpretation is that if there are different types within a series then image type field must be set to “MIXED” and frame type contains the per-frame type information. The section also states “Image Type (0008,0008) and Frame Type (0008,9007) shall consist of four values.” which is also violated. The Siemens data set XA for image modality, so C.8.16.1 may not apply. However, the GE data set uses CT modality, so it should respect C.8.16.1.
Anyway, considering the creativity of how device manufacturers are (ab)using the DICOM standard, it would be important to update the standard and explicitly permit this usage (and then properly specify the expected behavior) or prohibit it.