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.
Even Rouault [Thu, 17 Aug 2017 09:05:53 +0000 (11:05 +0200)]
Avoid asserting on assert(i == pcol) in opj_jp2_apply_pclr() by adding new check in opj_jp2_check_color(). Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3068. Credit to OSS Fuzz
Even Rouault [Wed, 16 Aug 2017 16:29:59 +0000 (18:29 +0200)]
opj_t1_encode_cblk(): avoid uint32 overflow when numbps = 0 (which is well defined behaviour, and is properly handled here, but better avoid it to detect real issues)
The number of components is given only by TIFFTAG_SAMPLESPERPIXEL / tiSpp.
Querying TIFFTAG_EXTRASAMPLES only give information about which channel is
the alpha channel, but we mostly ignore it for now, so remove that part of the
code.
Even Rouault [Wed, 16 Aug 2017 10:52:33 +0000 (12:52 +0200)]
opj_t2_encode_packet(): only emit an error about insufficiently large output buffer in FINAL_PASS mode. Fixes (master-only) regression added in 0b4fef6d1901254e41ab74ed681daba477d724c3
Even Rouault [Wed, 9 Aug 2017 09:34:08 +0000 (11:34 +0200)]
Partial revert BPC related check of #975 (#979)
PR #975 introduced a check that rejects images that have different bit depth/sign
per compoment in SIZ marker if the JP2 IHDR box has BPC != 255
This didn't work properly if decoding a .j2k file since the new bit added in
opj_cp_t wasn't initialized to the right value.
For clarity, tThis new bit has also been renamed to allow_different_bit_depth_sign
But looking closer at the code, it seems we were already tolerant to inconsistencies.
For example we parsed a JP2 BPCC box even if BPC != 255 (just a warning is emitted)
So failing hard in opj_j2k_read_siz() wouldn't be very inconsistent, and that
alone cannot protect against other issues, so just emit a warning if BPC != 255
and the SIZ marker contains different bit depth/sign per component.
Note: we could also check that the content of JP2 BPCC box is consistant with the one
of the SIZ marker.
Even Rouault [Thu, 6 Jul 2017 17:34:21 +0000 (19:34 +0200)]
Slight improvement in management of code block chunks
Instead of having the chunk array at the segment level, we can move it down to
the codeblock itself since segments are filled in sequential order.
Limit the number of memory allocation, and decrease slightly the memory usage.
Even Rouault [Thu, 6 Jul 2017 14:11:11 +0000 (16:11 +0200)]
Decoding: do not allocate memory for the codestream of each codeblock
Currently we allocate at least 8192 bytes for each codeblock, and copy
the relevant parts of the codestream in that per-codeblock buffer as we
decode packets.
As the whole codestream for the tile is ingested in memory and alive
during the decoding, we can directly point to it instead of copying. But
to do that, we need an intermediate concept, a 'chunk' of code-stream segment,
given that segments may be made of data at different places in the code-stream
when quality layers are used.
With that change, the decoding of MAPA_005.jp2 goes down from the previous
improvement of 2.7 GB down to 1.9 GB.
b7594c0fcb9dd3aa6356d72c4a525d76168da689 may put opj_tcd_tilecomp_t->data
allocated by opj_alloc_tile_component_data() as the image->comps[].data. As
opj_alloc_tile_component_data() use opj_aligned_malloc() we must be sure to
ue opj_alined_malloc()/_free() in all places where we alloc/free
image->comps[].data.
Note: this might have some compatibility impact in case user code does itself
the allocation/free of image->comps[].data
Even Rouault [Fri, 4 Aug 2017 16:01:29 +0000 (18:01 +0200)]
opj_j2k_read_sot(): check current TPSot number regarding previous (non-zero) TNsot to avoid opj_j2k_merge_ppt() to be called several times. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2851. Credit to OSS Fuzz