Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OpenJpeg 2.1 and 1.4 fails to decompress this file correctly #721

Closed
notBald opened this issue Mar 8, 2016 · 6 comments
Closed

OpenJpeg 2.1 and 1.4 fails to decompress this file correctly #721

notBald opened this issue Mar 8, 2016 · 6 comments
Labels

Comments

@notBald
Copy link

notBald commented Mar 8, 2016

I'm currently testing C# reimplemetations of OpenJpeg 1.4 and 2.1. The code is fairly close to the original implementations.

Adobe Reader DC and Microsoft Edge opens this file right, while Sumatra v.3.1.1, kdu v.7.1 and the C# reimplemetations gets it wrong. (Sumatra also displays the image very dark, but that's not an OpenJpeg issue)

To my knowledge, Sumatra uses the real OpenJpeg for Jpeg 2000 files, but according to the changelog it's version 1.4. This means I've not tested it on the real OpenJpeg 2.1, just the C# version.

The files were encoded using using the C# 2.1 library, in lossless mode. The image is 1bpp black and white.

The problem is a black spot under the pencil's eraser. The "Kofax" text at the bottom of the page is also unreadable.

issue.pdf

@boxerab
Copy link
Contributor

boxerab commented May 2, 2016

Please don't report bugs in a C# re-implementation on this issue tracker. It is probably a bug in your code :) If you take a few minutes to test on actual OpenJPEG, and you still have a problem, then and only then please report it here.

@notBald
Copy link
Author

notBald commented May 2, 2016

The issue isn't important enough for me to fix, OpenJpeg isn't good at 1bpp images so who cares, but the issue was tested on the real OpenJPEG, the one bundled with SumatraPDF.

I don't know what OpenJPEG version Sumatra use, it can be 1.4 or later, but the issue is definitely there too, while not in most other implementation. Could be a buffer under run, for all I know, which isn't a problem for C# but could be a security issue for C++.

@mayeut
Copy link
Collaborator

mayeut commented May 2, 2016

issue721 jp2

Renamed the file to jpg to allow upload.
There is in fact an artefact.
I would think about a corrupted/malformed jp2 rather than a bug in OpenJpeg (KDU & Safari show the same issue). Don't know the origin of the file but Adobe is know to have produced malformed files in the past.

@notBald
Copy link
Author

notBald commented May 4, 2016

The origin of the file is a CCITT test image from the libtiff test suit, compressed with lossless settings using a C# impl. of OpenJpeg 2.1. So it's not produced with Adobe.

From what I recall, I used a script to compressed all the images in the Tiff suit using C# and normal C OpenJpeg, then did a byte for byte comparison to insure that the output was identical. This means that if the file is corrupt, the bug could be in the OpenJpeg compressor.

If there's any actual interest in this, I can investigate.

@mayeut
Copy link
Collaborator

mayeut commented May 5, 2016

@notBald,
please do share the original image & compression settings used. If OpenJpeg can't do a lossless compress/decompress on it, it's something that should be investigated.

@malaterre malaterre added the bug label Sep 20, 2016
@rouault
Copy link
Collaborator

rouault commented Jun 13, 2017

Presumably fixed per #949 (issue with number of decomposition levels in border tiles) ? Closing. Re-open if the issue is still present

@rouault rouault closed this as completed Jun 13, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants