Even Rouault [Thu, 30 Nov 2017 13:48:34 +0000 (14:48 +0100)]
opj_j2k_read_cod: remove check for 'No more than one COD marker per tile' (fixes #1043)
This check was added per https://github.com/uclouvain/openjpeg/commit/daed8cc9195555e101ab708a501af2dfe6d5e001
to fix https://github.com/uclouvain/openjpeg/issues/476 , but it does not seem
to be necessary with latest master (issue476.jp2 doesn't cause memory issues),
and breaks reading legit files.
Even Rouault [Mon, 9 Oct 2017 09:40:43 +0000 (11:40 +0200)]
Unix build: fix regression of 2.3.0 where a shared-only or static-only build lacks the installation target for the library (#1019, fixes regression introduced by 3dfc6ca2bcf06fd1adb6b6b4cecc6c092f08ba0b)
Even Rouault [Fri, 8 Sep 2017 08:56:49 +0000 (10:56 +0200)]
opj_tcd_mct_decode(): avoid heap buffer overflow when components have not the same number of resolutions. Also fixes an issue with subtile decoding. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3331. Credit to OSS Fuzz
Even Rouault [Fri, 8 Sep 2017 07:16:51 +0000 (09:16 +0200)]
Use opj_image_data_free() where appropriate (adapted from https://github.com/uclouvain/openjpeg/pull/1015/commits/dab9db0723a5bb9f3d745f9dd7a0b8b3b18b8054, #1014)
Even Rouault [Wed, 6 Sep 2017 13:59:19 +0000 (15:59 +0200)]
Fix null pointer dereference on partial tile decoding when they are empty. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3297 (master only)
For some reason, the OPJ_CI_ARCH=x86_64 OPJ_CI_BUILD_CONFIGURATION=Release OPJ_NUM_THREADS=2
configuration fails once PR1010 has been merged in master
( https://travis-ci.org/uclouvain/openjpeg/jobs/272219011 ) whereas (almost) the same
code in my branch didn't fail per https://travis-ci.org/rouault/openjpeg/jobs/271738113
The errors we get are the same as with the other x86_64 compilers, so nothing alarming here.
Even Rouault [Fri, 1 Sep 2017 18:43:39 +0000 (20:43 +0200)]
Replace error message 'Not enough memory for tile data' by 'Size of tile data exceeds system limits' (refs https://github.com/uclouvain/openjpeg/pull/730#issuecomment-326654188)
Even Rouault [Fri, 1 Sep 2017 17:16:35 +0000 (19:16 +0200)]
opj_compress help: revert 32572617765cb9d77302384653a48d793b8f657f and indicate 1 again as being the value to get lossless for -r. In opj_j2k_setup_encoder(), make sure that ll rates[] <= 1.0 are set to 0. Document 0 as being lossless for -q / tcp_distoratio (#1009)
Even Rouault [Fri, 1 Sep 2017 14:30:48 +0000 (16:30 +0200)]
Allow several repeated calls to opj_set_decode_area() and opj_decode() for single-tiled images
* Only works for single-tiled images --> will error out cleanly, as currently
in other cases
* Save re-reading the codestream for the tile, and re-use code-blocks of the
previous decoding pass.
* Future improvements might involve improving opj_decompress, and the image writing logic,
to use this strategy.
Even Rouault [Fri, 1 Sep 2017 14:30:37 +0000 (16:30 +0200)]
Remove limitation that prevents from opening images bigger than 4 billion pixels
However the intermediate buffer for decoding must still be smaller than 4
billion pixels, so this is useful for decoding at a lower resolution level,
or subtile decoding.
Even Rouault [Fri, 1 Sep 2017 14:30:29 +0000 (16:30 +0200)]
Sub-tile decoding: only allocate tile component buffer of the needed dimension
Instead of being the full tile size.
* Use a sparse array mechanism to store code-blocks and intermediate stages of
IDWT.
* IDWT, DC level shift and MCT stages are done just on that smaller array.
* Improve copy of tile component array to final image, by saving an intermediate
buffer.
* For full-tile decoding at reduced resolution, only allocate the tile buffer to
the reduced size, instead of the full-resolution size.
Even Rouault [Mon, 28 Aug 2017 15:18:33 +0000 (17:18 +0200)]
Subtile decoding: fix overflows in subband coordinate computation that cause later buffer overflow. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3115. Credit to OSS Fuzz. master only
Even Rouault [Mon, 28 Aug 2017 12:57:49 +0000 (14:57 +0200)]
Make opj_set_decode_area() and opj_decode() take into account opj_set_decoded_resolution_factor() (#1006, affect API use)
* Better document usage of opj_set_decode_area(), ie expecting coordinates
in full resolution/reference grid even if requesting at a lower resolution
factor
* Make sure that image->comps[].factor is set by opj_set_decode_area() and
opj_decode() from the value specified in opj_set_decoded_resolution_factor()
* opj_decompress: add 2 environmenet variables to test alternate ways of
using the API, namely USE_OPJ_SET_DECODED_RESOLUTION_FACTOR=YES to use
opj_set_decoded_resolution_factor() instead of parameters.cp_reduce, and
SKIP_OPJ_SET_DECODE_AREA=YES to not call opj_set_decode_area() if -d is
not specified.