7.8.1 PRIVATE DATA ELEMENT TAGS: clarification
Mathieu Malaterre
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
Mathieu Malaterre
wrote:
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
Sathya
wrote:
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).
>
Mathieu Malaterre
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
Marco Eichelberg
> (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
gunter zeilinger
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
David Clunie
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
Mathieu Malaterre
On Jun 10, 1:23 pm, David Clunie <dclu...@dclunie.com> 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
gunter zeilinger
"And my interpretation of DICOM gives no hint how to deal with that"
- gunter