dicomtonifti.exe fails when dicoms in series differ in bit depth

[dmgroppe]

dicometonifite.exe failed on series of dcm files from a Siemens Skyra MRI because the dcms on the extrema of the volume were 8 bits deep, but the majority of dcms in the middle of the volume were 16 bits deep.

I have never seen this issue before. Is it possible that the 3D MR was acquired with different bit depths? Or do you think was there an error exporting the dcms from PACS?

[dgobbi]

Was the failure a crash, or did you get an error message?

Sometimes a series will contain scouts, for example, an axial series might contain a single sagittal image that is annotated with parallel lines to show the location of each axial slice. I've also heard people call them "protocol images" because they show how the person operating the scanner planned the scan.

However, these "scouts" are usually 16-bit images like the rest of the series, and they usually have a different orientation from the rest of the series. So maybe in your case they are something different? What do they look like?

In any case, they were most likely created from the scanner console itself. It's very unlikely that they are the result of a PACS issue.

[dmgroppe]

Thanks for the speedy reply, @dgobbi .

The failure is an error message. It says "Bad DICOM file:" followed by the full filename of the first dcm it hits with a bit depth that differs from the first dcm.

I don't think the 8 bit scans are scouts. They appear to be part of the 3D series. I'll email you a couple of the files so you can see for yourself.

[dgobbi]

Got them. Yes, all files are part of a 3D acquisition, but for some reason BitsStored and BitsAllocated are both set on a slice-by-slice basis (for instance, BitsStored varies from 7 to 8 to 9).

For the MR Image IOD, the only value permitted for BitsAllocated is 16, so there's something funny going on with these images. Though I can probably modify the vtkDICOMReader to deal with them, since it already does slice-by-slice data conversion for other modalities e.g. for PET.

[dmgroppe]

Thank you very much, David. This makes me think that the files were miswritten by research-grade dcm software.

If this turns out not to be the case, we'll let you know.