Signed pixels and lossless JPEG
Marco
I'm writing a piece of code to decode lossless-JPEG DICOM Images
(Transfer Syntax UID = 1.2.840.10008.1.2.4.70) and I am facing the
following problem:
I'm trying to decode a MR Image generated by a GE modality. This DICOM
file has the following attributes:
Pixel Representation = 1
Bits Allocated = 16
Bits Stored = 16
High Bit = 15
Window Center = 252
Window Width = 504
In other words, it is a 16-bit "signed" image.
If I decode the Pixel Data with my lossless jpeg decoder, then I check
the values of the pixel samples relative to each pixel of the image
(interpreted in an UNSIGNED way), I obtain:
Min pixel value: 32578
Max pixel value: 33335
If I interpret these pixel samples in 2s-complement (as the Pixel
Representation = 1 would imply), I obtain an image with some pixels
having a large positive value (+32578 -> +32767) and some pixel having
a large (in module) negative value (-32768 -> -32xxx). Hence the
suggested VOI LUT transformation (WC = 252, WW = 504) would not catch
any pixel value of the image...
The only transformation that would allow pixel values to fall inside
the VOI range is to subtract 32768 from all pixel stored values before
applying the VOI LUT transformation: but is this kind of
transformation indicated by the DICOM standard?
How can I know in which cases I have to subtract 32768 to the pixel
values? Obviously, no Rescale Intercept data element is present in my
file, since it is a MR image...
Any help would be greatly appreciated.
Regards,
Marco.
Yves Martel
Regardless of the sign, do the image look O.K. ?
I ask this because it is very possible that you have a compression
problem and that the values are incorrect. This would explain the
wide dynamic range. Some GE implementations seem to use the
PVRG library and it has a problem with the 16 bit images.
You can try to drop your image in TomoVision and see what it tells...
Yves
"Marco" <marco....@poste.it> wrote in message
news:f79ca8c8.04022...@posting.google.com...
Jean-Luc Cyr
Do you have a rescale intercept/slope within your
image data?
It is a way to indicate if you must substract any value from your
data before applying windows center/width.
Rescale slope(0028,1053)/intercept(0028,1052)
Jean-Luc
-- Jean-Luc Cyr Les systemes médicaux IMAGEM / Groupe Conseil GRAF 930 Jacques-Cartier Est, Chicoutimi, Québec, G7H-7K9. Tél: (418) 543-0427 poste 112 Téléc: (418) 543-4812
Marco
thank you for your answer.
I don't have any rescale slope / intercept data elements in the DICOM
file containing the lossless JPEG image, and I believe this is normal
since it is a MR image.
This is the reason why I can't understand how I could "imagine" that I
have to subtract 32768 to the pixel data (interpreted in an UNSIGNED
fashion) in order to obtain the correct image, on which to apply the
Window Center / Window Width transformation.
By the way, the image displays correctly with eFilm or ezDICOM...
Thank you for your help.
Regards,
Marco.
Jean-Luc Cyr <jl...@grafsoft.com> wrote in message news:<403E6EAA...@grafsoft.com>...
> --
Marco
thanks a lot for your message.
Well, If I interpret the pixel samples as 2s-complement values, the
image does NOT look correct, since all of the pixel values of my image
fall outside the VOI window range. I've tryied to open the DICOM file
with Tomovision, but it has exactly the same display problem as my
viewer (when I interpret the pixel samples as 2s-complement values).
Nevertheless, the image is displayed correctly by both eFilm and
ezDICOM.
I've also tried to subtract 32768 from all pixel samples interpreted
as UNSIGNED, then to apply the VOI windowing: what my viewer displays
is a "better" image, but still it isn't the same as displyed by eFilm
or ezDICOM.
By the way, my code is a Java code, and I am using Java Advanced
Imaging (JAI) + Image I/O tools for JAI for decoding the lossless JPEG
image...
Any help would be greatly appreciated.
Thank you and best regards,
Marco.
"Yves Martel" <mar...@acm.org> wrote in message news:<141ee3a751f85edb...@news.teranews.com>...
Yves Martel
I received your image and, just as I thought, it is a compression
problem. Apparently the image was compressed with the PVRG
library (is this true? Actually this question is for the other Marco,
the one from OFFIS, since the Implementation Version Name state:
"OFFIS_DCMTK_351"). My programs have a couple of test to
detect this conditions, but apparently they didn't catch your image.
I'll fix this and let you know when it's done...
With the proper decompression, the dynamic range of the image is
between 0 and 500.
Since your image is displayed correctly with eFilm and ezDICOM,
then I suppose they also use PVRG. It is a very good library, but
it does have a bug when handling 16 bit images. If everybody was
using this library, then it wouldn't be to bad, but since some
manufacturer are not (Siemens for example), we do have a problem.
And indeed, eFilm has problems with the latest Siemens images.
(Has this been fixed recently?)
Yves
"Marco" <marco....@poste.it> wrote in message
news:f79ca8c8.04022...@posting.google.com...
Marco
thanks a lot for your answer.
I am very interested in the possible ways to detect and fix the
compression problem you are talking about. Since my purpose is to be
able to correctly display that image with my own viewer code, I would
be grateful if you could give me some suggestions about this.
Thanks again,
Marco.
"Yves Martel" <mar...@acm.org> wrote in message news:<c98335c35387fd03...@news.teranews.com>...
Marco Eichelberg
> I received your image and, just as I thought, it is a compression
> problem. Apparently the image was compressed with the PVRG
> library (is this true? Actually this question is for the other Marco,
> the one from OFFIS, since the Implementation Version Name state:
> "OFFIS_DCMTK_351").
The implementation version name in the meta-header could simply mean
that the image has been received by DCMTK's storescp application,
it does not necessarily mean that the compression has been performed
by DCMTK. The JPEG codec used within DCMTK is the Independent JPEG
Group toolkit with a lossless extension. We don't use the Stanford PVRG
code.
You could "detect" an image compressed with DCMTK by checking if
there is an attribute (0008,2111) DerivationDescription that contains a
string like "Lossless JPEG compression, selection value 1, point
transform 0, compression ratio 1.2345".
Regards,
Marco Eichelberg
OFFIS
Marco
encoding bug with 16-bit grayscale images?
It would be useful to understand possible ways to detect the presence
of this encoding bug in a DICOM stream/file and to correctly decode
it.
Any help would be greatly appreciated.
Regards,
Marco.
Marco Eichelberg <eichelbe...@offis.de> wrote in message news:<c21gnq$2...@news.Informatik.Uni-Oldenburg.DE>...