[Dcmlib] GDCM problems with created dicom]

[Jean-Pierre ROUX]

Bonjour.

Maintenant, nous savons *ou* David Clunie va chercher l'info 
'BytesPerWord' : dans la 'Value Representation' de 7FE0,0010.
Qui est une info facultative.
Et, lorsqu'elle y est, si ca ne matche pas avec le reste, il sort en 
erreur, alors que même e-film s'en tape ...

La conclusion de ca, c'est qu'il faudra verifier que nos images, en 
plus d'etre efilm-readable soient egalement D.Clunie-readable
Et vtkgdcmViewer-displayable ... car les images avec PixelSpacing=0.0 
dans les 2 dimensions, telles qu'en propose D.Clunie dans son Data 
set Compression, c'est pas terrible !

Pour ce qui est de la modif de la VR de 7fe0,000 en fonction du contexte ...
est-ce que ca parrait une idee raisonable de creer une Virtual 
DictEntry des que l'on a fini le parsing, et de lui affecter une VR 
qui matche BitsAllocated (et sutout, qui soit modifiable par la suite 
sans tout peter).
Au moment d'une eventuelle ecriture du fichier en utilisant ce 
Header, on pourra   remettre cette VR en concordance avec le reste 
(si l'utilisateur a, par exemple, 'fabriqué' une image 8 bits a 
partir d'une image 16 bits)



At 10:46 -0500 18/12/04, Mathieu Malaterre wrote:
> > Subject: RE: [Insight-developers] GDCM problems with created dicom
> >
> > Mathieu,
> > I found the rest of the problem. The fix you provided was part of the
> > solution.
> > 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.
> >
> > I'll be checking in the changes this morning. It seems that I 
>have to make a
> > trivial change to gdcmDefaultDicts.cxx.in to get the dictionary to rebuild.
> > The dependency on dicomV3.dic is missing.
> >
> > Thanks for your help,
> >
> > Bill
> >
> > -----Original Message-----
> > From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> > Sent: Friday, December 17, 2004 10:55 AM
> > To: Lorensen, William E (Research)
> > Subject: Re: [Insight-developers] GDCM problems with created dicom
> >
> > Done
> >
> > $ cvs ci -m"BUG: The (Meta) Group Length tags contain a wrong lenght.
> > Remove those tags from the output until the calculation of lenght is
> > fixed in gdcm." itkGDCMImageIO.cxx itkGDCMImageIO.h
> > /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.cxx,v  <--
> > itkGDCMImageIO.cxx
> > new revision: 1.43; previous revision: 1.42
> > /cvsroot/Insight/Insight/Code/IO/itkGDCMImageIO.h,v  <--  itkGDCMImageIO.h
> > new revision: 1.9; previous revision: 1.8
> >
> > Lorensen, William E (Research) wrote:
> > > Yes, remove it for now and Ill try it.
> > >
> > > -----Original Message-----
> > > From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> > > Sent: Friday, December 17, 2004 10:39 AM
> > > To: Lorensen, William E (Research)
> > > Cc: insight-developers at public.kitware.com
> > > Subject: Re: [Insight-developers] GDCM problems with created dicom
> > >
> > > Lorensen, William E (Research) wrote:
> > >
> > >>Mathieu,
> > >>I am having trouble with dicom files that we are creating. We are reading
> > >>dicoms, filtering them and creating new dicoms. We are passing the meta
> > >> data from the input to the output unmodified.
> > >>If I run the dicom3tools dcdump program it fails on an assertion
> > >>  dcdump 88_20_0.0625_1.dcm
> > >> you get an error messages that includes the phrase
> > >>  Assertion `bitsallocated <= bytesinword*8u' failed.
> > >>
> > >>I have tried to track things down further, and there is trouble in the
> > >>0x0002 area. I notice lots of FIXME comments in the gdcm code aroubd
> > >>processing of the 0x0002 tags.
> > >>I know this message is a bit cryptic, but I'm on travel trying 
>to get this
> > >>to work.
> > >>Once I get back, I'll get you a sample file that is failing. I can force
> > >>the fail if I run the dicomSeriesReadSeriesWrite example.
> > >>
> > >>Have you seen problems like this?
> > >
> > > 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 ?
> > >
> > > Mathieu

  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