[Dcmlib] [Fwd: GDCM problems with created dicom]

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> Salut,
>
> La solution simple pour regler le probleme du group 0x0002, c'est de 
> virer (0x0002, 0x0000) c'est ca ?

I suggested Benoit not to write anymore the elem (0x0002, 0x0000), but 
now I think it's a bad idea :
In DICOM Part 6 : Data Dictionnary, the element 0x0000 of each group in 
not longer present, BUT in the Groups 0x0002 and 0x0004, where there are 
quoted as '... needed to support the formatting ...'
- within gdcm, we decided to ignore the value of any element 0x0000, 
whatever the group it belongs to.
- e-film 1.8 raises a warning if the value is wrong, but it goes on.
- maybe Dicom3Tools does matter with the length, and breaks when wrong ...

I will put back the former 'UpdateGroupLength' method, removed a few 
months ago.

Could you ask Bill to send me a 'wrong image', because I wonder *where* 
is the trouble, since he says that group 0x0002 was reused, unimpared.

Thx

Jean-Pierre Roux



> Merci
> Mathieu
>
>
> -------- Original Message --------
> Subject: GDCM problems with created dicom
> Date: Fri, 17 Dec 2004 10:05:54 -0500
>
> 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?
>
> Bill