Problem reading DICOM file

[Gian]

Hi all,

I"m using the DCMTK for reading DICOM data sets, which has been working great (kudos to the developers!).

However, I've recently come across a data set that the DCMTK appears unable to load. The same data loads into numerous other DICOM viewers, so I know the data is OK (may not be well formed ...)

Using the dcmdump utility (from 3.5.4), I see an error reading a sequence Item (fffe,0000) tag. By setting the +E option to ignore errors, the remainder of the file looks fine (all critical tags are present and reasonable). But ... there's no PixelData tag! According to the other tools I've used, the pixel data is there.

So, either there is a bug in the DCMTK, or the data is not well formed. Unfortunately, I really need to load this data as it's coming from a PACS provider that services numerous Hospitals we deal with.

I don't know what else to check (bit of a DICOM novice), so any help trakcing this down would be appreciated.

I'm happy to send sample slice from this data set if it will help.

Thanks,
Gian

[Jörg Riesmeier]

Please do so: Send a sample file to dicom/at/offis/dot/de.

[Gian]

Done. In the email I've also included the output of dcmdump.

BTW there is a typo in my original post - the error is happening when parsing the tag (fffe,e000).

Cheers,
Gian

[Jörg Riesmeier]

I checked the file with various tools (incl. DCMTK, dicom3tools and DicomEye). None of them could read the file completely.

[Gian]

Thanks for checking the file, it looks like it is not correctly formatted.

I've tried DicomWorks and the Sante Dicom editor, both of which seem able to read the file.

Is there some other way I might discover the PixelData?

Gian

[Marco Eichelberg]

There is no reliable way of detecting the pixel data for an defectively encoded DICOM image. In this case, the encoding is really messed up and it is not even clear what the encoder tried to do, i.e. there is no simple or obvious way of fixing the image. Patching the file at offset 0x720 by replacing four bytes with FF FF 32 02 makes the image "readable" to DCMTK by disabling all the messed-up part, but the offset and exact bytes will not be the same for other images even of the same series.

[Gian]

That seems reasonable.

Thanks for looking at the file,
Gian