[Dcmlib] Bug in ComputeRLEInfo

[Eric Boix]

	Hi Jean-Michel,

Quoting jean-michel.rouet at philips.com <jean-michel.rouet at philips.com>:
> I think there is a bug in ComputeRLEInfo.
> 
>       uint32_t rleSegmentOffsetTable[15];
>       for( int k = 1; k <= 15; k++ )
>       {
>          rleSegmentOffsetTable[k] = ReadInt32();
>       }
> 
> should be replaced by
> 
>       uint32_t rleSegmentOffsetTable[15];
>       // for( int k = 1; k <= 15; k++ )
>       for( int k = 1; k <= nbRleSegments; k++ )
>       {
>          rleSegmentOffsetTable[k] = ReadInt32();
>       }

Hummm, I'm not quite sure of that. This section of Document::ComputeRLEInfo()
parses the RLE Header. As stated in the version 2003 of the
part 5 in section annex G section 5 (see gdcm/Doc/Dicom2003_Part5.pdf on
page 86):
  "the RLE header is 16 long words in length".
The first one is the "number or RLE segments" and the succeeding words
are "the offset of each of the RLE segments". And "all unused segments
offsets shall be set to zero".

As I understand it, we allways have to read 15 offsets and NOT
"number of RLE segments" offsets. Is that correct with you ?

> TestReadWriteReadCompare was always failing on acuson RLE encoded images.
This is surely platteform dependant, because 
   gdcmbin/bin/gdcmTests TestReadWriteReadCompare
runs smoothly on my fedora core 2.
Additionaly on today's dashboard 
   http://public.kitware.com/dashboard.php?name=public
the only place were TestReadWriteReadCompare fails is on DarwinG5-g++
  http://public.kitware.com/Public/Sites/midworld.kitwarein/GDCM-DarwinG5-g++/20041115-0830-Experimental/Test.html
but the ACUSON files are not the culprit ones:
  http://public.kitware.com/Public/Sites/midworld.kitwarein/GDCM-DarwinG5-g++/20041115-0830-Experimental/Results/__Test_TestReadWriteReadCompare.html

Hummmmmmmm, what is going wrong here ?

>    Testing: ../gdcmData/PHILIPS_Integris_H-8-MONO2-Multiframe.dcm
>            step 1 ...Corrupt JPEG data: premature end of data segment
> Corrupt JPEG data: premature end of data segment
> Corrupt JPEG data: 1 extraneous bytes before marker 0xd9
> Corrupt JPEG data: premature end of data segment
> Corrupt JPEG data: 2 extraneous bytes before marker 0xd9
> 2...3...4...OK.
I believe this is related to the JPEG decompression and not an RLE header
problem.

	Yours,
   Eric.