Hello - DICOM

This is a discussion on Hello - DICOM ; Hello, I have a question. I am trying to parse the DICOM tags ( Group Number and Element Number ) in a DICOM image file. At some point I get the following DICOM Tag : (0xFF,0xFF,0xFF, 0xFF) with the length ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Hello

  1. Hello

    Hello,

    I have a question. I am trying to parse the DICOM tags ( Group Number
    and Element Number ) in a DICOM image file. At some point I get the
    following DICOM Tag : (0xFF,0xFF,0xFF, 0xFF) with the length
    (0x00,0xE0) (which turns out to be a huge value ) . Howver, the value
    for this tag only has 4 bytes 0xFF 0xFF 0xFF 0xFF....
    Is this some sort of weird tag ? How should I deal with such tags ?

    So the full thing is:

    0xFF 0xFF 0xFF 0xFF 0xFE 0xFF 0x00 0xE0 0xFF 0xFF 0xFF 0xFF

    Best regards,
    Seb


  2. Re: Hello

    Hi Sebastian,
    the parsing you show does not exactly fit, it could be part of a
    sequence of items, where sequence and item have unknown length.

    Please have a look at Part 5 Section 7.5 for an explanation.
    In short words:

    (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    SQ LLLL is the 4 bytes length value.
    now in the value field of that tag you have a sequence of items where
    each item consists of embedded tags.
    To mark the begining, end of an item and end of the sequence some
    delimiters are defined:
    FFFE, E000 : Item start (always there)
    FFFE, E00D: Item delimiter (only if item length is unknown)
    FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    The delimiters look like tags and have a lengh as well. In case of an
    unknown length all length bytes are set to FF.
    If I start with byte 5 of your example and supposed you have a little
    endian transfer syntax it looks like:
    FFFE, E000 FFFF FFFF which is begining of an item with unknown
    length.

    Have a closer look at what comes before byte 5 the first 4 bytes might
    be an unknown length as well. So the 4 bytes preceding the posted
    buffer will show the tag.
    Another possibility is you are in the pixel data and deal with have
    frame delimiters which use items as well. - See Annex A4. However in
    that case you shall have a defined item length.


    Thomas


  3. Re: Hello

    Hello,

    Here is a larger fragment....

    00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00

    So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    be the VR ("SQ"). Than, "00 00" has to be the
    length....................Than
    "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    VR of this tag and "00 E0" has to be the length of the value that
    follows ... However,
    the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    followed by some other DICOM tag....
    Do you see what I'm saying ?

    Best regards,
    Seb

    On Aug 13, 3:42 am, Thomas Freier wrote:
    > Hi Sebastian,
    > the parsing you show does not exactly fit, it could be part of a
    > sequence of items, where sequence and item have unknown length.
    >
    > Please have a look at Part 5 Section 7.5 for an explanation.
    > In short words:
    >
    > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > SQ LLLL is the 4 bytes length value.
    > now in the value field of that tag you have a sequence of items where
    > each item consists of embedded tags.
    > To mark the begining, end of an item and end of the sequence some
    > delimiters are defined:
    > FFFE, E000 : Item start (always there)
    > FFFE, E00D: Item delimiter (only if item length is unknown)
    > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > The delimiters look like tags and have a lengh as well. In case of an
    > unknown length all length bytes are set to FF.
    > If I start with byte 5 of your example and supposed you have a little
    > endian transfer syntax it looks like:
    > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > length.
    >
    > Have a closer look at what comes before byte 5 the first 4 bytes might
    > be an unknown length as well. So the 4 bytes preceding the posted
    > buffer will show the tag.
    > Another possibility is you are in the pixel data and deal with have
    > frame delimiters which use items as well. - See Annex A4. However in
    > that case you shall have a defined item length.
    >
    > Thomas




  4. Re: Hello


    Ok.. Thanks Thomas .. I read Part 5 Section 7.5 and now I understand
    my mistake...
    But I have one more question.........The GroupNumber and ElementNumber
    are always going to be stored in Little Endian format ?? Correct ???
    Regards

    On Aug 13, 5:37 am, sebastian.ha...@gmail.com wrote:
    > Hello,
    >
    > Here is a larger fragment....
    >
    > 00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    > 00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00
    >
    > So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    > be the VR ("SQ"). Than, "00 00" has to be the
    > length....................Than
    > "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    > VR of this tag and "00 E0" has to be the length of the value that
    > follows ... However,
    > the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    > followed by some other DICOM tag....
    > Do you see what I'm saying ?
    >
    > Best regards,
    > Seb
    >
    > On Aug 13, 3:42 am, Thomas Freier wrote:
    >
    > > Hi Sebastian,
    > > the parsing you show does not exactly fit, it could be part of a
    > > sequence of items, where sequence and item have unknown length.

    >
    > > Please have a look at Part 5 Section 7.5 for an explanation.
    > > In short words:

    >
    > > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > > SQ LLLL is the 4 bytes length value.
    > > now in the value field of that tag you have a sequence of items where
    > > each item consists of embedded tags.
    > > To mark the begining, end of an item and end of the sequence some
    > > delimiters are defined:
    > > FFFE, E000 : Item start (always there)
    > > FFFE, E00D: Item delimiter (only if item length is unknown)
    > > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > > The delimiters look like tags and have a lengh as well. In case of an
    > > unknown length all length bytes are set to FF.
    > > If I start with byte 5 of your example and supposed you have a little
    > > endian transfer syntax it looks like:
    > > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > > length.

    >
    > > Have a closer look at what comes before byte 5 the first 4 bytes might
    > > be an unknown length as well. So the 4 bytes preceding the posted
    > > buffer will show the tag.
    > > Another possibility is you are in the pixel data and deal with have
    > > frame delimiters which use items as well. - See Annex A4. However in
    > > that case you shall have a defined item length.

    >
    > > Thomas




  5. Re: Hello

    On Aug 13, 2:37 pm, sebastian.ha...@gmail.com wrote:
    > Hello,
    >
    > Here is a larger fragment....
    >
    > 00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    > 00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00
    >
    > So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    > be the VR ("SQ"). Than, "00 00" has to be the
    > length....................Than
    > "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    > VR of this tag and "00 E0" has to be the length of the value that
    > follows ... However,
    > the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    > followed by some other DICOM tag....
    > Do you see what I'm saying ?
    >
    > Best regards,
    > Seb
    >
    > On Aug 13, 3:42 am, Thomas Freier wrote:
    >
    > > Hi Sebastian,
    > > the parsing you show does not exactly fit, it could be part of a
    > > sequence of items, where sequence and item have unknown length.

    >
    > > Please have a look at Part 5 Section 7.5 for an explanation.
    > > In short words:

    >
    > > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > > SQ LLLL is the 4 bytes length value.
    > > now in the value field of that tag you have a sequence of items where
    > > each item consists of embedded tags.
    > > To mark the begining, end of an item and end of the sequence some
    > > delimiters are defined:
    > > FFFE, E000 : Item start (always there)
    > > FFFE, E00D: Item delimiter (only if item length is unknown)
    > > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > > The delimiters look like tags and have a lengh as well. In case of an
    > > unknown length all length bytes are set to FF.
    > > If I start with byte 5 of your example and supposed you have a little
    > > endian transfer syntax it looks like:
    > > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > > length.

    >
    > > Have a closer look at what comes before byte 5 the first 4 bytes might
    > > be an unknown length as well. So the 4 bytes preceding the posted
    > > buffer will show the tag.
    > > Another possibility is you are in the pixel data and deal with have
    > > frame delimiters which use items as well. - See Annex A4. However in
    > > that case you shall have a defined item length.

    >
    > > Thomas


    Hello,

    first 00 skip it
    08 00 = group 8
    10 11 = tag 1110 (Referenced Study Sequence)
    00 00 = length. Ignore (defined in the next 4 bytes)
    ff ff ff ff = undefined length
    fe ff = group fffe
    00 e0 = tag e000 (Sequence item)
    ff ff ff ff = undefined length
    08 00 = group 8
    00 00 = tag 0 (group length)
    55 4c = tag 8,0 type is UL
    04 00 = tag 8,0 length is 4 bytes
    10 00 00 00 = tag 8,0 content (group's length)
    08 00 50 11 = tag 8, 1150
    And so on.

    The following tags have their length specified in 4 bytes following
    the first two normally used by other tags:
    "OB"
    "OF"
    "OW"
    "SQ"
    "UN"
    "UT"

    Bye,
    Paolo


  6. Re: Hello

    And the Value Length is also always going to be Little Endian,
    right ??

    On Aug 13, 6:03 am, sebastian.ha...@gmail.com wrote:
    > Ok.. Thanks Thomas .. I read Part 5 Section 7.5 and now I understand
    > my mistake...
    > But I have one more question.........The GroupNumber and ElementNumber
    > are always going to be stored in Little Endian format ?? Correct ???
    > Regards
    >
    > On Aug 13, 5:37 am, sebastian.ha...@gmail.com wrote:
    >
    > > Hello,

    >
    > > Here is a larger fragment....

    >
    > > 00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    > > 00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00

    >
    > > So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    > > be the VR ("SQ"). Than, "00 00" has to be the
    > > length....................Than
    > > "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    > > VR of this tag and "00 E0" has to be the length of the value that
    > > follows ... However,
    > > the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    > > followed by some other DICOM tag....
    > > Do you see what I'm saying ?

    >
    > > Best regards,
    > > Seb

    >
    > > On Aug 13, 3:42 am, Thomas Freier wrote:

    >
    > > > Hi Sebastian,
    > > > the parsing you show does not exactly fit, it could be part of a
    > > > sequence of items, where sequence and item have unknown length.

    >
    > > > Please have a look at Part 5 Section 7.5 for an explanation.
    > > > In short words:

    >
    > > > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > > > SQ LLLL is the 4 bytes length value.
    > > > now in the value field of that tag you have a sequence of items where
    > > > each item consists of embedded tags.
    > > > To mark the begining, end of an item and end of the sequence some
    > > > delimiters are defined:
    > > > FFFE, E000 : Item start (always there)
    > > > FFFE, E00D: Item delimiter (only if item length is unknown)
    > > > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > > > The delimiters look like tags and have a lengh as well. In case of an
    > > > unknown length all length bytes are set to FF.
    > > > If I start with byte 5 of your example and supposed you have a little
    > > > endian transfer syntax it looks like:
    > > > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > > > length.

    >
    > > > Have a closer look at what comes before byte 5 the first 4 bytes might
    > > > be an unknown length as well. So the 4 bytes preceding the posted
    > > > buffer will show the tag.
    > > > Another possibility is you are in the pixel data and deal with have
    > > > frame delimiters which use items as well. - See Annex A4. However in
    > > > that case you shall have a defined item length.

    >
    > > > Thomas




  7. Re: Hello

    On Aug 13, 3:11 pm, sebastian.ha...@gmail.com wrote:
    > And the Value Length is also always going to be Little Endian,
    > right ??
    >
    > On Aug 13, 6:03 am, sebastian.ha...@gmail.com wrote:
    >
    > > Ok.. Thanks Thomas .. I read Part 5 Section 7.5 and now I understand
    > > my mistake...
    > > But I have one more question.........The GroupNumber and ElementNumber
    > > are always going to be stored in Little Endian format ?? Correct ???
    > > Regards

    >
    > > On Aug 13, 5:37 am, sebastian.ha...@gmail.com wrote:

    >
    > > > Hello,

    >
    > > > Here is a larger fragment....

    >
    > > > 00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    > > > 00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00

    >
    > > > So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    > > > be the VR ("SQ"). Than, "00 00" has to be the
    > > > length....................Than
    > > > "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    > > > VR of this tag and "00 E0" has to be the length of the value that
    > > > follows ... However,
    > > > the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    > > > followed by some other DICOM tag....
    > > > Do you see what I'm saying ?

    >
    > > > Best regards,
    > > > Seb

    >
    > > > On Aug 13, 3:42 am, Thomas Freier wrote:

    >
    > > > > Hi Sebastian,
    > > > > the parsing you show does not exactly fit, it could be part of a
    > > > > sequence of items, where sequence and item have unknown length.

    >
    > > > > Please have a look at Part 5 Section 7.5 for an explanation.
    > > > > In short words:

    >
    > > > > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > > > > SQ LLLL is the 4 bytes length value.
    > > > > now in the value field of that tag you have a sequence of items where
    > > > > each item consists of embedded tags.
    > > > > To mark the begining, end of an item and end of the sequence some
    > > > > delimiters are defined:
    > > > > FFFE, E000 : Item start (always there)
    > > > > FFFE, E00D: Item delimiter (only if item length is unknown)
    > > > > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > > > > The delimiters look like tags and have a lengh as well. In case of an
    > > > > unknown length all length bytes are set to FF.
    > > > > If I start with byte 5 of your example and supposed you have a little
    > > > > endian transfer syntax it looks like:
    > > > > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > > > > length.

    >
    > > > > Have a closer look at what comes before byte 5 the first 4 bytes might
    > > > > be an unknown length as well. So the 4 bytes preceding the posted
    > > > > buffer will show the tag.
    > > > > Another possibility is you are in the pixel data and deal with have
    > > > > frame delimiters which use items as well. - See Annex A4. However in
    > > > > that case you shall have a defined item length.

    >
    > > > > Thomas


    No,

    The endian depends from the transfer syntax, specified in the first
    group 0x0002.
    I use this method to know the endian type of the group 0x0002: if the
    first group I read is 0x0200 then it means I have to reverse the
    endian. Then I use the transfer syntax to decide the endian of the
    other groups.


  8. Re: Hello

    On Aug 13, 6:25 am, paolo.brand...@gmail.com wrote:
    > On Aug 13, 3:11 pm, sebastian.ha...@gmail.com wrote:
    >
    >
    >
    > > And the Value Length is also always going to be Little Endian,
    > > right ??

    >
    > > On Aug 13, 6:03 am, sebastian.ha...@gmail.com wrote:

    >
    > > > Ok.. Thanks Thomas .. I read Part 5 Section 7.5 and now I understand
    > > > my mistake...
    > > > But I have one more question.........The GroupNumber and ElementNumber
    > > > are always going to be stored in Little Endian format ?? Correct ???
    > > > Regards

    >
    > > > On Aug 13, 5:37 am, sebastian.ha...@gmail.com wrote:

    >
    > > > > Hello,

    >
    > > > > Here is a larger fragment....

    >
    > > > > 00 08 00 10 11 53 51 00 00 ff ff ff ff fe ff 00 e0 ff ff ff ff 08 00
    > > > > 00 00 55 4c 04 00 10 00 00 00 08 00 50 11 55 49 00 00

    >
    > > > > So "00 08 00 10" has to be Dicom Tag (0x0800,0x1000) and 11 53 has to
    > > > > be the VR ("SQ"). Than, "00 00" has to be the
    > > > > length....................Than
    > > > > "FF FF FF FF" has to be a tag (0xFFFF,0xFFFF) , "FE FF" has to be the
    > > > > VR of this tag and "00 E0" has to be the length of the value that
    > > > > follows ... However,
    > > > > the value that follows only contains 4 bytes (ff ff ff ff) .. and is
    > > > > followed by some other DICOM tag....
    > > > > Do you see what I'm saying ?

    >
    > > > > Best regards,
    > > > > Seb

    >
    > > > > On Aug 13, 3:42 am, Thomas Freier wrote:

    >
    > > > > > Hi Sebastian,
    > > > > > the parsing you show does not exactly fit, it could be part of a
    > > > > > sequence of items, where sequence and item have unknown length.

    >
    > > > > > Please have a look at Part 5 Section 7.5 for an explanation.
    > > > > > In short words:

    >
    > > > > > (gggg,eeee) LLLL Value where gggg,eeee is a "normal tag" with a VR of
    > > > > > SQ LLLL is the 4 bytes length value.
    > > > > > now in the value field of that tag you have a sequence of items where
    > > > > > each item consists of embedded tags.
    > > > > > To mark the begining, end of an item and end of the sequence some
    > > > > > delimiters are defined:
    > > > > > FFFE, E000 : Item start (always there)
    > > > > > FFFE, E00D: Item delimiter (only if item length is unknown)
    > > > > > FFFE, E0DD: Sequence delimiter (only if sequence length is unknown)
    > > > > > The delimiters look like tags and have a lengh as well. In case of an
    > > > > > unknown length all length bytes are set to FF.
    > > > > > If I start with byte 5 of your example and supposed you have a little
    > > > > > endian transfer syntax it looks like:
    > > > > > FFFE, E000 FFFF FFFF which is begining of an item with unknown
    > > > > > length.

    >
    > > > > > Have a closer look at what comes before byte 5 the first 4 bytes might
    > > > > > be an unknown length as well. So the 4 bytes preceding the posted
    > > > > > buffer will show the tag.
    > > > > > Another possibility is you are in the pixel data and deal with have
    > > > > > frame delimiters which use items as well. - See Annex A4. However in
    > > > > > that case you shall have a defined item length.

    >
    > > > > > Thomas

    >
    > No,
    >
    > The endian depends from the transfer syntax, specified in the first
    > group 0x0002.
    > I use this method to know the endian type of the group 0x0002: if the
    > first group I read is 0x0200 then it means I have to reverse the
    > endian. Then I use the transfer syntax to decide the endian of the
    > other groups.




    Ok so to sum up ...

    - Group 2 elements are always in Explicit VR Little Endian
    - Group Numbers and Element Numbers are always Little Endian
    - Value Length can be Big Endian or Little Endian depending on the
    transfer syntax
    - Value is Big Endian or Little Endian depending on the transfer
    syntax but character strings are not affected by this.

    Is that correct now ?










  9. Re: Hello

    paolo got it very well already. Your sum up is almost correct.
    As you want to decode files from byte level you need to have a lot of
    the encoding stuff in mind.

    For media it is like this:

    - Group 2 elements: always explicit little endian (btw. it would never
    be 0x0002,xxxx). Reason: so you always know to read the file set
    header.
    - transfer syntax for a file is taken from (0002,0010), here you find
    a UID look it up in part 6, then you know how the data set is encoded.
    - data set tags: are encoded according to the transfer syntax

    Regarding little/big endian:
    - tag group/element # and length are according to the endianism, since
    they are words not bytes.
    - value field is depending on endianism if it is word oriented (OW,
    US...) - not byte oriented (e.g. strings, or VR of OB).
    Exception: an encapsulated transfer syntax (something like JPEG) means
    the pixel data is JPEG and the rest of data set tags are explicit VR
    little endian.
    Details, see Part 5. Section 10.

    additionally the next things you might come accross are:
    - you have to deal with different attribute formats, implicit vr
    little endian always 4 byte length field, explicit vr has short and
    long representations depending on VR. Like paolo said, see also part 5
    section 7 for details.
    - you have to deal with sequences as described before
    - you have to deal with repeting groups which are different as well
    - you have to deal with private tags

    Best regards

    Thomas





+ Reply to Thread