[Insight-developers] dicom private tag advice

[Mathieu Malaterre]

Richard,

On Wed, Jun 10, 2009 at 5:36 AM, Richard Beare<richard.beare at gmail.com> wrote:
> Hi,
>
> I'm struggling with reading private tags using itk/gdcm 2.0.11. The
> tags are displayed by gdcmdump - e.g.
>
> (0051,0010) LO [SIEMENS MR HEADER ]                               #
> 18,1 Private Creator
> (0051,1008) CS [IMAGE NUM 4 ]                                     #
> 12,1 CSA Image Header Type
> (0051,1009) LO [1.0 ]                                             #
> 4,1 CSA Image Header Version ??
> (0051,100a) LO (SH) [TA 00.23]                                    # 8,1 ?
> (0051,100b) LO (SH) [144*256 ]                                    #
> 8,1 AcquisitionMatrixText
> (0051,100c) LO (SH) [FoV 318*340 ]                                # 12,1 ?
> (0051,100d) SH [SP H21.8]                                         # 8,1 ?
> (0051,100e) LO (SH) [Tra>Cor(39.4)>Sag(-25.9)]                    # 24,1 ?
> (0051,100f) LO [T:BO1,2;SP1-3 ]                                   #
> 14,1 CoilString
> (0051,1011) LO [p2]                                               #
> 2,1 PATModeText
> (0051,1012) SH [TP 0]                                             # 4,1 ?
> (0051,1013) SH [+LPH]                                             #
> 4,1 PositivePCSDirections
> (0051,1016) LO [p2 M/DIS2D]                                       # 10,1 ?
> (0051,1017) SH [SL 8.0]                                           # 6,1 ?
> (0051,1018) SH [CT]                                               # 2,1 ?
> (0051,1019) LO [A1]                                               # 2,1 ?
>
>
> DicomImageReadPrintTags does not display these tags. My code, derived
> from this is failing too. I thought the issues may relate to casting
> to strings, but the tags don't appear to be in the dictionary at all,
> since the call to Find is failing.

The behavior for loading a particular tag in the metadatadictionary is
poorly documented.
Long story short, because gdcm 1.2.0 did not support VR:UN element,
the only way to be able to write a particular DICOM attribute is to
know information about the tag. Which was done in GDCM 1.x using:

while ( )
  if ( attribute[i]->GetName() != unknown )
    load( attribute[i] );

This would guarantee that we knew enough information to be able to
rewrite the attribute using it's VR.

When I rewrote this while loop in GDCM 2.x I changed (my mistake) it into:

while ( )
  if ( attribute[i]->IsPublic() )
    load( attribute[i] );

now that GDCM 2.x:
1. Properly handle private attributes
2. It properly handle VR:UN attribute

It seems reasonable to add a minimal support for them. Please fill in
a bug report (http://itk.org/Bug) & assign it to me. Thx.

> I have the following enabled
>
>  dicomIO->LoadPrivateTagsOn();
>  dicomIO->LoadSequencesOn();

Those are the default. BTW the documentation for those tags can be
found in the cxx file. The behavior might not be /exactly/ what you
think this is doing.

/*
 * m_LoadPrivateTagsDefault:
 * When this flag is set to false, GDCM will try to use the value
stored in each private Group Length attribute value.
 * This is a modest optimization feature that can be found in some
ACR-NEMA file and/or DICOM pre-2008 file.
 * Because it is required by the standard that DICOM file reader can
read file where Group Length attribute value
 * would be invalid, turning this flag to off, on the one hand might
lead to some speed improvement, but on the
 * other hand will make your DICOM implementation non-standard.
 * Technically Group Length value could be incorrect and GDCM might
even seek over some public element and not
 * just the desired current group of attributes. Do not turn this
option to false unless you understand the
 * consequences.
 *
 * m_LoadSequencesDefault:
 * Following the same idea (modest speed improvement), one can use a
feature from DICOM and use the Value Length
 * of a Sequence attribute to 'seek' over a large number of nested attributes.
 * Again this feature can lead to some modest speed improvement, but
seek'ing over public sequence is not
 * a good idea. For instance you could be reading some new Enhanced MR
Image Storage, where the Pixel Spacing
 * is stored within a Sequence attribute, therefore Pixel Spacing
would not be correct after a call to
 * ExecuteInformation.
 */

For your particular problem, you'll have to load a file using
gdcm::Reader. Let me know if you need help in writing /pure/ gdcm 2.x
code to be able to retrieve those tags. Because GDCM 2.x correctly
handle the double-lookup for private tag I would encourage you to use
the gdcm::PrivateTag API to retrieve them.

HTH,
-- 
Mathieu