[Insight-users] Different tags after GetMetaDataDictionary(Array) and SetMetaDataDictionary(Array)

[Mathieu Malaterre]

On Wed, Jan 7, 2009 at 11:41 AM, Stéphane CALANDE <scalande at gmail.com> wrote:
> The ones that changed :
>
> File Meta Elements Group Length

Come'on :)
At least open once PS 3.5-2008:
ftp://medical.nema.org/medical/dicom/2008/08_05pu.pdf

It defines the general meaning of "group length" which is now
deprecated...except for the very particular case of the file meta
information as defined in PS 3.10-2008 (same base URL: 08_10pu.pdf).

> Media Storage SOP Instance UID

Don't look at attributes with group value=0x0002, this is the header
of a DICOM file (all values are derived from the DICOM dataset).

> Transfer Syntax UID

This is a very low level detail which explain how the following DICOM
dataset will be encoded (right after the file meta information block).

> Implementation Class UID

Group 0x2 => it's meaningless for you

> SOP Instance UID
> Study Instance UID
> Series Instance UID

Good: dataset values. They actually mean something :)
By default ITK will generated new UID, this is the safe bet. There is
an option in itk::GDCMImageIO to keep the UIDs.

> Others tags existed in the original file et disappeared in the new one...
> and the contrary
>
> For example, in the original file, I've a lot of tags like that :
>> 00E1-****
>> 01E1-****
>> 01F1-****
>> 01F7-****
>> 07A1-****
>> 7FDF-****

Same thing read PS 3.5-2008 about group with odd value (aka private group).

> They all dispappeard in the new one.
>
> And in the new one, I can see the following new tags :
>
>> 7FE0-0000
>> FFFE-E000
>> FFFE-E00D
>> FFFE-E0DD

Do you mean 7FE0-0010 ? You did not mention the value for Transfer
Syntax UID, but I would guess you use an encapsulated transfer syntax
(ie. compressed image).
Could you please use the output of, say 'gdcmdump' to send those sort
of thing, indentation really means something...

> I also encountered an other problem.
>
> I have to send the generated DICOM file to the hospital network
> The software that send the file to the network parse all the DICOM tags, but
> it doesn't support the tags having a length of "-1" (undefined length I
> think...)
> So : when I send an original DICOM file, it works ! (no "-1" length), but
> when I send the new generated DICOM file, it doesn't work because of the
> "-1" length.

...weird...
Two things:
- ITK/GDCM does not load Sequence, so AFAIK the output DICOM should be
free of any undefined length sequence.
- There are 3rd party tool that will allow rewritting undefined length
to defined length Sequence (see dcmtk: dcmconv)... which make me think
this would be a cool option to gdcmconv.

What I also suspect is that your receiving application simply does not
support some particular compression. Do not set the Compression flag
in ITK. This way you'll store the DICOM file as RAW, which is garantee
to be support by all DICOM implementors.

> I suppose that the appearance of the "-1" length in a tag is a consequence
> of get/setMetaDataDictionary...

no.

> The tag that causes the problem is a tag of the group "0008". (I d'ont know
> the element) I mean that tag had a defined length BEFORE and has a undefined
> length (-1) AFTER.

Oh...ok. So this file has never been processed by ITK/GDCM then ?
Again use gdcmdump to dump all the group=0x8 attributes.



-- 
Mathieu