Problems during Dicom import

[JoeCrozier (Joseph Crozier)]

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?

[JoeCrozier (Joseph Crozier)]

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.

[lassoan (Andras Lasso)]

@JoeCrozier

Do these settings affect when I initially “import” the dicom data, or only when I load it?

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.

[JoeCrozier (Joseph Crozier)]

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

Any other ideas or am I out of luck?

[lassoan (Andras Lasso)]

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

[JoeCrozier (Joseph Crozier)]

Just emailed you links to it. Good luck!

[lassoan (Andras Lasso)]

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.

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.

[JoeCrozier (Joseph Crozier)]

This is awesome! Thank you!

[pieper (Steve Pieper (Isomics, Inc.))]

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

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.

[Juicy]

Hi Andras,

I actually had an error recently where one of these “overview” slices caused the volume to mirror about the sagittal plane. I messaged Steve peiper but I can copy you in as well. This was using 4.10.2

Thanks

[lassoan (Andras Lasso)]

It would be great if you could test with today’s Preview Release if you can load your image correctly by using the loadables split by image type.

[JoeCrozier (Joseph Crozier)]

Works great! It still splits it like so:

but then it loads just fine like so:

Also didn’t crash when I first hit to load dicom

[lassoan (Andras Lasso)]

Happy to hear that it works well.

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).

[JoeCrozier (Joseph Crozier)]

Uh oh:

This was the “501” from the patient I sent you in email.

[lassoan (Andras Lasso)]

In advanced view, choose the loadables split by image type (see my screenshot above).

[JoeCrozier (Joseph Crozier)]

Nevermind, when i select to load the “content time 2” it works fine

[lassoan (Andras Lasso)]

Yes, you have now access to both the “overview” image and the 3D volume (as image type 1 and 2).

The overview image is a single-slice volume on an oblique plane. If you want to see the complete slice then it then click “Rotate to volume plane”.

[JoeCrozier (Joseph Crozier)]

Thank you so much for your help! Images aren’t lost anymore!

[lassoan (Andras Lasso)]

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.

@JoeCrozier

I have downloaded the nightly 4.11.0 and loaded the image set into the new DICOM module.

When I pressed load, an error message pops up suggesting that I examine the data in advanced mode. If I press load anyway at this point then the a normal looking volume appears except that it is mirrored.

Now if I close the scene, reload the image set again and open the advanced area I notice that the images have been separated by image type and image orientation patient. If I load the two image groups separately as shown in the following screenshot then two volumes appear. One volume is just the ‘orientation’ image and the other is the main volume which in this case has loaded correctly and is not mirrored.

I would like to have sent you the offending anonymised DICOM but when I run the images through DICOM cleaner it actually does not exhibit the same behavior anymore, which is frustrating. When loading the anonymised DICOM it is still mirrored but looks obviously broken.

I guess the main danger is that people seem to casually ignore warnings which they don’t understand and just see what happens. In this case one of our technicians did just that and because the volume looked pretty normal and because it is difficult to pick up mirroring about the sagittal plane a mirrored biomodel was produced.

Perhaps when that first window pops up then the user should be forced to look at advanced mode instead of being able to skip past it by pressing ok? Or maybe by default the images should be separated by image orientation patient and loaded as separate volumes so that if the user casually skips past the warning then at least there would be less danger of an erroneous volume appearing?

A colleague also informed me that he has seen this error occur before on another image set so I don’t think that it is a one off.

@lassoan

We could introduce a “strict mode” in application settings. It could prevent loading of data sets that have associated warning message.

@pieper

I’m seeing more and more of these pre-MPR’d series so I think we should find some way to detect and deal with them, but I don’t know if there is a good general solution.

What I think is happening here is that the orientation is coming from the first index image, and then the others are essentially sorted by some arbitrary value which sometimes is the exact opposite of what you want, hence the flipping.

Big picture though is that these reformats are not actually useful in Slicer anyway, since they just pre-compute views that you get anyway. So people should be using the original acquisition volume (typically one of the single-digit series, like 2,3,4, not 201, 801, etc).

Coincidentally, I have a study here that I can use to replicate, so I’ll investigate and see if there’s a fix possible.

@lassoan

It seems that “localizer” is the appropriate term for the extra slice (see this post and the ImageType containing “LOCALIZER” word and David Clunie’s DICOM faq).

In the discourse post referenced above, the series is a 3D XA spin reconstruction by Siemens. In this post the images are 3D XA spin reconstructions by GE. So, it is common that they are both 3D spin reconstructions and localizer image is stored in the same series, but image types are different:

Siemens:

• Localizer slice: DERIVED, SECONDARY, LOCALIZER, MPR, , , PARALLEL
• Volume slice: DERIVED, SECONDARY, AXIAL, MPR, , , PARALLEL

GE:

• Localizer slice: DERIVED, SECONDARY, REFORMATTED
• Volume slices: DERIVED, SECONDARY, REFORMATTED, AVERAGE

DICOM does not strictly specify how to organize series. According to the DICOM standard “Each Series may be associated with exactly one Frame of Reference IE, and if so associated all Composite Instances within the Series shall be spatially or temporally related to each other”. But this very loose definition makes it hard to implement software that can robustly interpret DICOM files, so I think the practice of storing different image types with the same series instance UID should be explicitly stated as valid or invalid in the DICOM standard.

@pieper Could you ask David Clunie’s opinion on this?

Also, would you mind if I copied the last few posts (without images) to the public forum topic?

@pieper

I agree, yes - the case I have here is the GE version, where the localizer (instance 1) is type 3 DERIVED, SECONDARY, REFORMATTED and the rest are type 4 DERIVED, SECONDARY, REFORMATTED, AVERAGE.

Interestingly, for the the localizer ImageOrientationPatient is 1, 0, 0, 0, 0, -1 while for the rest it is 0, 1, 0, 0, 0, -1. This makes sense since the localizer is coronal and the rest are sagittal.

Unfortunately we’re either going to end up with heuristics here or perhaps we need to have a more sophisticated user interface that makes it clear to the user what is going on and lets them decide.

For now I think the ScalarVolumePlugin should be hard-coded to detect this pattern (ignore a slice with one different image type).

Yes, I can ask David Clunie. We are at a meeting with him Wed-Fri this week.

It’s fine with me for this discussion to move to the public forum. This is something serious users should be made aware of.

@lassoan

David’s opinion (and eventually the DICOM standard) is important because based on that we could decide how to handle this: if it’s considered an invalid series then we would refuse to load it and add a rule to fix it in the DICOM Patcher; if it is a valid series then we need to detect the localizer slices in scalar volume plugin and ignore them by default.

localizer (instance 1) is type 3 DERIVED, SECONDARY, REFORMATTED and the rest are type 4 DERIVED, SECONDARY, REFORMATTED, AVERAGE

Note that “3” and “4” are just the multiplicity of the values and not part of the values.

@pieper

If it’s invalid we should definitely flag it, but I still would want to try to load it correctly if we feel we can do it confidently. This seems to be a common pattern. My guess is that David will say this is a valid series - it’s very common to have slices with different orientations, so the question is what part of the series maps to a valid Slicer scalar volume.

For most Slicer purposes, these reformats should be avoided in any case. In the study I’m looking at the series 8 is .8 x .8 x 1.0 while the reformat is .8 x .8 . 2.5. which makes is visibly blurry, but only if you zoom in, so I would avoid it for any kind of analysis or planning tasks.

[lassoan (Andras Lasso)]

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.