[Dcmlib] jpeg 2000
Mathieu Malaterre
Hi, everybody !
Finally, we get a JPEG2K image (kindly supplied by Dr. Loic Boussel)
comming from a clinical console (Philips), not from a compression data set.
And here is a png conversion:
http://www.creatis.insa-lyon.fr/~malaterre/gdcm/CT_Phillips_JPEG2K_Decompr_Problem.png
Something I don't like too much, is that we can see two hypointense
shapes, (between the lungs and on the pelvis), that shouldn't exist.
Just use :
vtkgdcmViewer CT_Phillips_JPEG2K_Decompr_Problem.dcm
If anybody could check this image against any other dicom encapsulated
jpeg2k viewer, we should know if the trouble comes from *their*
compressor, or from *our* decompressor.
Thx
Jean-Pierre & Mathieu
Ps:
I tried dicomworks and tomovision but they both failed to open the image.
I tried with Osirix and it gives the exact same image since we both use
jasper.
Mathieu Malaterre
mailing list, and Marco (you are everywhere !) answer me, he already saw
the problem and had a very detailed description of the problem:
http://groups.yahoo.com/group/jasper-discussion/message/717
Message included here since the mailing list require subscription (doh!)
-----------------------------------------------------------------------
BUG REPORT: OVERFLOW IN JPC QUANTIZER
Affected: JasPer 1.701.0. both JPC encoder and decoder
The problem can be reproduced both on Linux (gcc 3.2) and Windows (MSVC6).
Problem description: When images with high bit depth (> 8 bits/sample)
are compressed with JasPer using real mode, strange artifacts appear
in the images. These artifacts are causes by overflows in the
quantizer (jpc/jpc_qmfb.c).
I have prepared a 16 bit test pattern (a monochrome image that
contains the well-known SMPTE pattern) that can be used to demonstrate
the bug. The test pattern is available for download from
http://dicom.offis.de/pattern16_int.jpc
The file contains a JPEG 2000 bitstream (JPC) compressed in integer mode.
When re-compressing this test pattern with an umodified JasPer codec
compiled with -DDEBUG_OVERFLOW, overflows are reported in file
jpc_qmfb.c, line 907.
in: NNS_LIFT1
in: jpc_fix_pluseq line 839
in: jpc_fix_add(*hptr, hptr[(step)]), (alpha)));
Indeed the addition creates both underflows from negative to positive
and overflows from positive to negative because the integers handled
here are too large.
The problem can easily be reproduced by compiling JasPer with
-DDEBUG_OVERFLOW
and running the following command:
jasper --input pattern16_int.jpc --output-format jpc --output output.jpc \
--output-option "mode=real rate=0.5"
The lossy compressed image shows severe deformations when
de-compressed. Reducing the constant JPC_FIX_FRACBITS in jpc/jpc_fix.h
from 13 to 12 causes the error message to disappear, but the
compressed image still shows deformations. This means that overflows
still happen at some place not covered by the DEBUG_OVERFLOW macros
(possibly a shift operation?).
One needs to decrease JPC_FIX_FRACBITS to 11 in order to achieve a
correct compressed image. Other reports to the JasPer Yahoo discussion
forum indicate that for certain images a reduction even to 10 is
necessary.
The following files contain the same test pattern, always produced
with the same jasper command shown above, for different values of
JPC_FIX_FRACBITS.
- http://dicom.offis.de/pattern16_real_fix13bit.jpc
- http://dicom.offis.de/pattern16_real_fix12bit.jpc
- http://dicom.offis.de/pattern16_real_fix11bit.jpc
- http://dicom.offis.de/pattern16_real_fix10bit.jpc
Since visualizing 16 bit images is a bit difficult, I have also
produced PNG versions of these images. This can be done by converting
to PNM with JasPer and the pnmtopng tool from the NetPBM package which
supports the 16 bit PNG format written by JasPer:
jasper --input file.jpc --output-format pnm --output output.pnm
pnmtopng output.pnm output.png
Here are the PNG images. They were all created using a JasPer codec
with JPC_FIX_FRACBITS decreased to 10.
- http://dicom.offis.de/pattern16_real_fix13bit.png
- http://dicom.offis.de/pattern16_real_fix12bit.png
- http://dicom.offis.de/pattern16_real_fix11bit.png
- http://dicom.offis.de/pattern16_real_fix10bit.png
The same quantizer overflow problem also affects the JPC decompressor.
When decompressing pattern16_real_fix13bit.jpc with an unmodified
jasper application (JPC_FIX_FRACBITS == 13), compiled with with
-DDEBUG_OVERFLOW, the following overflow errors are reported:
overflow error: file jpc_qmfb.c, line 976
overflow error: file jpc_qmfb.c, line 981
overflow error: file jpc_qmfb.c, line 984
overflow error: file jpc_qmfb.c, line 987
overflow error: file jpc_qmfb.c, line 990
Again, decreasing JPC_FIX_FRACBITS sufficiently seems to solve the
problem.
Conclusion: In the current unmodified form, the JasPer codec cannot be
used for real mode encoding or decoding of 16 bit images. While this
is not a problem for many mainstream application, it makes use in
certain fields such as medical imaging very problematic.
I see three possible solutions to address this issue
1. make JasPer refuse real-mode encoding or decoding of images with
a precision of more than 8 bits/sample. From my perspective, this
is the least desirable solution because I *need* to work with 16 bit
images.
2. Permanently reduce JPC_FIX_FRACBITS to 10. This will cause the
fixed-point arithmetic operations to lose 3 bits of precision, roughly
one decimal digit. It is difficult to me to quantify the effect on
image quality this would have, but in the examples I have seen the
effect seems to be quite acceptable.
3. Change all fixed-point operations in the quantizer to 64 bit integers.
I have not really tried this yet, but it seems to me that a
typedef int_fast64_t jpc_fix_t;
should be a good starting point. One receives about 50 warnings
about assignments from incompatible pointer types in files
jpc_mct.c, jpc_qmfb.c, jpc_t1dec.c, jpc_t1enc.c then, which would
need to be fixed.
I would consider option 3 the most desirable one, because it retains
precision while offering enough headroom even for images > 16
bits/sample, at a certain speed expense, which would have to be
evaluated. I could imagine this to be a compile time feature
(configure option) - either you configure 64 bit fixed-point
arithmetic and can process images > 8 bits/pixel, or you use 32 bit
and are limited to 8 bits. This would offer the best of both worlds to
the end user of the library.
Comments are welcome.