Re: [Dcmlib] [Fwd: Possible bug in sample file] : jpeg lib gdcm petée ?
Mathieu Malaterre
mathieu.malaterre at kitware.com
Fri Nov 5 17:38:30 CET 2004
Salut JP,
Bon ca y est qlqu'un a repere' que j'ai /un peu/ pete' la lecture des
lossless jpeg ;)
Plus serieusement je fais maintenant:
else if ( BitsStored == 16)
{
// Reading Fragment pixels
if ( ! gdcm_read_JPEG_file16 ( fp, localDecompressed ) )
{
return false;
}
//assert( IsJPEGLossless );
}
Donc qd une image est lossless *mais* pas BitStored == 16 et ben on
echoue sur un
dbg.Error("PixelConvert::ReadAndDecompressJPEGFile: unknown "
"jpeg lossy compression ");
Voili voilou.
A tout hasard si tu changes
else if ( BitsStored == 16)
par
else if ( IsJPEGLossless )
1. TOUS les tests continues de passer correctement
2. En plus tu peux lire les images de dclunie ?
Mathieu
La lib que clunie utilise est
http://www.devarchives.com/archive/newsgroups/comp.protocols.dicom/2023/Re-truly-lossless-jpeg-
I had no trouble reading this image using either the Stanford
PVRG codec or the Sun Java JAI JIIO codecs that both support
lossless JPEG.
Jean-Pierre Roux wrote:
> 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
>>
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>
More information about the Dcmlib
mailing list