On Thursday, June 30, 2005 5:53:52 PM UTC+2, Mathieu Malaterre wrote: > > Ok just for future references, I send the very same question on jasper > 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. > > > Mathieu Malaterre wrote: > > > > 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. > > > > See : > > > http://www.creatis.insa-lyon.fr/~jpr/PUBLIC/gdcm/gdcmSampleData/were_in_gdcmData/CT_Phillips_JPEG2K_Decompr_Problem.dcm > > > > > > > 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. > >
