Doubt calculating item & SQ lengths - DICOM

This is a discussion on Doubt calculating item & SQ lengths - DICOM ; Hello everyone, We wonder if someone could help us to clarify a doubt regarding to the encoding of the following dataset attributes, which are part of a file encoded using Offis DCMDJPEG Particularly, I don't understand why the item (fffe,e000) ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Doubt calculating item & SQ lengths

  1. Doubt calculating item & SQ lengths

    Hello everyone,

    We wonder if someone could help us to clarify a doubt regarding to the
    encoding of the following dataset attributes, which are part of a file
    encoded using Offis DCMDJPEG

    Particularly, I don't understand why the item (fffe,e000) has a length
    of 928 bytes. In our opinion, it should have a 936 bytes length
    (explicit VR)


    > # Dicom-File-Format
    >
    > # Dicom-Meta-Information-Header
    > # Used TransferSyntax: LittleEndianExplicit
    > (0002,0000) UL 200 # 4, 1 MetaElementGroupLength
    > (0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
    > (0002,0002) UI =DigitalXRayImageStorageForProcessing # 30, 1 MediaStorageSOPClassUID
    > (0002,0003) UI [1.2.840.113619.2.203.4.604641182.1146179814.226992] # 50, 1 MediaStorageSOPInstanceUID
    > (0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID
    > (0002,0012) UI [1.2.276.0.7230010.3.0.3.5.2] # 28, 1 ImplementationClassUID
    > (0002,0013) SH [OFFIS_DCMTK_352] # 16, 1 ImplementationVersionName
    >
    > ...
    >
    > (0088,0000) UL 948 # 4, 1 StorageGroupLength
    > (0088,0200) SQ (Sequence with explicit length #=1) # 936, 1 IconImageSequence
    > (fffe,e000) na (Item with explicit length #=11) # 928, 1 Item
    > (0028,0000) UL 90 # 4, 1 ImagePresentationGroupLength
    > (0028,0002) US 1 # 2, 1 SamplesPerPixel
    > (0028,0004) CS [MONOCHROME1] # 12, 1 PhotometricInterpretation
    > (0028,0010) US 64 # 2, 1 Rows
    > (0028,0011) US 64 # 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,0000) UL 814 # 4, 1 PixelDataGroupLength
    > (7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
    > (fffe,e000) pi 00\00\00\00 # 4, 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\c3... # 782, 1 Item
    > (fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
    > (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
    > (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
    > (2050,0000) UL 16 # 4, 1 PresentationLUTGroupLength
    > (2050,0020) CS [INVERSE] # 8, 1 PresentationLUTShape


    We have calculated the addition of the inner attribute lengths and
    result is 936 bytes. What are we doing wrong?

    In fact, if we open the file, the offset between the end of the header
    of attribute (fffe,e000) and the begining of header of attribute
    (2050,0000) is 936, not 928.

    Anyway, DMCTK libraries and other software (e.g. SYNGO) can handle such
    file.

    Thanks in advance,

    Marta


  2. Re: Doubt calculating item & SQ lengths

    the tag [fffe,e000] has 8 bytes .

    Razvan
    marta.pujol@gmail.com wrote:
    > Hello everyone,
    >
    > We wonder if someone could help us to clarify a doubt regarding to the
    > encoding of the following dataset attributes, which are part of a file
    > encoded using Offis DCMDJPEG
    >
    > Particularly, I don't understand why the item (fffe,e000) has a length
    > of 928 bytes. In our opinion, it should have a 936 bytes length
    > (explicit VR)
    >
    >
    > > # Dicom-File-Format
    > >
    > > # Dicom-Meta-Information-Header
    > > # Used TransferSyntax: LittleEndianExplicit
    > > (0002,0000) UL 200 # 4, 1 MetaElementGroupLength
    > > (0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
    > > (0002,0002) UI =DigitalXRayImageStorageForProcessing # 30, 1 MediaStorageSOPClassUID
    > > (0002,0003) UI [1.2.840.113619.2.203.4.604641182.1146179814.226992] # 50, 1 MediaStorageSOPInstanceUID
    > > (0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID
    > > (0002,0012) UI [1.2.276.0.7230010.3.0.3.5.2] # 28, 1 ImplementationClassUID
    > > (0002,0013) SH [OFFIS_DCMTK_352] # 16, 1 ImplementationVersionName
    > >
    > > ...
    > >
    > > (0088,0000) UL 948 # 4, 1 StorageGroupLength
    > > (0088,0200) SQ (Sequence with explicit length #=1) # 936, 1 IconImageSequence
    > > (fffe,e000) na (Item with explicit length #=11) # 928, 1 Item
    > > (0028,0000) UL 90 # 4, 1 ImagePresentationGroupLength
    > > (0028,0002) US 1 # 2, 1 SamplesPerPixel
    > > (0028,0004) CS [MONOCHROME1] # 12, 1 PhotometricInterpretation
    > > (0028,0010) US 64 # 2, 1 Rows
    > > (0028,0011) US 64 # 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,0000) UL 814 # 4, 1 PixelDataGroupLength
    > > (7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
    > > (fffe,e000) pi 00\00\00\00 # 4, 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\c3... # 782, 1 Item
    > > (fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
    > > (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
    > > (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
    > > (2050,0000) UL 16 # 4, 1 PresentationLUTGroupLength
    > > (2050,0020) CS [INVERSE] # 8, 1 PresentationLUTShape

    >
    > We have calculated the addition of the inner attribute lengths and
    > result is 936 bytes. What are we doing wrong?
    >
    > In fact, if we open the file, the offset between the end of the header
    > of attribute (fffe,e000) and the begining of header of attribute
    > (2050,0000) is 936, not 928.
    >
    > Anyway, DMCTK libraries and other software (e.g. SYNGO) can handle such
    > file.
    >
    > Thanks in advance,
    >
    > Marta



  3. Re: Doubt calculating item & SQ lengths

    Hello,

    Thanks for your response. We don't want to know the tag header length,
    our problem is the tag value whose length is 928 bytes. We have
    calculated the operation and our result is 936 bytes. We don't know
    what we don't do right.

    If anyone wants to see the file, we will send it.

    Thanks,

    Marta


    Razvan Costea-Barlutiu ha escrito:

    > the tag [fffe,e000] has 8 bytes .
    >
    > Razvan
    > marta.pujol@gmail.com wrote:
    > > Hello everyone,
    > >
    > > We wonder if someone could help us to clarify a doubt regarding to the
    > > encoding of the following dataset attributes, which are part of a file
    > > encoded using Offis DCMDJPEG
    > >
    > > Particularly, I don't understand why the item (fffe,e000) has a length
    > > of 928 bytes. In our opinion, it should have a 936 bytes length
    > > (explicit VR)
    > >
    > >
    > > > # Dicom-File-Format
    > > >
    > > > # Dicom-Meta-Information-Header
    > > > # Used TransferSyntax: LittleEndianExplicit
    > > > (0002,0000) UL 200 # 4, 1 MetaElementGroupLength
    > > > (0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
    > > > (0002,0002) UI =DigitalXRayImageStorageForProcessing # 30, 1 MediaStorageSOPClassUID
    > > > (0002,0003) UI [1.2.840.113619.2.203.4.604641182.1146179814.226992] # 50, 1 MediaStorageSOPInstanceUID
    > > > (0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID
    > > > (0002,0012) UI [1.2.276.0.7230010.3.0.3.5.2] # 28, 1 ImplementationClassUID
    > > > (0002,0013) SH [OFFIS_DCMTK_352] # 16, 1 ImplementationVersionName
    > > >
    > > > ...
    > > >
    > > > (0088,0000) UL 948 # 4, 1 StorageGroupLength
    > > > (0088,0200) SQ (Sequence with explicit length #=1) # 936, 1 IconImageSequence
    > > > (fffe,e000) na (Item with explicit length #=11) # 928, 1 Item
    > > > (0028,0000) UL 90 # 4, 1 ImagePresentationGroupLength
    > > > (0028,0002) US 1 # 2, 1 SamplesPerPixel
    > > > (0028,0004) CS [MONOCHROME1] # 12, 1 PhotometricInterpretation
    > > > (0028,0010) US 64 # 2, 1 Rows
    > > > (0028,0011) US 64 # 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,0000) UL 814 # 4, 1 PixelDataGroupLength
    > > > (7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
    > > > (fffe,e000) pi 00\00\00\00 # 4, 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\c3... # 782, 1 Item
    > > > (fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
    > > > (fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
    > > > (fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
    > > > (2050,0000) UL 16 # 4, 1 PresentationLUTGroupLength
    > > > (2050,0020) CS [INVERSE] # 8, 1 PresentationLUTShape

    > >
    > > We have calculated the addition of the inner attribute lengths and
    > > result is 936 bytes. What are we doing wrong?
    > >
    > > In fact, if we open the file, the offset between the end of the header
    > > of attribute (fffe,e000) and the begining of header of attribute
    > > (2050,0000) is 936, not 928.
    > >
    > > Anyway, DMCTK libraries and other software (e.g. SYNGO) can handle such
    > > file.
    > >
    > > Thanks in advance,
    > >
    > > Marta



  4. Re: Doubt calculating item & SQ lengths

    You can send me the file if you're still in trouble.

    Razvan


+ Reply to Thread