ezDICOM: Explicit VR - Big Endian

[Mathieu Malaterre]

Hello,

I received yet another buggy DICOM file today:

http://www.creatis.insa-lyon.fr/~malaterre/gdcm/c_vf1001.dcm

According to the user it was written using ezDICOM. Has anyone seen
something like this before, and is there people supporting this type of
bug ?

Thanks
Mathieu
Ref:
[Insight-users] Problem in reading a clean DICOM file
http://public.kitware.com/pipermail/insight-users/2006-October/019879.html

[Marianne]

Hello Mathieu,

I checked the file. Indeed it is little-endian, but the Transfersyntax
UID 0002,0010 is 1.2.840.10008.1.2.2 what would mean big-endian. If you
change this UID to 1.2.840.10008.1.2.1 it can be opened, though there
are some more issues in this file (TM and some UI attributes with wrong
format, High Bit 0,..).

Here is the header dump:

0002,0000 Group Length UL 1 70
0002,0001 File Meta Information Version OB 1 01 00
0002,0010 Transfer Syntax UID UI 1 1.2.840.10008.1.2.2
0002,0012 Implementation Class UID UI 1 2.16.840.1.113662.5
0008,0000 Group Length UL 1 300
0008,0008 Image Type CS 3
ORIGINAL\PRIMARY\OTHER
0008,0016 SOP Class UID UI 1
1.2.840.10008.5.1.4.1.1.4
0008,0018 SOP Instance UID UI 1 2.16.840.1.1136621
0008,0020 Study Date DA 1 20020202
0008,0021 Series Date DA 1 20020202
0008,0030 Study Time TM 1 124567.000000
0008,0031 Series Time TM 1 124567.000000
0008,0032 Acquisition Time TM 1 124567.000000
0008,0033 Content Time TM 1 124567.000000
0008,0050 Accession Number SH 1 1
0008,0060 Modality CS 1 MR
0008,0070 Manufacturer LO 1 ezDICOM
0008,0080 Institution Name LO 1 ANONYMIZED
0008,0081 Institution Address ST 1 ANONYMIZED
0008,1030 Study Description LO 1 FUNCTIONAL
0010,0000 Group Length UL 1 30
0010,0010 Patient's Name PN 1 NO NAME
0010,0020 Patient ID LO 1 NO ID
0018,0000 Group Length UL 1 72
0018,0023 MR Acquisition Type CS 1 2D
0018,0050 Slice Thickness DS 1 1.000000
0018,0088 Spacing Between Slices DS 1 0.000000
0018,1100 Reconstruction Diameter DS 1 250.000000
0018,5100 Patient Position CS 1 HFS
0020,0000 Group Length UL 1 172
0020,000D Study Instance UID UI 1 1.1
0020,000E Series Instance UID UI 1 1.1
0020,0010 Study ID SH 1 1
0020,0011 Series Number IS 1 1
0020,0013 Instance Number IS 1 1
0020,0032 Image Position Patient DS 3
-125.000000\-125.000000\0.0000...(32 Bytes)
0020,0037 Image Orientation Patient DS 6
1.000000\0.000000\0.000000\0.0...(54 Bytes)
0020,1041 Slice Location DS 1 0.000000
0028,0000 Group Length UL 1 152
0028,0002 Samples per Pixel US 1 1
0028,0004 Photometric Interpretation CS 1 MONOCHROME2
0028,0008 Number of Frames IS 1 1
0028,0009 Frame Increment Pointer AT 1 (0020,0013)
0028,0010 Rows US 1 512
0028,0011 Columns US 1 512
0028,0030 Pixel Spacing DS 2 0.49\0.49
0028,0100 Bits Allocated US 1 16
0028,0101 Bits Stored US 1 16
0028,0102 High Bit US 1 0
0028,0103 Pixel Representation US 1 0
0028,1052 Rescale Intercept DS 1 0.00
0028,1053 Rescale Slope DS 1 1
7FE0,0000 Group Length UL 1 524300
7FE0,0010 Pixel Data OW 1 0000 0000 0000 0000
0000 0000 ...(524288 Bytes)

Greetings
Marianne

[kr-val]

Did the same conclusion as Marianne. I have seen a lot of incorrect
DICOM files, but not this type of error. We definitely do not support
this kind of bug.

Regards,

Krister Valtonen
Sectra, Sweden

[ru...@rubomedical.com]

The 'Rubo Dicom Viewer' and parser do handle this:
The viewer: www.rubomedical.com/download
The parser: www.rubomedical.com/dicomparser

Good luck,
Rutger

[Andreas Knopke]

Just to excuse ezDICOM:
the original source provides just one function called write_dicom which
creates LEI only and was used in Chris Rorden's MRicro. The buggy TM
and UI values are original but meant to be examples in case the
corresponing fields are empty in the assigned DICOMDATA struct, the
transfer syntax UID will be set to LEI if the flag LittleEndian is set
in the DICOMDATA struct. The programmer who used this function
obviously did not know much about the standard.

regards,
Andreas