Re: [Dcmlib] [Fwd: Possible bug in sample file] : jpeg lib gdcm petée ?

[Jean-Pierre Roux]

Mathieu Malaterre wrote:

> -------- Original Message --------
> Subject: Possible bug in sample file
> Date: Wed, 03 Nov 2004 13:10:37 +0200
> From: Anthony Patrinos <patrinos at escape.gr>
>
[...]

>
> The decompression was performed with the 12 bit version the JPEG_2B
> library.   [...]   While going through the test data sets kindly 
> provided by Dr Clunie I
> encountered a minor problem with the RG3_JPLY file from the
> ftp://medical.nema.org/MEDICAL/Dicom/DataSets/WG04/compsamples_jpeg.tar
> file set.

Il en a, de la chance, lui, de pouvoir s'interroger sur la vraisemblnace 
du contenu de certains champs....

--> La version actuelle de vtkgdcmViewer pete sur :

Debug: In /home/jpr/junk/gdcm/vtk/vtkGdcmReader.cxx, line 614
vtkGdcmReader (0x8addb08): Copying to memory image [RG3_JPLY.dcm]
gdcm::PixelConvert::ReadAndDecompressJPEGFile: unknown jpeg lossy 
compression

--> la version 'avant tremblement de terre' affichait l'image ...


Bon ...
A part ça, il y a un truc qui me laisse vraiment reveur, c'est la 
difficulté qu'il y a pour trouver une jpeg lib qui ... lise le jpeg !
(Mathieu en sait plus la dessus que nous tous réunis)

avec Cornwell lib, vtkgdcmViewer partait en Seg Fault sur : 
gdcm-JPEG-LossLessThoravision.dcm
alors qu'avec l'actuelle jkpeg lib, il se contente d'afficher :
gdcm::PixelConvert::ReadAndDecompressJPEGFile: unknown jpeg lossy 
compression

David Clunie disait que sa library n'avait aucun soucis avec cette image.
Nous, nous avons des soucis avec *chaque* image du data set compression 
de D. Clunie

C'est quoi, la lib JPEG_2B qu'il utilise, Anthony Patrinos?
Google n'a pas l'air de connaitre, et "JPEG 2B" conduit tout droit a un 
'pornomotore' de la Madona Porca !




D'autre part, la version actuelle de PrintFile se termine par :

 > PrintFile RG3_JPLY.dcm
[...]
===========================================
--- Pixel information -------------------------
Pixel Data: offset 1614 x64e   length 92470 x16936
 
===========================================
ce qui ne donne pas  plus d'information que la derniere ligne du Header :
7fe0|0010 lg :   x(16936) 92470    Off.:     x(64e) 1614    [OB] 


La version avant tremblement de terre, se terminait par :

 > PrintFile RG3_JPLY.dcm
[...]
===========================================
Checking the Dicom-encapsulated Jpeg/RLE Pixels
at 64e : ItemTag (should be fffe,e000): fffe,e000
at 652 : Basic Offset Table Item Length (??) 0 x(00000000)
at 656 : ItemTag (should be fffe,e000 or e0dd): fffe,e000
      at 65a : fragment length 65536 x(00010000)
at 1065e : ItemTag (should be fffe,e000 or e0dd): fffe,e000
      at 10662 : fragment length 26902 x(00006916)
at 16f7c : ItemTag (should be fffe,e000 or e0dd): fffe,e0dd 
=========================================== 
RG3_JPLY.dcm is Readable

qui permettait de s'assurer que les fragments, items, offset table, etc 
étaient bons.


>
> This file specifies 10 bits stored (data element 0x0028, 0x0101), so
> the pixel values should have an allowed range of 0 to 1023 (1024
> values). However, this file's pixel data range from 0 to 1024. The
> discrepancy was caught by a sanity check in our code for the range
> actual pixel values (as in the data) vs the nominally allowed ones (as
> calculated from the bits used data element).
>
> The decompression was performed with the 12 bit version the JPEG_2B
> library. With the 16 bit version of the library the resulting pixel
> value range was 30711 to 31744, i.e. 1034 values. In both cases the
> resulting image is visually identical to the reference image RG3_UNC
> available at
> ftp://medical.nema.org/MEDICAL/Dicom/DataSets/WG04/compsamples_refanddir.
> tar.bz2 .
>
> This is most likely a decompression artifact caused by the fact that
> the available output range from the jpeg library is 12/16 bits
> respectively.
>
> This particular case is not much of a problem, but does raise the
> question of how one (an application or toolkit) is supposed to handle
> such situations.
>
> Is a re-scaling of the data values to the correct range appropriate or
> could one just ignore the overshoot (since the data values would be
> embedded in a 16 bit buffer anyway) or maybe clamp the overshooting
> pixel values to the maximum allowed? I'm inclined to prefer the second
> or third approach because (not quite sure which one yet) because
>   a. Re-scaling by 1023/newMaxPixelValue would probably cause more
> artifacts due to aliasing of the data values.
>   b. More significantly, re-scaling would move the mean of the pixel
> values, thus introducing a systematic bias to the resulting image.
>
> Best regards to all,
>
> Tony Patrinos, PhD
> Escape Information Services
> http://www.escape.gr/dicom/
>
>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>