Problems during Dicom import

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.

1 Like

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


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.

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

1 Like

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

Uh oh:

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

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

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

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

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

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.