7.8.1 PRIVATE DATA ELEMENT TAGS: clarification - DICOM

This is a discussion on 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification - DICOM ; Hi, 1. There is no restriction for a specific Private Creator Data Element (PCDE) to be unique within the same group, right ? Decoders of Private Data would have to handle the case where a PCDE would be repeated and ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

  1. 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    Hi,


    1.
    There is no restriction for a specific Private Creator Data Element
    (PCDE) to be unique within the same group, right ?
    Decoders of Private Data would have to handle the case where a PCDE
    would be repeated and should NOT stop on the first instance of a
    particular PCDE, right ?

    Eg. when searching for the tag associated with
    (0x0029,0x0010,"SIEMENS CSA HEADER") in the following (pseudo)
    dataset:

    (0029,0010) LO [SIEMENS CSA HEADER] # 18, 1
    PrivateCreator
    (0029,0011) LO [SIEMENS MEDCOM HEADER] # 22, 1
    PrivateCreator
    (0029,0012) LO [SIEMENS MEDCOM HEADER2] # 22, 1
    PrivateCreator
    (0029,0013) LO [SIEMENS CSA HEADER] # 18, 1
    PrivateCreator
    (0029,1008) CS [IMAGE NUM 4] # 12, 1
    CSAImageHeaderType
    (0029,1009) LO [20050723] # 8, 1
    CSAImageHeaderVersion
    (0029,1010) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    (0029,1018) CS [MR] # 2, 1
    CSASeriesHeaderType
    (0029,1019) LO [20050723] # 8, 1
    CSASeriesHeaderVersion
    (0029,1020) OB 53\56\31\30\04\03\02\01\2c\00\00\00\4d
    \00\00\00\55\73\65\64\50\61... # 51520, 1 CSASeriesHeaderInfo
    (0029,1131) LO [4.0.163088300] # 14, 1
    PMTFInformation1
    (0029,1132) UL 32768 # 4, 1
    PMTFInformation2
    (0029,1133) UL 0 # 4, 1
    PMTFInformation3
    (0029,1134) CS [DB TO DICOM] # 12, 1
    PMTFInformation4
    (0029,1260) ?? 63\6f\6d\20 # 4, 1
    Unknown Tag & Data
    (0029,1310) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo

    one should return two instances, correct ?

    2.
    What exactly are the private tag: (gggg,0000-0009) (where gggg is
    odd). As far as I understand PS 3.5 those elements are not addressed.
    The only one defined is gggg,0000 which is a private element, but not
    a PCDE (retired group length).

    3.
    When an application is requested to encode as Explicit DataSet an
    Implicit DataSet, what should the application do with the VR for
    PCDEs. As far as I understand it is required to be VR=LO, but I have
    seen application using VR=UN. Same question for (gggg,0000) element,
    is it VR=UN or VR=UL ?

    Thanks !
    -Mathieu

  2. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    On Jun 6, 11:13 am, Mathieu Malaterre
    wrote:
    > Hi,
    >
    > 1.
    > There is no restriction for a specific Private Creator Data Element
    > (PCDE) to be unique within the same group, right ?
    > Decoders of Private Data would have to handle the case where a PCDE
    > would be repeated and should NOT stop on the first instance of a
    > particular PCDE, right ?
    >
    > Eg. when searching for the tag associated with
    > (0x0029,0x0010,"SIEMENS CSA HEADER") in the following (pseudo)
    > dataset:
    >
    > (0029,0010) LO [SIEMENS CSA HEADER] # 18, 1
    > PrivateCreator
    > (0029,0011) LO [SIEMENS MEDCOM HEADER] # 22, 1
    > PrivateCreator
    > (0029,0012) LO [SIEMENS MEDCOM HEADER2] # 22, 1
    > PrivateCreator
    > (0029,0013) LO [SIEMENS CSA HEADER] # 18, 1
    > PrivateCreator
    > (0029,1008) CS [IMAGE NUM 4] # 12, 1
    > CSAImageHeaderType
    > (0029,1009) LO [20050723] # 8, 1
    > CSAImageHeaderVersion
    > (0029,1010) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    > (0029,1018) CS [MR] # 2, 1
    > CSASeriesHeaderType
    > (0029,1019) LO [20050723] # 8, 1
    > CSASeriesHeaderVersion
    > (0029,1020) OB 53\56\31\30\04\03\02\01\2c\00\00\00\4d
    > \00\00\00\55\73\65\64\50\61... # 51520, 1 CSASeriesHeaderInfo
    > (0029,1131) LO [4.0.163088300] # 14, 1
    > PMTFInformation1
    > (0029,1132) UL 32768 # 4, 1
    > PMTFInformation2
    > (0029,1133) UL 0 # 4, 1
    > PMTFInformation3
    > (0029,1134) CS [DB TO DICOM] # 12, 1
    > PMTFInformation4
    > (0029,1260) ?? 63\6f\6d\20 # 4, 1
    > Unknown Tag & Data
    > (0029,1310) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    >
    > one should return two instances, correct ?
    >
    > 2.
    > What exactly are the private tag: (gggg,0000-0009) (where gggg is
    > odd). As far as I understand PS 3.5 those elements are not addressed.
    > The only one defined is gggg,0000 which is a private element, but not
    > a PCDE (retired group length).
    >
    > 3.
    > When an application is requested to encode as Explicit DataSet an
    > Implicit DataSet, what should the application do with the VR for
    > PCDEs. As far as I understand it is required to be VR=LO, but I have
    > seen application using VR=UN. Same question for (gggg,0000) element,
    > is it VR=UN or VR=UL ?
    >
    > Thanks !
    > -Mathieu


    Found an answer for #3, in 6.2.2 Unknown (UN) Value Representation

    ....
    The UN VR shall not be used for Private Creator Data Elements (i.e.
    the VR is equal to LO, see section
    7.8.1).
    ....

    -Mathieu

  3. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    On Jun 6, 4:13*am, Mathieu Malaterre
    wrote:
    > Hi,
    >
    > 1.
    > * There is no restriction for a specific Private Creator Data Element
    > (PCDE) to be unique within the same group, right ?
    > * Decoders of Private Data would have to handle the case where a PCDE
    > would be repeated and should NOT stop on the first instance of a
    > particular PCDE, right ?
    >
    > * Eg. when searching for the tag associated with
    > (0x0029,0x0010,"SIEMENS CSA HEADER") in the following (pseudo)
    > dataset:
    >
    > (0029,0010) LO [SIEMENS CSA HEADER] * * * * * * * * * * # *18, 1
    > PrivateCreator
    > (0029,0011) LO [SIEMENS MEDCOM HEADER] * * * * * * * * *# *22, 1
    > PrivateCreator
    > (0029,0012) LO [SIEMENS MEDCOM HEADER2] * * * * * * * * # *22, 1
    > PrivateCreator
    > (0029,0013) LO [SIEMENS CSA HEADER] * * * * * * * * * * # *18, 1
    > PrivateCreator
    > (0029,1008) CS [IMAGE NUM 4] * * * * * * * * * * * * * *# *12, 1
    > CSAImageHeaderType
    > (0029,1009) LO [20050723] * * * * * * * * * * * * * * * # * 8, 1
    > CSAImageHeaderVersion
    > (0029,1010) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    > (0029,1018) CS [MR] * * * * * * * * * * * * * * * * * * # * 2, 1
    > CSASeriesHeaderType
    > (0029,1019) LO [20050723] * * * * * * * * * * * * * * * # * 8, 1
    > CSASeriesHeaderVersion
    > (0029,1020) OB 53\56\31\30\04\03\02\01\2c\00\00\00\4d
    > \00\00\00\55\73\65\64\50\61... # 51520, 1 CSASeriesHeaderInfo
    > (0029,1131) LO [4.0.163088300] * * * * * * * * * * ** *# *14, 1
    > PMTFInformation1
    > (0029,1132) UL 32768 * * * * * * * * * * * * * * * * * *# * 4, 1
    > PMTFInformation2
    > (0029,1133) UL 0 * * * * * * * * * * * * * * * * * * * *# * 4, 1
    > PMTFInformation3
    > (0029,1134) CS [DB TO DICOM] * * * * * * * * * * * * * *# *12, 1
    > PMTFInformation4
    > (0029,1260) ?? 63\6f\6d\20 * * * * * * * * * * * ** * *# * 4, 1
    > Unknown Tag & Data
    > (0029,1310) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    >
    > * one should return two instances, correct ?
    >

    This behavior is specific to implementations of tool kit. As per
    standard there is no need for to PCDE to be unique. It is quite
    possible that same PCDE would like to add private blocks in multiple
    odd number groups (DICOM suggests to use nearest odd group number to
    extend specific portion of DICOM standard information objects)
    > 2.
    > * What exactly are the private tag: (gggg,0000-0009) (where gggg is
    > odd). As far as I understand PS 3.5 those elements are not addressed.
    > The only one defined is gggg,0000 which is a private element, but not
    > a PCDE (retired group length).
    >

    This question is not clear....
    > 3.
    > * When an application is requested to encode as Explicit DataSet an
    > Implicit DataSet, what should the application do with the VR for
    > PCDEs. As far as I understand it is required to be VR=LO, but I have
    > seen application using VR=UN. Same question for (gggg,0000) element,
    > is it VR=UN or VR=UL ?
    >
    > Thanks !
    > -Mathieu



  4. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    On Jun 7, 6:05 pm, Sathya wrote:
    > On Jun 6, 4:13 am, Mathieu Malaterre
    > wrote:
    >
    > > Hi,

    >
    > > 1.
    > > There is no restriction for a specific Private Creator Data Element
    > > (PCDE) to be unique within the same group, right ?
    > > Decoders of Private Data would have to handle the case where a PCDE
    > > would be repeated and should NOT stop on the first instance of a
    > > particular PCDE, right ?

    >
    > > Eg. when searching for the tag associated with
    > > (0x0029,0x0010,"SIEMENS CSA HEADER") in the following (pseudo)
    > > dataset:

    >
    > > (0029,0010) LO [SIEMENS CSA HEADER] # 18, 1
    > > PrivateCreator
    > > (0029,0011) LO [SIEMENS MEDCOM HEADER] # 22, 1
    > > PrivateCreator
    > > (0029,0012) LO [SIEMENS MEDCOM HEADER2] # 22, 1
    > > PrivateCreator
    > > (0029,0013) LO [SIEMENS CSA HEADER] # 18, 1
    > > PrivateCreator
    > > (0029,1008) CS [IMAGE NUM 4] # 12, 1
    > > CSAImageHeaderType
    > > (0029,1009) LO [20050723] # 8, 1
    > > CSAImageHeaderVersion
    > > (0029,1010) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo
    > > (0029,1018) CS [MR] # 2, 1
    > > CSASeriesHeaderType
    > > (0029,1019) LO [20050723] # 8, 1
    > > CSASeriesHeaderVersion
    > > (0029,1020) OB 53\56\31\30\04\03\02\01\2c\00\00\00\4d
    > > \00\00\00\55\73\65\64\50\61... # 51520, 1 CSASeriesHeaderInfo
    > > (0029,1131) LO [4.0.163088300] # 14, 1
    > > PMTFInformation1
    > > (0029,1132) UL 32768 # 4, 1
    > > PMTFInformation2
    > > (0029,1133) UL 0 # 4, 1
    > > PMTFInformation3
    > > (0029,1134) CS [DB TO DICOM] # 12, 1
    > > PMTFInformation4
    > > (0029,1260) ?? 63\6f\6d\20 # 4, 1
    > > Unknown Tag & Data
    > > (0029,1310) OB 53\56\31\30\04\03\02\01\38\00\00\00\4d
    > > \00\00\00\45\63\68\6f\4c\69... # 6788, 1 CSAImageHeaderInfo

    >
    > > one should return two instances, correct ?

    >
    > This behavior is specific to implementations of tool kit. As per
    > standard there is no need for to PCDE to be unique. It is quite
    > possible that same PCDE would like to add private blocks in multiple
    > odd number groups (DICOM suggests to use nearest odd group number to
    > extend specific portion of DICOM standard information objects)> 2.


    Ok so to summarize what you are saying, it is possible (=valid) for a
    DICOM file to have two instances of the same Data Element where the
    private tag is (e.g) (0x0029,0x0010,"SIEMENS CSA HEADER"). This is
    very suprising to me, as this is not valid for public element, and
    implementors, are asked to drop duplicates.

    > > What exactly are the private tag: (gggg,0000-0009) (where gggg is
    > > odd). As far as I understand PS 3.5 those elements are not addressed.
    > > The only one defined is gggg,0000 which is a private element, but not
    > > a PCDE (retired group length).

    >
    > This question is not clear....


    Question:
    What is this tag (0009,0001), is this a private tag ?
    Answer
    No: because element should start at value 0010 at a minimum. And there
    are not public element either, since the group element is odd.

    Which make it a ... ?

    Thanks,
    -Mathieu

  5. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    > There is no restriction for a specific Private Creator Data Element
    > (PCDE) to be unique within the same group, right ?


    Correct.

    > Decoders of Private Data would have to handle the case where a PCDE
    > would be repeated and should NOT stop on the first instance of a
    > particular PCDE, right ?


    That's an application specific problem, and not something that the
    DICOM standard is likely to mandate. As long as you perform a look-up
    from a private tag to the related reservation element (gggg,00xx),
    this does not matter.

    > 2.
    > What exactly are the private tag: (gggg,0000-0009) (where gggg is
    > odd).


    Illegal, just as (0005,xxxx) or (0007,xxxx) tags are.

    > 3.
    > When an application is requested to encode as Explicit DataSet an
    > Implicit DataSet, what should the application do with the VR for
    > PCDEs. As far as I understand it is required to be VR=LO, but I have
    > seen application using VR=UN. Same question for (gggg,0000) element,
    > is it VR=UN or VR=UL ?


    When encoding an explicit VR dataset as implicit VR, you just don't store
    the VR and there is no problem for the encoder. When converting in the
    other direction, (gggg,00xx) where xx >= 0x10 is "LO" by definition.
    You convert attributes to UN when you don't know their VR but in this case
    you do know.

    Regards,
    Marco Eichelberg
    OFFIS

  6. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    On Jun 9, 11:56*am, Marco Eichelberg
    wrote:
    > > * There is no restriction for a specific Private Creator Data Element
    > > (PCDE) to be unique within the same group, right ?

    >
    > Correct.
    >
    > > * Decoders of Private Data would have to handle the case where a PCDE
    > > would be repeated and should NOT stop on the first instance of a
    > > particular PCDE, right ?

    >
    > That's an application specific problem, and not something that the
    > DICOM standard is likely to mandate. As long as you perform a look-up
    > from a private tag to the related reservation element (gggg,00xx),
    > this does not matter.
    >


    But then the relation

    (private creator id, gggg, xxee) -> data element

    is no longer injective: There may be private data elements with equal
    private element tag xxee in different reserved blocks (gggg,ee00-eeFF)
    associated with the same Private Creator ID by corresponding PCDEs
    (gggg,00ee).

    And DICOM gives no hint how to deal with that

    -gunter


  7. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    Hi Gunter

    I would say that this is covered in principle by the PS 3.5 7.1
    "The Data Elements ... shall occur at most once in a Data Set"
    rule, since the data element is defined by the tuple
    (private creator,gggg,ee) where xxee is the element
    number and xx is arbitrary and has no inherent meaning and
    does not serve to disambiguate the data element.

    E.g.:

    (0019,0030) Private Creator ID = "Smith"
    ....
    (0019,0032) Private Creator ID = "Smith"
    ....
    (0019,3015) Fractal Index = "32"
    ....
    (0019,3215) Fractal Index = "32"

    would be illegal because even though they are assigned different
    (completely arbitrary) blocks, with the same group, element
    number and private creator, (0019,3015) and (0019,3215) are the
    "same" data element.

    I think how to deal with this is obvious ... it is an error,
    though obviously a parser should not "stop" because of it.

    If you think that the standard is unclear, you could write a
    CP that added a note to emphasize this.

    In our example, if the creator actually intended (0019,3015)
    and (0019,3215) to mean different concepts, then they would
    be in error, since DICOM clearly defines that the blocks
    are "dynamically" assigned (PS 3.5 7.8.1), so making the
    interpretation dependent on which particular block is used
    is forbidden.

    Some older pre-DICOM ACR-NEMA implementations from Philips were
    dependent on the block and did re-use the same codes in different
    blocks for different purposes, and so there is some support for
    that in my dicom3tools for these ancient images, but one should
    never see that in contemporary images.

    David

    gunter zeilinger wrote:
    > On Jun 9, 11:56 am, Marco Eichelberg
    > wrote:
    >>> There is no restriction for a specific Private Creator Data Element
    >>> (PCDE) to be unique within the same group, right ?

    >> Correct.
    >>
    >>> Decoders of Private Data would have to handle the case where a PCDE
    >>> would be repeated and should NOT stop on the first instance of a
    >>> particular PCDE, right ?

    >> That's an application specific problem, and not something that the
    >> DICOM standard is likely to mandate. As long as you perform a look-up
    >> from a private tag to the related reservation element (gggg,00xx),
    >> this does not matter.
    >>

    >
    > But then the relation
    >
    > (private creator id, gggg, xxee) -> data element
    >
    > is no longer injective: There may be private data elements with equal
    > private element tag xxee in different reserved blocks (gggg,ee00-eeFF)
    > associated with the same Private Creator ID by corresponding PCDEs
    > (gggg,00ee).
    >
    > And DICOM gives no hint how to deal with that
    >
    > -gunter
    >


  8. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    Hi David,

    On Jun 10, 1:23 pm, David Clunie wrote:
    > Hi Gunter
    >
    > I would say that this is covered in principle by the PS 3.5 7.1
    > "The Data Elements ... shall occur at most once in a Data Set"
    > rule, since the data element is defined by the tuple
    > (private creator,gggg,ee) where xxee is the element
    > number and xx is arbitrary and has no inherent meaning and
    > does not serve to disambiguate the data element.
    >
    > E.g.:
    >
    > (0019,0030) Private Creator ID = "Smith"
    > ...
    > (0019,0032) Private Creator ID = "Smith"
    > ...
    > (0019,3015) Fractal Index = "32"
    > ...
    > (0019,3215) Fractal Index = "32"
    >
    > would be illegal


    Thanks ! I prefer a whole lot that

    > because even though they are assigned different
    > (completely arbitrary) blocks, with the same group, element
    > number and private creator, (0019,3015) and (0019,3215) are the
    > "same" data element.
    >
    > I think how to deal with this is obvious ... it is an error,
    > though obviously a parser should not "stop" because of it.
    >
    > If you think that the standard is unclear, you could write a
    > CP that added a note to emphasize this.


    I have been wanting to do that for a while. So I'll get started on
    this one ASAP.

    > In our example, if the creator actually intended (0019,3015)
    > and (0019,3215) to mean different concepts, then they would
    > be in error, since DICOM clearly defines that the blocks
    > are "dynamically" assigned (PS 3.5 7.8.1), so making the
    > interpretation dependent on which particular block is used
    > is forbidden.
    >
    > Some older pre-DICOM ACR-NEMA implementations from Philips were
    > dependent on the block and did re-use the same codes in different
    > blocks for different purposes, and so there is some support for
    > that in my dicom3tools for these ancient images, but one should
    > never see that in contemporary images.


    I have seen those references in your toolkit, but to be honest never
    really understood how this work. I'll just pretend it never existed

    -Mathieu

  9. Re: 7.8.1 PRIVATE DATA ELEMENT TAGS: clarification

    Thanks David for the clarification. Should have better written:
    "And my interpretation of DICOM gives no hint how to deal with that"
    - gunter

+ Reply to Thread