[Dcmlib] [Fwd: Possible bug in sample file]

[Mathieu Malaterre]

-------- Original Message --------
Subject: Possible bug in sample file
Date: Wed, 03 Nov 2004 13:10:37 +0200
From: Anthony Patrinos <patrinos at escape.gr>
Organization: FORTHnet S.A., Atthidon 4, GR-17671 Kalithea, Greece, Tel: 
+30 2109559000, Fax: +30 2109559333, url: http://www.forthnet.gr
To: tech at escape.gr
Newsgroups: comp.protocols.dicom

[[ This message was both posted and mailed: see
    the "To," "Cc," and "Newsgroups" headers for details. ]]


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.

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/