Is DICOM image in mesa test conform to standard ? - DICOM

This is a discussion on Is DICOM image in mesa test conform to standard ? - DICOM ; Hello, when doing some MESA tests (see http://ihewiki.wustl.edu/wiki/index....ities_in_Study ) we have run into a problem with a dicom image used in the tests (CR1S1IM1.dcm). There exist the control character 0x9F in the ImageComments field (0020,4000). Reading the dicom standard 08-05pu.pdf ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Is DICOM image in mesa test conform to standard ?

  1. Is DICOM image in mesa test conform to standard ?

    Hello,

    when doing some MESA tests (see
    http://ihewiki.wustl.edu/wiki/index....ities_in_Study)
    we have run into a problem with a dicom image used in the tests
    (CR1S1IM1.dcm).
    There exist the control character 0x9F in the ImageComments field
    (0020,4000).
    Reading the dicom standard 08-05pu.pdf Section 6 I found out that
    characters outside the default charcter set (=ascii) have to be
    indicated by the 'Specific character set attribute' (0008,0005) and
    that control characters from the C1 set shall not be used at all (see
    page 18).

    Whenever I try to convert the image to xml with the dcm2xml utility I
    get following error message:

    > ./dcm2xml.exe error.dcm

    dcm2xml: error: (0008,0005) Specific Character Set absent but extended
    characters used in file: error.dcm

    When adding any extended charset with the '+Ca' option to dcm2xml the
    conversion to xml succeeds.

    Since the character is there and no specific character set is defined
    I wonder whether this specific DICOM image conforms to the DICOM
    standard ? Or do I misinterpret the standard here ?

    thanks in advance,
    Arno Wilhelm


    P.S.:
    Here is the dump of the dicom file:
    # Dicom-File-Format

    # Dicom-Meta-Information-Header
    # Used TransferSyntax: LittleEndianExplicit
    (0002,0000) UL 28 # 4, 1
    MetaElementGroupLength
    (0002,0010) UI =LittleEndianExplicit # 20, 1
    TransferSyntaxUID

    # Dicom-Data-Set
    # Used TransferSyntax: LittleEndianExplicit
    (0008,0008) CS [ORIGINAL PRIMARY] # 16, 1
    ImageType
    (0008,0012) DA [19950720] # 8, 1
    InstanceCreationDate
    (0008,0013) TM [093508.0000] # 12, 1
    InstanceCreationTime
    (0008,0016) UI =ComputedRadiographyImageStorage # 26, 1
    SOPClassUID
    (0008,0018) UI [1.2.392.200036.9125.0.19950720093509] # 36, 1
    SOPInstanceUID
    (0008,0020) DA (no value available) # 0, 0
    StudyDate
    (0008,0022) DA [19881129] # 8, 1
    AcquisitionDate
    (0008,0030) TM (no value available) # 0, 0
    StudyTime
    (0008,0032) TM [110800.0000] # 12, 1
    AcquisitionTime
    (0008,0050) SH [FUJI95701] # 10, 1
    AccessionNumber
    (0008,0060) CS [CR] # 2, 1
    Modality
    (0008,0070) LO [FUJI PHOTO FILM CO. LTD.] # 24, 1
    Manufacturer
    (0008,0080) LO [KANAGAWA C.C.] # 20, 1
    InstitutionName
    (0008,0090) PN (no value available) # 0, 0
    ReferringPhysiciansName
    (0008,1090) LO [CR201] # 6, 1
    ManufacturersModelName
    (0010,0010) PN [TANAKA^HANAKO] # 14, 1
    PatientsName
    (0010,0020) LO [FUJI00001] # 10, 1
    PatientID
    (0010,0030) DA [19250824] # 8, 1
    PatientsBirthDate
    (0010,0040) CS [F] # 2, 1
    PatientsSex
    (0018,0015) CS [ABDOMEN] # 8, 1
    BodyPartExamined
    (0018,1260) SH [ST] # 2, 1
    PlateType
    (0018,1261) LO [2] # 2, 1
    PhosphorType
    (0018,1400) LO [[ ]] # 20, 1
    AcquisitionDeviceProcessingDescription
    (0018,1401) LO [00] # 2, 1
    AcquisitionDeviceProcessingCode
    (0018,1402) CS [PORTRAIT] # 10, 1
    CassetteOrientation
    (0018,1403) CS [10INX12IN] # 10, 1
    CassetteSize
    (0018,5101) CS [AP] # 2, 1
    ViewPosition
    (0018,6000) DS [438] # 4, 1
    Sensitivity
    (0020,000d) UI [1.2.392.200036.9125.0.198811291108.7] # 36, 1
    StudyInstanceUID
    (0020,000e) UI [1.2.392.200036.9125.0.198811291108.7] # 36, 1
    SeriesInstanceUID
    (0020,0010) SH (no value available) # 0, 0
    StudyID
    (0020,0011) IS (no value available) # 0, 0
    SeriesNumber
    (0020,0013) IS [7] # 2, 1
    InstanceNumber
    (0020,4000) LT [\ Y" 566] # 12, 1
    ImageComments
    (0028,0002) US 1 # 2, 1
    SamplesPerPixel
    (0028,0004) CS [MONOCHROME1] # 12, 1
    PhotometricInterpretation
    (0028,0010) US 2010 # 2, 1 Rows
    (0028,0011) US 1670 # 2, 1
    Columns
    (0028,0100) US 16 # 2, 1
    BitsAllocated
    (0028,0101) US 10 # 2, 1
    BitsStored
    (0028,0102) US 9 # 2, 1
    HighBit
    (0028,0103) US 0 # 2, 1
    PixelRepresentation
    (0028,1050) DS [550] # 4, 1
    WindowCenter
    (0028,1051) DS [1024] # 4, 1
    WindowWidth
    (2010,0100) CS [WHITE] # 6, 1
    BorderDensity
    (7fe0,0010) OW
    0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\ 0000\0000\0000... #
    6713400, 1 PixelData




  2. Re: Is DICOM image in mesa test conform to standard ?

    On Aug 26, 12:08*pm, Arno Wilhelm wrote:
    > Hello,
    >
    > when doing some MESA tests (seehttp://ihewiki.wustl.edu/wiki/index.php/MESA/Image_Manager#Image_Mana...)
    > we have run into a problem with adicomimage used in the tests
    > (CR1S1IM1.dcm).
    > There exist the control character 0x9F in the ImageComments field
    > (0020,4000).
    > Reading thedicomstandard 08-05pu.pdf Section 6 I found out that
    > characters outside the default charcter set (=ascii) have to be
    > indicated by the 'Specific character set attribute' (0008,0005) and
    > that control characters from the C1 set shall not be used at all (see
    > page 18).
    >
    > Whenever I try to convert the image to xml with the dcm2xml utility I
    > get following error message:
    >
    > > ./dcm2xml.exe error.dcm

    >
    > dcm2xml: error: (0008,0005) Specific Character Set absent but extended
    > characters used in file: error.dcm
    >
    > When adding any extended charset with the '+Ca' option to dcm2xml the
    > conversion to xml succeeds.
    >
    > Since the character is there and no specific character set is defined
    > I wonder whether this specificDICOMimage conforms to theDICOM
    > standard ? Or do I misinterpret the standard here ?
    >
    > thanks in advance,
    > Arno Wilhelm
    >
    > P.S.:
    > Here is the dump of thedicomfile:
    > #Dicom-File-Format
    >
    > #Dicom-Meta-Information-Header
    > # Used TransferSyntax: LittleEndianExplicit
    > (0002,0000) UL 28 * * * * * * * * * * * * * ** * * * * # * 4, 1
    > MetaElementGroupLength
    > (0002,0010) UI =LittleEndianExplicit * * * * * * * * * *# *20, 1
    > TransferSyntaxUID
    >
    > #Dicom-Data-Set
    > # Used TransferSyntax: LittleEndianExplicit
    > (0008,0008) CS [ORIGINAL PRIMARY] * * * * * * * * * ** # *16, 1
    > ImageType
    > (0008,0012) DA [19950720] * * * * * * * * * * * ** * * # * 8, 1
    > InstanceCreationDate
    > (0008,0013) TM [093508.0000] * * * * * * * * * * * * * *# *12, 1
    > InstanceCreationTime
    > (0008,0016) UI =ComputedRadiographyImageStorage * * * * # *26, 1
    > SOPClassUID
    > (0008,0018) UI [1.2.392.200036.9125.0.19950720093509] * # *36, 1
    > SOPInstanceUID
    > (0008,0020) DA (no value available) * * * * * * * * * * # * 0, 0
    > StudyDate
    > (0008,0022) DA [19881129] * * * * * * * * * * * ** * * # * 8, 1
    > AcquisitionDate
    > (0008,0030) TM (no value available) * * * * * * * * * * # * 0, 0
    > StudyTime
    > (0008,0032) TM [110800.0000] * * * * * * * * * * * * * *# *12, 1
    > AcquisitionTime
    > (0008,0050) SH [FUJI95701] * * * * * * * * * * * * * * *# *10, 1
    > AccessionNumber
    > (0008,0060) CS [CR] * * * * * * * * * * * * * * * * * * # * 2, 1
    > Modality
    > (0008,0070) LO [FUJI PHOTO FILM CO. LTD.] * * * * * * * # *24, 1
    > Manufacturer
    > (0008,0080) LO [KANAGAWA C.C.] * * * * * * * * * * * * *# *20, 1
    > InstitutionName
    > (0008,0090) PN (no value available) * * * * * * * * * * # * 0, 0
    > ReferringPhysiciansName
    > (0008,1090) LO [CR201] * * * * * * * * * * * * * * * * *# * 6, 1
    > ManufacturersModelName
    > (0010,0010) PN [TANAKA^HANAKO] * * * * * * * * * * * * *# *14, 1
    > PatientsName
    > (0010,0020) LO [FUJI00001] * * * * * * * * * * * * * * *# *10, 1
    > PatientID
    > (0010,0030) DA [19250824] * * * * * * * * * * * ** * * # * 8, 1
    > PatientsBirthDate
    > (0010,0040) CS [F] * * * * * * * * * * * * * * * * * * *# * 2, 1
    > PatientsSex
    > (0018,0015) CS [ABDOMEN] * * * * * * * * * * * * * * * *# * 8, 1
    > BodyPartExamined
    > (0018,1260) SH [ST] * * * * * * * * * * * * * * * * * * # * 2, 1
    > PlateType
    > (0018,1261) LO [2] * * * * * * * * * * * * * * * * * * *# * 2, 1
    > PhosphorType
    > (0018,1400) LO [[ * * * * * * * * *]] * * * * * * * * * # *20, 1
    > AcquisitionDeviceProcessingDescription
    > (0018,1401) LO [00] * * * * * * * * * * * * * * * * * * # * 2, 1
    > AcquisitionDeviceProcessingCode
    > (0018,1402) CS [PORTRAIT] * * * * * * * * * * * ** * * # *10, 1
    > CassetteOrientation
    > (0018,1403) CS [10INX12IN] * * * * * * * * * * * * * * *# *10, 1
    > CassetteSize
    > (0018,5101) CS [AP] * * * * * * * * * * * * * * * * * * # * 2, 1
    > ViewPosition
    > (0018,6000) DS [438] * * * * * * * * * * * * * * * * * *# * 4, 1
    > Sensitivity
    > (0020,000d) UI [1.2.392.200036.9125.0.198811291108.7] * # *36, 1
    > StudyInstanceUID
    > (0020,000e) UI [1.2.392.200036.9125.0.198811291108.7] * # *36, 1
    > SeriesInstanceUID
    > (0020,0010) SH (no value available) * * * * * * * * * * # * 0, 0
    > StudyID
    > (0020,0011) IS (no value available) * * * * * * * * * * # * 0, 0
    > SeriesNumber
    > (0020,0013) IS [7] * * * * * * * * * * * * * * * * * * *# * 2, 1
    > InstanceNumber
    > (0020,4000) LT [\ *Y" *566] * * * * * * * * * * * * * * # *12, 1
    > ImageComments
    > (0028,0002) US 1 * * * * * * * * * * * * * * * * * * * *# * 2, 1
    > SamplesPerPixel
    > (0028,0004) CS [MONOCHROME1] * * * * * * * * * * * * * *# *12, 1
    > PhotometricInterpretation
    > (0028,0010) US 2010 * * * * * * * * * * * * * * * * * * # * 2, 1 Rows
    > (0028,0011) US 1670 * * * * * * * * * * * * * * * * * * # * 2, 1
    > Columns
    > (0028,0100) US 16 * * * * * * * * * * * * * ** * * * * # * 2, 1
    > BitsAllocated
    > (0028,0101) US 10 * * * * * * * * * * * * * ** * * * * # * 2, 1
    > BitsStored
    > (0028,0102) US 9 * * * * * * * * * * * * * * * * * * * *# * 2, 1
    > HighBit
    > (0028,0103) US 0 * * * * * * * * * * * * * * * * * * * *# * 2, 1
    > PixelRepresentation
    > (0028,1050) DS [550] * * * * * * * * * * * * * * * * * *# * 4, 1
    > WindowCenter
    > (0028,1051) DS [1024] * * * * * * * * * * * * ** * * * # * 4, 1
    > WindowWidth
    > (2010,0100) CS [WHITE] * * * * * * * * * * * * * * * * *# * 6, 1
    > BorderDensity
    > (7fe0,0010) OW
    > 0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\ 0000\0000\0000... #
    > 6713400, 1 PixelData


    Hello Arno,

    You are correct. If no character set is defined in tag (0008,0005),
    then any DICOM reader (or converter in your case) will assume that
    this dataset uses the basic graphic set.

    However, if there was no special character used in the dataset, the
    DICOM reader will (mostly) open it correctly, but you will get an
    error only when special characters used. The DICOM reader will also
    ignores the non-basic character set if it only opens the pixel data
    within a data set and not the tags.

    Keep in mind that this will only affect data set strings that contain
    characters (like patient name, patient ID, manufacturer, etc).

    This means, the file itself does not violate the DICOM standard, and
    if the viewers are not required to display that particular item
    correctly, then they should open the file.

    Our toolkit (http://www.leadtools.com/) can be used to parse a DICOM
    data set and retrieve the exact binary data from any item if you need
    it. There's a free evaluation edition if you you'd like to try it.

  3. Re: Is DICOM image in mesa test conform to standard ?

    Hi,

    thanks for your answer!

    > This means, the file itself does not violate the DICOM standard, and
    > if the viewers are not required to display that particular item
    > correctly, then they should open the file.


    If I understand you correctly:
    The usage of the character 0x9F which represents the control character
    'Application Program Command' from the C1 set (see
    http://en.wikipedia.org/wiki/C0_and_C1_control_codes) does not violate
    the DICOM standard, even when in the DICOM standard (08-05pu.pdf page
    18) it says:

    "The Control Character set C0 shall be invoked in CL and the Graphic
    Character sets G0 and G1 in GL
    and GR respectively. Only some Control Characters from the C0 set are
    used in DICOM (see Section
    6.1.3), and characters from the C1 set shall not be used." ?

    Another important question is, how an application should react when it
    has to deal with an character that does not conform to the dicom
    standard?
    Should it ignore the offending part and only give out a warning, or
    should it refuse to deal with the non-conforming DICOM document at
    all ?

    greetings,
    Arno Wilhelm

  4. Re: Is DICOM image in mesa test conform to standard ?

    Hi Arno

    It is definitely a violation of the DICOM standard; no question
    about it.

    You cannot use bytes in strings that are not permitted by the
    character set, default or otherwise.

    That said, it does not help the users to do anything other than
    ignore the bad character, as most applications would.

    David

    Arno Wilhelm wrote:
    > Hi,
    >
    > thanks for your answer!
    >
    >> This means, the file itself does not violate the DICOM standard, and
    >> if the viewers are not required to display that particular item
    >> correctly, then they should open the file.

    >
    > If I understand you correctly:
    > The usage of the character 0x9F which represents the control character
    > 'Application Program Command' from the C1 set (see
    > http://en.wikipedia.org/wiki/C0_and_C1_control_codes) does not violate
    > the DICOM standard, even when in the DICOM standard (08-05pu.pdf page
    > 18) it says:
    >
    > "The Control Character set C0 shall be invoked in CL and the Graphic
    > Character sets G0 and G1 in GL
    > and GR respectively. Only some Control Characters from the C0 set are
    > used in DICOM (see Section
    > 6.1.3), and characters from the C1 set shall not be used." ?
    >
    > Another important question is, how an application should react when it
    > has to deal with an character that does not conform to the dicom
    > standard?
    > Should it ignore the offending part and only give out a warning, or
    > should it refuse to deal with the non-conforming DICOM document at
    > all ?
    >
    > greetings,
    > Arno Wilhelm


  5. Re: Is DICOM image in mesa test conform to standard ?

    Hi David,

    thanks for clarifying this point - it's just a we expected it to be.
    So we will have a way to workaround this problem ....


    Arno

+ Reply to Thread