Encapsulated JPEG in Implicit Transfer Syntax - DICOM

This is a discussion on Encapsulated JPEG in Implicit Transfer Syntax - DICOM ; If anyone is interested in supporting this file: http://forums.dcm4che.org/jiveforums...a?threadID=644 or direct link: http://forums.dcm4che.org/jiveforums...264/GBRGB2.dcm Amazingly dcmtk was able to parse it, without no problem. 2cts -Mathieu # Dicom-File-Format # Dicom-Meta-Information-Header # Used TransferSyntax: LittleEndianExplicit (0002,0000) UL 182 # 4, 1 MetaElementGroupLength ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Encapsulated JPEG in Implicit Transfer Syntax

  1. Encapsulated JPEG in Implicit Transfer Syntax

    If anyone is interested in supporting this file:

    http://forums.dcm4che.org/jiveforums...a?threadID=644

    or direct link:

    http://forums.dcm4che.org/jiveforums...264/GBRGB2.dcm

    Amazingly dcmtk was able to parse it, without no problem.

    2cts
    -Mathieu

    # Dicom-File-Format

    # Dicom-Meta-Information-Header
    # Used TransferSyntax: LittleEndianExplicit
    (0002,0000) UL 182 # 4, 1
    MetaElementGroupLength
    (0002,0001) OB 00\01 # 2, 1
    FileMetaInformationVersion
    (0002,0002) UI =SecondaryCaptureImageStorage # 26, 1
    MediaStorageSOPClassUID
    (0002,0003) UI
    [1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.3] # 56, 1
    MediaStorageSOPInstanceUID
    (0002,0010) UI =LittleEndianImplicit # 18, 1
    TransferSyntaxUID
    (0002,0012) UI [1.2.40.0.13.1.1] # 16, 1
    ImplementationClassUID
    (0002,0013) SH [dcm4che-2.0] # 12, 1
    ImplementationVersionName

    # Dicom-Data-Set
    # Used TransferSyntax: LittleEndianImplicit
    (0008,0005) CS [ISO_IR 100] # 10, 1
    SpecificCharacterSet
    (0008,0012) DA [20080804] # 8, 1
    InstanceCreationDate
    (0008,0013) TM [125058.319] # 10, 1
    InstanceCreationTime
    (0008,0016) UI =SecondaryCaptureImageStorage # 26, 1
    SOPClassUID
    (0008,0018) UI
    [1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.3] # 56, 1
    SOPInstanceUID
    (0008,0060) CS [OT] # 2, 1
    Modality
    (0008,0064) CS [SI] # 2, 1
    ConversionType
    (0008,0070) LO (no value available) # 0, 0
    Manufacturer
    (0010,0010) PN [Glass brain RGB] # 16, 1
    PatientsName
    (0010,0020) LO (no value available) # 0, 0
    PatientID
    (0010,0030) DA (no value available) # 0, 0
    PatientsBirthDate
    (0010,0040) CS (no value available) # 0, 0
    PatientsSex
    (0020,000d) UI
    [1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.1] # 56, 1
    StudyInstanceUID
    (0020,000e) UI
    [1.2.40.0.13.1.10.180.18.159.10840700.2008080412505 8319.2] # 56, 1
    SeriesInstanceUID
    (0020,0011) IS [1] # 2, 1
    SeriesNumber
    (0020,0013) IS [1] # 2, 1
    InstanceNumber
    (0028,0002) US 3 # 2, 1
    SamplesPerPixel
    (0028,0004) CS [YBR_FULL_422] # 12, 1
    PhotometricInterpretation
    (0028,0010) US 937 # 2, 1 Rows
    (0028,0011) US 651 # 2, 1
    Columns
    (0028,0100) US 8 # 2, 1
    BitsAllocated
    (0028,0101) US 8 # 2, 1
    BitsStored
    (0028,0102) US 7 # 2, 1
    HighBit
    (0028,0103) US 0 # 2, 1
    PixelRepresentation
    (7fe0,0010) OB (PixelSequence #=2) # u/l, 1
    PixelData
    (fffe,e000) pi (no value available) # 0, 1
    Item
    (fffe,e000) pi ff\d8\ff\e0\00\10\4a
    \46\49\46\00\01\01\00\00\01\00\01\00\00\ff\db... # 69184, 1 Item
    (fffe,e0dd) na (SequenceDelimitationItem) # 0, 0
    SequenceDelimitationItem

  2. Re: Encapsulated JPEG in Implicit Transfer Syntax

    On Aug 19, 11:43*am, Mathieu Malaterre
    wrote:
    > If anyone is interested in supporting this file:
    >
    > http://forums.dcm4che.org/jiveforums...a?threadID=644
    >
    > or direct link:
    >
    > http://forums.dcm4che.org/jiveforums...t/download/5-6...
    >
    > Amazingly dcmtk was able to parse it, without no problem.
    >
    > 2cts
    > -Mathieu


    I guess, most DICOM implementations will able to parse the file, but
    interpreting the encapsulated pixel data as JPEG baseline stream would
    need to apply some simple heuristic (e.g. detect JPEG SOI marker).
    Fortunately, I have not (yet) seen such objects in real PACS
    installations, and I hope that the possibility to create such invalid
    DICOM objects by wrong usage of dcm4che's jpg2dcm utility will not
    induce that such objects show up in future.

    -gunter

  3. Re: Encapsulated JPEG in Implicit Transfer Syntax

    Mathieu Malaterre wrote:
    > If anyone is interested in supporting this file: [...]
    > Amazingly dcmtk was able to parse it, without no problem.


    DCMTK will read the file, but will refuse to write or send the file, because the pixel data is
    treated as being of "unknown transfer syntax", and none of the compression/decompression codecs
    in DCMTK supports a conversion from unknown to something well-defined.

    We added some support for cases like that because the combination of the icon image sequence
    and compression/decompression sometimes leads to strange results: compressed images with
    uncompressed icons (permitted in DICOM), compressed images with compressed icons (also permitted),
    decompressed images where the icon remains compressed (stupid decoder, but seems to happen).

    Best regards,
    Marco Eichelberg


  4. Re: Encapsulated JPEG in Implicit Transfer Syntax

    On Aug 20, 10:28 am, gunter zeilinger wrote:
    > On Aug 19, 11:43 am, Mathieu Malaterre
    > wrote:
    >
    > > If anyone is interested in supporting this file:

    >
    > >http://forums.dcm4che.org/jiveforums...a?threadID=644

    >
    > > or direct link:

    >
    > >http://forums.dcm4che.org/jiveforums...t/download/5-6...

    >
    > > Amazingly dcmtk was able to parse it, without no problem.

    >
    > > 2cts
    > > -Mathieu

    >
    > I guess, most DICOM implementations will able to parse the file, but
    > interpreting the encapsulated pixel data as JPEG baseline stream would
    > need to apply some simple heuristic (e.g. detect JPEG SOI marker).
    > Fortunately, I have not (yet) seen such objects in real PACS
    > installations, and I hope that the possibility to create such invalid
    > DICOM objects by wrong usage of dcm4che's jpg2dcm utility will not
    > induce that such objects show up in future.


    Gunter,

    Seriously, how could you blame your dcm4che user for that. If this
    is so easy to create such invalid DICOM object, I'd rather think there
    is a serious bug in how your write DICOM DataSet in jpg2dcm. Add
    somewhere in your code that you cannot have encapsulated JPEG with
    implicit dataset. This is much simpler than adding a "simple
    heuristic" in every DICOM implementation to guess that a JPEG stream
    is encapsulated within an implicit dataset.

    Marco,

    That is yet another example of why I think a list of valid/invalid
    DICOM objects is becoming a necessity for DICOM implementors.

    -Mathieu

  5. Re: Encapsulated JPEG in Implicit Transfer Syntax

    On Aug 20, 11:11 am, Marco Eichelberg
    wrote:

    > decompressed images where the icon remains compressed (stupid decoder, but seems to happen).


    Ouch ! How do you guess the original compressor then ? Any sample
    dataset ?

    Thanks
    -Mathieu

  6. Re: Encapsulated JPEG in Implicit Transfer Syntax

    Mathieu Malaterre wrote:
    >> decompressed images where the icon remains compressed (stupid decoder, but seems to happen).

    >
    > Ouch ! How do you guess the original compressor then ? Any sample
    > dataset ?


    We don't guess the original compressor - we read the file but refuse to
    write it unless the application "fixes" or removes the icon image sequence.
    Display of the main image will work, however, since this does not need the icon image.

    Unfortunately I cannot find a sample image right now. Must be buried somewhere in my collection
    of awful things :-)

    Regards,
    Marco

  7. Re: Encapsulated JPEG in Implicit Transfer Syntax

    On Aug 20, 12:27 pm, Marco Eichelberg
    wrote:
    > Mathieu Malaterre wrote:
    > >> decompressed images where the icon remains compressed (stupid decoder, but seems to happen).

    >
    > > Ouch ! How do you guess the original compressor then ? Any sample
    > > dataset ?

    >
    > We don't guess the original compressor - we read the file but refuse to
    > write it unless the application "fixes" or removes the icon image sequence.
    > Display of the main image will work, however, since this does not need the icon image.


    AFAIK this is actually the right thing to do. I hate this guessing
    heuristic game.

    > Unfortunately I cannot find a sample image right now. Must be buried somewhere in my collection
    > of awful things :-)


    This is not that hard to produce. I'll create a fake example.

    Thanks,
    -Mathieu

+ Reply to Thread