[Dcmlib] [Fwd: Re: [Insight-developers] GDCM problems with created dicom]

[Mathieu Malaterre]

Est-ce que vous avez lu la reponse de David Clunie ?

Est-ce que j'applique le changement dans le dictionaire finalement ou 
pas ? Je suis un peu perdu pour tout avouer.


Bonne Anne'e !
Mathieu

-------- Original Message --------
Subject: Re: [Insight-developers] GDCM problems with created dicom
Date: Mon, 27 Dec 2004 09:09:06 -0500
From: David Clunie <dclunie at dclunie.com>
Reply-To: dclunie at dclunie.com
CC: dcmlib at creatis.insa-lyon.fr, 
"'insight-developers at public.kitware.com'" 
<insight-developers at public.kitware.com>
References: <D95313D68743304EA8BD26E7B44ACF8E01187CAC at xmb04crdge.crd.ge.com>

Lorensen, William E (Research) wrote:

> The other problem was that the pixel data in the dictionary for
> group/element
> 7fe0 0010 had a representation of OB, not OW.
> 
> Most readers probably don't use this because this info can be derived from
> other tags. Of course, this representation should vary depending on whether
> the data is chars or shorts, but the current gdcm code won't let you change
> a representation on the fly (as far as I can tell).
> 
> Since most medical data is 16 bit, I have changed the entry in the
> dictionary from "OB" to "OW". Now I can generate files that the dicom3tools
> can read.

There rules for whether or not Pixel Data (7fe0,0010) should be OB or OW 
depend
on Bits Allocated (0028,0100) and are defined in DICOM PS 3.5 A.2, and are:

"-where Bits Allocated (0028,0100) has a value greater than 8 shall have 
Value
Representation OW and shall be encoded in Little Endian;
-where Bits Allocated (0028,0100) has a value less than or equal to 8 
shall have the
Value Representation OB or OW and shall be encoded in Little Endian."

so on encoding, always using OW will work.

Most importantly, when Bits Allocated (0028,0100) is > 8, the VR must 
NOT be OB,
at least in explicit VR transfer syntaxes.

(As a general rule, for complex attributes like (7fe0,0010) a single 
dictionary
entry for VR does not suffice and special code based on the particular 
element
is always required).

>>Unfortunately yes. There has been some mail on the gdcm mailing list 
>>about this issue. e-film had also some trouble reading some DICOM imagea 
>>produced by GDCM. It appears that the length of group 0x0002 was wrong. 
>>The easy solution was simply to remove this tag from the output.
>>
>>As a quick fix I can remove this tag also from itkGDCMImageIO, until 
>>they rewrite the function that calculate the lenght of group 0x0002.
>>
>>How does that sound ?

You should not do that.

See PS 3.10 7.1. Group Length (0002,0000) is Type 1 (required with a value).

Whilst group lengths are deprecated for most of the dataset, this is not 
true
for the meta information header group 0002 elements, since the meta
information header has a fixed transfer syntax (explicit VR little endian)
and the rest of the data set may have a different transfer syntax, which is
specified by Transfer Syntax UID (0002,0010). The group length (0002,0000)
is required in order to know when one reaches the end of the 
meta-information
header and hence when to change transfer syntax. You cannot just look at the
next group and back up if it is not 0002, because some transfer syntaxes are
encoded completely differently (e.g. deflate compresses the entire dataset,
but not the meta information header).

It is absolutely vital that (0002,0000) be encoded, or some legal DICOM 
parsers
may fail on the files you write.

Since you have been using dicom3tools for various checks, I would 
suggest that
you use dciodvfy to check any files that you create, and if it reports 
errors,
then investigate. The validator is not perfect but usually worth listening
to, especially if it can't even parse the dataset due to a fundamental 
encoding
error. In today's version I have added a specific check to make sure that
(0002,0000) is present, something that I had overlooked explicitly checking
for before.

David

PS. Reading through the gdcm mailing list archives, though my french is not
very good, I noticed reference to a comp.protocols.dicom posting about
the same message "Assertion `bitsallocated <= bytesinword*8u' failed"
occurring when trying to use dicom3tools to create jpeg compressed images,
which they won't do; this has nothing to do with getting the same message
in the current case when 16 bit images are encoded as OB VR, which is just
wrong. I have avoided changing my toolkit to remove this assertion, in order
to detect this encoding error.

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers