-
Notifications
You must be signed in to change notification settings - Fork 455
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
opj_compress v2.1.2 can create images opj_decompress cannot read #891
Comments
It would be most helpful if you could please a) upload the original TIFF file for a TIFF file that produces a broken JP2 file. |
one of the most interesting bug report in while. Scary that lossless encoding is not lossless... |
Hello Mathieu, actually this isn't bad - lossless encoding with compression ratio greater than 1 results in lossy compression, it just uses the lossless 5/3 wavelet transform, with no quantization. So, this is expected. |
I can't attach the TIFFs as they're too big, but follow this link to one I just double-checked. Github also won't let me attach JP2 files, so I've included what I just now generated from the commands below: My settings:
I tried with and without the -I flag in the past, and results were still unpredictable, but I can't say for sure which rates and which TIFF files will give any particular error. We built a script to iterate over a few hundred rates on the problem files and found that most worked if we tweaked the rate, but they all had problems at some rate values, and some didn't work for any of the rates we tried. |
Thanks. So, even in pure lossless mode, I am seeing this error. i.e. this really is quite bad: lossless encoding is actually lossy. |
By the way, not to be pedantic, but both files that you created would be considered lossy. The first uses lossless wavelet transform and no quantization, while second uses lossy wavelet transform and quantization. |
Good to know. I haven't delved very deep into creating JP2 files, so I've mostly just played with settings until things seem to work reasonably well. We were originally just using GraphicsMagick, telling it to tile with a given quality value, and calling it good. When it died on us (different problem), we had to kind of rush jp2_compress into our process. |
As a work around, you could try setting tile size to 512x512 ? This seems to work for me. |
I think changing settings in general seems to give working results. The problem is that the results are inconsistent. For instance, 512x512 works well on the TIFF I've provided, but doesn't work for another TIFF in our repository Our workaround has been to just twiddle settings (mostly the rate) until something works, but we haven't found a single setting that we can apply to all TIFFs we have in a uniform way. |
Yeah. I think it is related to the dimensions of the image and the dimensions of the tiles. So, this isn't a very good workaround, I guess :( This kind of bug will take a long time to fix, as it is happening in the guts of the codec. |
@jechols If you like, you can use Grok codec to encode these images I tested with your image and encoding parameters, and everything works without error. Also, if no compression ratio is set, then compression is truly lossless : mathematically equal to original. This indicates that all is well with both encoder and decoder. |
…ain#892) There are situations where, given a tile size, at a resolution level, there are sub-bands with x0==x1 or y0==y1, that consequently don't have any valid codeblocks, but the other sub-bands may be non-empty. Given that we recycle the memory from one tile to another one, those ghost codeblocks might be non-0 and thus candidate for packet inclusion.
Fixed per #949 |
I hadn't been keeping up on this for a while - thanks for the fix! |
We're having a problem where opj_compress can occasionally produce a JP2 which opj_decompress cannot read. Sometimes changing the encoding rate fixes the problem, but sometimes we iterate hundreds of times with different rates and still have no luck. The original TIFF files don't seem to have any problems, and opj_encode doesn't seem to have any unusual complaints creating a JP2.
We've created a github repository with some examples, mostly for our own documentation, but the information provided may be of some assistance.
We get broken JP2 files when converting from raw TIFFs, when converting from TIFF to PNG and then to JP2, and sometimes even when going from TIFF to BMP to JP2. The latter gives us the most success, but the resulting JP2 usually has 3 channels despite the TIFF having only 1, so we can't really use that process.
Here's an example of output when decoding a JP2 we encode with opj_compress (for convenience, we've put the JP2 in question into the github repository as well):
The text was updated successfully, but these errors were encountered: