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

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> 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.


Je l'ai appliqué.
une VR a OW marchera qq soit la taille des Pixels ...

JP

>
>
> 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
>
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>