ezDICOM: Explicit VR - Big Endian - DICOM

This is a discussion on ezDICOM: Explicit VR - Big Endian - DICOM ; Hello, I received yet another buggy DICOM file today: http://www.creatis.insa-lyon.fr/~mal...m/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] ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: ezDICOM: Explicit VR - Big Endian

  1. ezDICOM: Explicit VR - Big Endian

    Hello,

    I received yet another buggy DICOM file today:

    http://www.creatis.insa-lyon.fr/~mal...m/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/...er/019879.html


  2. Re: ezDICOM: Explicit VR - Big Endian

    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


  3. Re: ezDICOM: Explicit VR - Big Endian

    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

    Mathieu Malaterre wrote:
    > Hello,
    >
    > I received yet another buggy DICOM file today:
    >
    > http://www.creatis.insa-lyon.fr/~mal...m/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/...er/019879.html



  4. Re: ezDICOM: Explicit VR - Big Endian

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

    Good luck,
    Rutger


  5. Re: ezDICOM: Explicit VR - Big Endian


    Mathieu Malaterre wrote:
    > Hello,
    >
    > I received yet another buggy DICOM file today:
    >
    > http://www.creatis.insa-lyon.fr/~mal...m/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/...er/019879.html



    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


+ Reply to Thread