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

[David Clunie]

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.