Debian Bug report logs - #681234
jasper does not decompress 16bits correctly

Package: libjasper1; Maintainer for libjasper1 is Roland Stigge <stigge@antcom.de>; Source for libjasper1 is src:jasper.

Reported by: Mathieu Malaterre <malat@debian.org>

Date: Wed, 11 Jul 2012 15:51:02 UTC

Severity: important

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Roland Stigge <stigge@antcom.de>:
Bug#681234; Package libjasper1. (Wed, 11 Jul 2012 15:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mathieu Malaterre <malat@debian.org>:
New Bug report received and forwarded. Copy sent to Roland Stigge <stigge@antcom.de>. (Wed, 11 Jul 2012 15:51:07 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Mathieu Malaterre <malat@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: jasper does not decompress 16bits correctly
Date: Wed, 11 Jul 2012 17:48:49 +0200
Package: libjasper1
Severity: grave

I cannot decompress a 16bits J2k codestream. Using jasper leads to
incorrect result (noisy?).

Steps:

$ jasper --input CT_Phillips_JPEG2K_Decompr_Problem.j2k --output
CT_Phillips_JPEG2K_Decompr_Problem_jasper.pnm

Compare the output with openjpeg (which is correct):

$ j2k_to_image -i CT_Phillips_JPEG2K_Decompr_Problem.j2k -o
CT_Phillips_JPEG2K_Decompr_Problem_openjpeg.pnm

Files can be found at:

http://jpeg.sourceforge.net/jpeg2000/CT_Phillips_JPEG2K_Decompr_Problem.j2k
http://jpeg.sourceforge.net/jpeg2000/CT_Phillips_JPEG2K_Decompr_Problem_jasper.pnm
http://jpeg.sourceforge.net/jpeg2000/CT_Phillips_JPEG2K_Decompr_Problem_openjpeg.pnm

Thanks




Severity set to 'important' from 'grave' Request was from Mathieu Malaterre <malat@debian.org> to control@bugs.debian.org. (Sun, 29 Jul 2012 09:33:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Roland Stigge <stigge@antcom.de>:
Bug#681234; Package libjasper1. (Sun, 29 Jul 2012 10:00:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mathieu Malaterre <malat@debian.org>:
Extra info received and forwarded to list. Copy sent to Roland Stigge <stigge@antcom.de>. (Sun, 29 Jul 2012 10:00:06 GMT) Full text and rfc822 format available.

Message #12 received at 681234@bugs.debian.org (full text, mbox):

From: Mathieu Malaterre <malat@debian.org>
To: 681234@bugs.debian.org
Subject: jasper does not decompress 16bits correctly
Date: Sun, 29 Jul 2012 11:57:46 +0200
For more reference see the thread at:

http://groups.yahoo.com/group/jasper-discussion/message/717

This group is not public, however one can find the message forwarded here:

https://groups.google.com/group/comp.protocols.dicom/msg/c93276d13fc6d74



Information forwarded to debian-bugs-dist@lists.debian.org, Roland Stigge <stigge@antcom.de>:
Bug#681234; Package libjasper1. (Sun, 29 Jul 2012 10:00:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mathieu Malaterre <mathieu.malaterre@gmail.com>:
Extra info received and forwarded to list. Copy sent to Roland Stigge <stigge@antcom.de>. (Sun, 29 Jul 2012 10:00:08 GMT) Full text and rfc822 format available.

Message #17 received at 681234@bugs.debian.org (full text, mbox):

From: Mathieu Malaterre <mathieu.malaterre@gmail.com>
To: 681234@bugs.debian.org
Subject: Fwd: [Dcmlib] jpeg 2000
Date: Sun, 29 Jul 2012 02:59:05 -0700 (PDT)
[Message part 1 (text/plain, inline)]

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.
>
>
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Roland Stigge <stigge@antcom.de>:
Bug#681234; Package libjasper1. (Sun, 29 Jul 2012 10:09:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mathieu Malaterre <malat@debian.org>:
Extra info received and forwarded to list. Copy sent to Roland Stigge <stigge@antcom.de>. (Sun, 29 Jul 2012 10:09:06 GMT) Full text and rfc822 format available.

Message #22 received at 681234@bugs.debian.org (full text, mbox):

From: Mathieu Malaterre <malat@debian.org>
To: 681234@bugs.debian.org
Date: Sun, 29 Jul 2012 12:07:02 +0200
I followed suggestion from:

http://tech.groups.yahoo.com/group/jasper-discussion/message/1452

I downloaded geojasper:
http://www.dimin.net/software/geojasper/geojasper_src_1.4.0.zip

$ autoreconf && make

-> still the exact same issue. 16bits lossy simply does not work in
jasper and/or geojasper.

More refs:
http://tech.groups.yahoo.com/group/jasper-discussion/message/1457

2cts



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 23:39:31 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.