Mathieu Malaterre wrote:
> 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 );
> }
>
La manip, c'est de remplacer :
else if ( BitsStored == 12 )
par
else if ( BitsStored <= 12 ) --> Ca traitera BitsStored = 9, 10, 11,
12 comme du 12.
=======
else if ( BitsStored <= 12 )
{
// Reading Fragment pixels
if ( ! gdcm_read_JPEG_file12 ( fp, localDecompressed ) )
{
return false;
}
=======
Ca lit, ca affiche, mais on voit que la jpeg lib a un pb (et non plus
qu'elle n'est pas appellee ...)
L'image a l'air cassée en deux, comme si un fragment de ligne manquait ...
Quant a gdcm-JPEG-LossLessThoravision.dcm, on a un message :
Corrupt JPEG data: bad Huffman code
>
> 1. TOUS les tests continues de passer correctement
> 2. En plus tu peux lire les images de dclunie ?
MG1_JPLY.dcm --> Invalid SOS parameters for sequential JPEG
MR1_JPLY.dcm --> OK
MR2_JPLY.dcm --> image cassee en 2
MR3_JPLY.dcm --> OK
MR3_JPLY.dcm --> image presque blanche (tres faible dynamique)
NM1_JPLY.dcm --> OK
RG2_JPLY.dcm --> Invalid SOS parameters for sequential JPEG
RG2_JPLY.dcm --> image cassee en 2
SC1_JPLY.dcm --> Invalid SOS parameters for sequential JPEG
XA1_JPLY.dcm --> OK
> Mathieu
> La lib que clunie utilise est
>
> http://www.devarchives.com/archive/newsgroups/comp.protocols.dicom/2023/Re-truly-lossless-jpeg-
>
Si elle a une bonne licence, il faut sauter lui dessus ;-)
>
>
> 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
>>
>
>
>