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

[Jean-Pierre ROUX]

Hi!

Best wishes for the new DICOM year ;-)

If I try to sumarize  David's advice :
  - Let's take OW as the VR for any Pixel Data element (easy ...).
  - Let's compute group 0002 length (I already wrote it)

  - The next chalenge to face will be to take into account 'Transfert 
Syntax' field.
Nowadays, we don't care about it : in order to be able to read 
ACR-NEMA images as well (with NO group 0002, and NO 'Transfert 
Syntax' field) we just use an heuristic try to guess (and *we guess* 
...) if the image is coded in the same way (big endian /little 
endian) the current processor works.

Of course all the stuff will break when we'll get a Big Endian coded 
'true DICOM' image (Looking at the first elements -of group 0002- our 
heuristic will tell us the image is 'Little Endian' ...)

To check the new code we're gonna write, we'll need a 'Big Endian Dicom Image'.
Does anyone of you knows where we can get such an image?
(Probabely David has got some, but I'm too shy to ask him ;-)


JP


 

At 9:09 -0500 27/12/04, David Clunie wrote:
>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.
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

   Jean-Pierre ROUX
   UMR CNRS 5515-CREATIS
   Laboratoire de Radiologie Experimentale
   Hopital Cardiologique
   28 Avenue du Doyen LEPINE
   B.P. Lyon-Montchat
   69394 Lyon Cedex 03
 
   Tel      : (+33) 04 72 35 74 12
   Fax      : (+33) 04 72 68 49 16
   URL      : http://www.creatis.univ-lyon1.fr
   e-mail   : jpr at creatis.univ-lyon1.fr