DICOM attributes read failure with versions > 5.22.3

[ivoklaassen]

Hello,

Please find below, 2 DICOM files (one MR and one CT) that no longer can be read correctly with version 5.22.3,
but no longer with newer versions (> 5.22.3). To reproduce, simply perform a dcm2xml on both files:

For file 1.3.46.670589.11.10175.5.0.5200.2009011701432018188 the output of dcm2xml:
09:26:30,636 WARN - Unrecognized VR code: 0000H for (FEFF,00E0) - treat as LO
09:26:30,636 WARN - Unexpected attribute (FEFF,00E0) #19466 @ 1760
09:26:30,636 WARN - Unrecognized VR code: 0000H for (0000,0000) - treat as UL
09:26:30,636 WARN - Unexpected attribute (0000,0000) #0 @ 21234
09:26:30,637 WARN - Unrecognized VR code: 0000H for (0000,0000) - treat as UL
09:26:30,637 WARN - Unexpected attribute (0000,0000) #0 @ 21242
09:26:30,637 WARN - Unrecognized VR code: 0000H for (0000,0000) - treat as UL
.....

For file 1.3.12.2.1107.5.1.4.54246.30000009011605320221800005700.dcm the output of dcm2xml:

9:27:56,226 WARN - Unrecognized VR code: 0000H for (FEFF,00E0) - treat as LO
09:27:56,227 WARN - Unexpected attribute (FEFF,00E0) #2073 @ 1450
09:27:56,227 WARN - Unrecognized VR code: 1BF0H for (CDBC,E21B) - treat as UN
09:27:56,227 WARN - Unexpected attribute (CDBC,E21B) #997509023 @ 3531
dcm2xml: null
java.io.EOFException
at org.dcm4che3.util.StreamUtils.readFully(StreamUtils.java:74)
at org.dcm4che3.io.DicomInputStream.readFully(DicomInputStream.java:393)
at org.dcm4che3.io.DicomInputStream.readHeader(DicomInputStream.java:426)
at org.dcm4che3.io.DicomInputStream.readHeader(DicomInputStream.java:420)
at org.dcm4che3.io.DicomInputStream.readItemHeader(DicomInputStream.java:461)
at org.dcm4che3.io.DicomInputStream.readSequence(DicomInputStream.java:742)
at org.dcm4che3.io.DicomInputStream.readValue(DicomInputStream.java:595)
at org.dcm4che3.io.SAXWriter.readValue(SAXWriter.java:251)
at org.dcm4che3.io.DicomInputStream.readAttributes(DicomInputStream.java:576)
at org.dcm4che3.io.DicomInputStream.readDataset(DicomInputStream.java:503)
at org.dcm4che3.io.DicomInputStream.readDataset(DicomInputStream.java:487)
at org.dcm4che3.tool.dcm2xml.Dcm2Xml.parse(Dcm2Xml.java:305)
at org.dcm4che3.tool.dcm2xml.Dcm2Xml.main(Dcm2Xml.java:221)

DICOM files can be found over here during next 14 days:
https://filebox.olea-medical.com/pickup?claimID=JyrDsPPPMdnGHTk4&claimPasscode=P3X7kwVT6eHvvCHu  
Claim ID: JyrDsPPPMdnGHTk4
Claim Passcode: P3X7kwVT6eHvvCHu

Thanks a lot!
Ivo Klaassen
Olea Medical

[gunterze]

Seems (0009,1010) does not actual contain a Sequence as the entry

(0009,0010) VERS="GEM"	VR="SQ"   VM="1"	Owner="GEIIS"				Keyword="GEPrivateImageThumbnailSequence"	Name="GE Private Image Thumbnail Sequence"

in the private dictionary gems.tpl suggest.

You may workaround by removing dcm4che-dict-priv-5.xx.y.jar from the classpath.

[ivoklaassen]

Hi Gunther,
Thanks a lot for your quick reply!

Do you think this problem is related to the fact that the data has been wrongly anonyised/deidentified? Or do tou think this can happen in real clinical life?

Do you think dcm4che could be able to correct lecture of this tag by forcing use of dictionary VR in stead of VR as written in the file? As if the file would have been written with ImplicitVRLittleEndian?

Do you think you will address this 'bug' in a newer dcm4che version?

The problem for me is that I need the private dictionaries. BTW really really GREAT you added that s
tuff in recent versions!!
So either I decide to remove this kind of studies from my DICOM database (supposing this will not happen in real life) either I wait for a newer version. Knowing that I have quite a lot of series with
this problem.

Thanks again and have a nice day
Ivo Klaassen

[gunterze]

Do you think you will address this 'bug' in a newer dcm4che version?

Yes. Most likely, we will just remove the conflicting entry from the dictionary. Just want to verify the issue with David Clunie, who maintains these dictionaries in his dicom3tools, before.

[gunterze]

Just realized, that the private attribute actually contains a DICOM Sequence, but it is Big Endian instead Little Endian encoded:

$ xxd 1.3.12.2.1107.5.1.4.54246.30000009011605320221800005700.dcm | grep -A3 00000590
00000590: 0900 1100 4c4f 0600 4745 4949 5320 0900  ....LO..GEIIS ..
000005a0: 1011 554e 0000 1019 0000 fffe e000 0000  ..UN............
000005b0: 1908 0028 0002 5553 0002 0001 0028 0004  ...(..US.....(..
000005c0: 4353 000c 4d4f 4e4f 4348 524f 4d45 3220  CS..MONOCHROME2 

$ xxd 1.3.46.670589.11.10175.5.0.5200.2009011701432018188  | grep -A3 000006c0
000006c0: 0400 6e0a 0000 0900 1000 4c4f 0600 4745  ..n.......LO..GE
000006d0: 4949 5320 0900 1010 554e 0000 540a 0000  IIS ....UN..T...
000006e0: fffe e000 0000 0a4c 0028 0002 5553 0002  .......L.(..US..
000006f0: 0001 0028 0004 4353 000c 4d4f 4e4f 4348  ...(..CS..MONOCH

Seems the images got corrupted between the modality and the system which stored them to DICOM files.

[ivoklaassen]

I sent you 2 files. One SIEMENS and one Philips. I think you just had a look at the SIEMENS file.
All DICOM data I treat has been anonymized. Oftenly it's clear when DICOM data passed by very poor quality deidentifier software: no private tags at all, all private tags encoded as VR.OB, too many missing mandatory tags, ...
But this data seems to contain all private tags as well as their correct VR for most of them.
If it could help you, I could supply you with a zip of all series I can't read with dcm4che version > 5.22.3?
Of course one image per series or study.
Please let me know how I could help you.
Thanks again
Ivo Klaassen

[gunterze]

Looked in both (from Siemens and Philips), both the same. Don't think that Siemens or Philips include GE private attributes into generated objects - so it must have been happened somewhere after

[ivoklaassen]

Ah OK. See what U mean. Yes of course Philips or Siemens using GE tags does not seam to be evidently.
Will delete these studies from my database and have a look myself at the other data that's posing problems.
One more time: Thanks a lot for your time and help. Have a nice day!

[gunterze]

You may fix that files by trans-coding them to Big Endian using dcm2dcm without dcm4che-dict-priv-5.xx.y.jar in its classpath

dcm2dcm -t 1.2.840.10008.1.2.2 1.3.46.670589.11.10175.5.0.5200.2009011701432018188  BE.dcm

and trans-coding them back to Little Endian using dcm2dcm with dcm4che-dict-priv-5.xx.y.jar in its classpath

dcm2dcm -t 1.2.840.10008.1.2.1 BE.dcm 1.3.46.670589.11.10175.5.0.5200.2009011701432018188.fixed