0028,3006 LUT Data (nightmare) - DICOM

This is a discussion on 0028,3006 LUT Data (nightmare) - DICOM ; Hello, I am adding some verification on the process to generate the DICOM dictionary from the PDF. And right now I am banging my head against the wall. I never realize that there was (at least one) a case where ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: 0028,3006 LUT Data (nightmare)

  1. 0028,3006 LUT Data (nightmare)

    Hello,

    I am adding some verification on the process to generate the DICOM
    dictionary from the PDF. And right now I am banging my head against the
    wall. I never realize that there was (at least one) a case where VM and
    VR were related:

    0028 3006 LUT Data US or SS 1-n or OW 1

    What kind of structure do you use to store this representation ?

    struct tag
    {
    uint16_t group,
    uint16_t element,
    char *name,
    int VR, // could be an enum
    int VM, //-1 -> 1-n, -2 -> 2-n ...
    bool ret
    }


    Thanks
    Mathieu

  2. Re: 0028,3006 LUT Data (nightmare)

    Mathieu Malaterre wrote:

    > Hello,
    >
    > I am adding some verification on the process to generate the DICOM
    > dictionary from the PDF. And right now I am banging my head against the
    > wall. I never realize that there was (at least one) a case where VM and
    > VR were related:
    >
    > 0028 3006 LUT Data US or SS 1-n or OW 1
    >
    > What kind of structure do you use to store this representation ?
    >
    > struct tag
    > {
    > uint16_t group,
    > uint16_t element,
    > char *name,
    > int VR, // could be an enum
    > int VM, //-1 -> 1-n, -2 -> 2-n ...
    > bool ret
    > }
    >
    >
    > Thanks
    > Mathieu


    Hi Mathieu

    Your nightmare hasn't started yet if you are only at the dictionary
    stage of describing LUTs

    The LUTs are just tables of 16 bit integer values, regardless of
    what the implicit or explicit VR is.

    The number of entries in the LUT is determined for any concrete
    instance by the VL of the attribute (and this should match the
    values defined in the corresponding LUT Descriptor (0028,3002)
    attribute).

    The data dictionary always describes OB and OW VRs as having a
    VM of 1, since conceptually there is a single "value" for these,
    it is just a really big value.

    As far as internal representation for practical use is concerned,
    you really want to determine if each LUT entry is encoded in an
    8 or 16 bit word, and based on that determination (from the
    LUT descriptor), decide whether to encode an array of bytes
    or an array of 16 bit words. Remember that LUTs with 8 bits
    (LUT Descriptor value 3 == 8) in them will have two 8 bit entries
    packed in one US/SS/OW word.

    As far as tabulation within the dictionary is concerned, one
    approach is to use a special (non-DICOM) VR enumerated value
    to flag these special cases; there are a bunch of them in
    the standard.

    Regardless, if you create attributes internal from actual
    instances, you will have to have special LUT Data handling
    code that takes into account both LUT Data and LUT Descriptor,
    just as you need to handle Pixel Data specially; don't forget
    to do the same for the Palette Color LUTs as well.

    David

    PS. The VR choices are a consequence of the realization after the
    standard was first written that for explicit VR encoding, the
    short form of the US/SS VL field is too small in size (16 bits)
    to encode big LUTs. The fix started out for palette color LUTs
    in CP 143 and was propagated to other LUTs in Sup 33; it is a
    shame that we did not have the balls to just retire or remove
    the US/SS variant, as opposed to adding OW, but there was (and
    still is) an installed base issue.


  3. Re: 0028,3006 LUT Data (nightmare)



    Mathieu Malaterre wrote:
    > Hello,
    >
    > I am adding some verification on the process to generate the DICOM
    > dictionary from the PDF. And right now I am banging my head against the
    > wall. I never realize that there was (at least one) a case where VM and
    > VR were related:


    Mathieu,
    An other nightmare you'll have to face, if you want to generate
    something from the pdf dictionary (enven if you do it 'manualy') is
    that some tags are flagged as 'RET' (retired) and have neither a VR no
    a VM, and some others, flagged as 'RET' as well still have their VR and
    VM.
    (you can find the information in older versions of the dictionary)

    Jean-Pierre Roux


    >
    > 0028 3006 LUT Data US or SS 1-n or OW 1
    >
    > What kind of structure do you use to store this representation ?
    >
    > struct tag
    > {
    > uint16_t group,
    > uint16_t element,
    > char *name,
    > int VR, // could be an enum
    > int VM, //-1 -> 1-n, -2 -> 2-n ...
    > bool ret
    > }
    >
    >
    > Thanks
    > Mathieu



  4. Re: 0028,3006 LUT Data (nightmare)

    Btw, Mattieu, would you have any sample of image using "0028 3006 LUT
    Data", and/or a www link were they explain how to use it?

    The only image I was able to find is in the gdcm Data test suite (its
    name is KODAK-12-MONO1); its described ad 'MONOCHROME1'.
    Is "0028 3006 LUT Data" just a trick to modify grey levels ?
    Thx
    Jean-Pierre Roux


  5. Retired element VR and VM, was Re: 0028,3006 LUT Data (nightmare)

    Jean-Pierre Roux jpr@creatis.univ-lyon1.fr wrote:
    >
    > An other nightmare you'll have to face, if you want to generate
    > something from the pdf dictionary (enven if you do it 'manualy') is
    > that some tags are flagged as 'RET' (retired) and have neither a VR no
    > a VM, and some others, flagged as 'RET' as well still have their VR and
    > VM.
    > (you can find the information in older versions of the dictionary)


    The ones that have a VM and VR and are retired were defined in previous
    versions of DICOM.

    The ones that do not were never defined in DICOM but were defined
    in ACR-NEMA prior to DICOM, at which time the concepts of VM and
    VR did not exist, hence their absence. They are still kept in the
    dictionary and flagged as retired to prevent us inadvertantly
    reusing the tag when we assign new attributes.

    David


  6. Re: 0028,3006 LUT Data (nightmare)

    jpr@creatis.univ-lyon1.fr wrote:
    > Btw, Mattieu, would you have any sample of image using "0028 3006 LUT
    > Data", and/or a www link were they explain how to use it?
    >
    > The only image I was able to find is in the gdcm Data test suite (its
    > name is KODAK-12-MONO1); its described ad 'MONOCHROME1'.
    > Is "0028 3006 LUT Data" just a trick to modify grey levels ?
    > Thx
    > Jean-Pierre Roux
    >


    Searching the group for that lead me to:

    http://groups-beta.google.com/group/...bfdbf73e?hl=en

    And therefore I went to:

    ftp://dicom.offis.de/pub/dicom/offis/software/ihe_y2/

    in particular:

    ftp://dicom.offis.de/pub/dicom/offis..._testcases.zip

    HTH
    Mathieu

  7. Re: Retired element VR and VM, was Re: 0028,3006 LUT Data (nightmare)

    David.
    Thank you for explaining.
    So, if one wants to make a Diconnary able to handle both ACR-NEMA and
    DICOM images, he just have to 'translate' the ACR-NEMA data type (AT,
    AN, etc) into the closer VM, and add the relevant line to his own
    dictionnary, right ?

    Btw ...
    'gdcm' Dicom dictionary uses a few tags, such as :

    0018 106b UI 1 Synchronization Frame of Reference
    0028 0122 US 1 Waveform Padding Value
    003a 0002 SQ 1 Waveform Sequence
    003a 0103 CS 1 Data Value Representation
    0040 0552 SQ 1 Specimen Description Sequence
    0040 0553 ST 1 Specimen Description
    0040 09f8 SQ 1 Vital Stain Code Sequence
    0040 a16a ST 1 Bibliographics Citation
    0040 a992 ST 1 Uniform Resource Locator

    that are no longer in the '2004 Dictionary'.
    I Googled for them.
    C programs for NIH site still use them.

    Is it a stuff of their own, or are they definively removed 'official'
    tags?

    Thx again.

    Jean-Pierre Roux


  8. Re: Retired element VR and VM, was Re: 0028,3006 LUT Data (nightmare)

    jpr@creatis.univ-lyon1.fr wrote:

    > So, if one wants to make a Diconnary able to handle both ACR-NEMA and
    > DICOM images, he just have to 'translate' the ACR-NEMA data type (AT,
    > AN, etc) into the closer VM, and add the relevant line to his own
    > dictionnary, right ?


    Yes, that's what I do, and I have seen various vendors do the same.

    I generally make LOs or DSs or ISs or USs out of them based on the
    descriptions in ACR-NEMA, and or experience with vendors using them
    in images that I have encountered. If you look in my dicom3tools
    dictionary you will see the choices that I have made (which vary from
    time to time).

    > Btw ...
    > 'gdcm' Dicom dictionary uses a few tags, such as :
    >
    > 0018 106b UI 1 Synchronization Frame of Reference


    This should be:

    (0020,0200) Synchronization Frame of Reference UID

    > 0028 0122 US 1 Waveform Padding Value


    (5400,100A) Waveform Padding Value

    > 003a 0002 SQ 1 Waveform Sequence


    (5400,0100) Waveform Sequence

    > 003a 0103 CS 1 Data Value Representation


    (50xx,0103) Data Value Representation

    > 0040 0552 SQ 1 Specimen Description Sequence


    No such attribute

    > 0040 0553 ST 1 Specimen Description


    No such attribute

    > 0040 09f8 SQ 1 Vital Stain Code Sequence


    No such attribute

    > 0040 a16a ST 1 Bibliographics Citation


    No such attribute

    > 0040 a992 ST 1 Uniform Resource Locator


    No such attribute

    I suspect these were taken for the draft for trial implementation
    of Sup 23 SR, which was problematic in many ways, not the least
    of which was that some of its attributes with the same number
    were re-used with different purpose and VR, etc.

    Some may have been from early drafts of other supplements (e.g.,
    waveform from the looks of things).

    None of these should ever be used.

    > that are no longer in the '2004 Dictionary'.
    > I Googled for them.
    > C programs for NIH site still use them.
    >
    > Is it a stuff of their own, or are they definively removed 'official'
    > tags?
    >
    > Thx again.
    >
    > Jean-Pierre Roux
    >


+ Reply to Thread