Fork of openjpeg library for JPEG2000 encoding and decoding https://git.carlh.net/cgit/openjpeg/atom?h=v2.2.0 2017-08-09T15:37:05Z 2017-08-09T15:37:05Z Even Rouault even.rouault@spatialys.com 2017-08-09T15:37:05Z urn:sha1:4b16e8d27ae524c5bf5f8af299703f7334752465 2017-08-09T13:04:29Z Even Rouault even.rouault@spatialys.com 2017-08-09T13:04:29Z urn:sha1:5e200452db84947f4eb893ae7f02f7dd9a358378 2017-08-09T12:50:59Z Even Rouault even.rouault@spatialys.com 2017-08-09T12:50:59Z urn:sha1:9203e8ec51a1c1c1a358a9cbafdf3391549ebc80 2017-08-09T12:13:58Z Even Rouault even.rouault@spatialys.com 2017-08-09T12:13:58Z urn:sha1:11b1ffb373d8e41705348080ba5e74a4ffe4148c 2017-08-09T09:34:08Z Even Rouault even.rouault@spatialys.com 2017-08-09T09:34:08Z urn:sha1:ac375ac9f5b4ae47501b60795e905e3d25dd00f8 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. 2017-08-08T23:51:54Z Antonin Descampe antonin@descampe.net 2017-08-08T23:51:54Z urn:sha1:0394f8d0f1c981e0bc587beddc14d1fb0b265b1b Catch images broken by AFL 2017-08-07T16:32:52Z Even Rouault even.rouault@spatialys.com 2017-07-06T17:34:21Z urn:sha1:92114694a48638e86c07e4adf11b78878045c8a9 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. On MAPA_005.jp2 n4: 1871312549 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. n1: 1610689344 0x4E781E7: opj_aligned_malloc (opj_malloc.c:61) n1: 1610689344 0x4E71D1B: opj_alloc_tile_component_data (tcd.c:676) n1: 1610689344 0x4E726CF: opj_tcd_init_decode_tile (tcd.c:816) n1: 1610689344 0x4E4BE39: opj_j2k_read_tile_header (j2k.c:8617) n1: 1610689344 0x4E4C902: opj_j2k_decode_tiles (j2k.c:10348) n1: 1610689344 0x4E4E3CE: opj_j2k_decode (j2k.c:7846) n1: 1610689344 0x4E53002: opj_jp2_decode (jp2.c:1564) n0: 1610689344 0x40374E: main (opj_decompress.c:1459) n1: 219232541 0x4E4BC50: opj_j2k_read_tile_header (j2k.c:4683) n1: 219232541 0x4E4C902: opj_j2k_decode_tiles (j2k.c:10348) n1: 219232541 0x4E4E3CE: opj_j2k_decode (j2k.c:7846) n1: 219232541 0x4E53002: opj_jp2_decode (jp2.c:1564) n0: 219232541 0x40374E: main (opj_decompress.c:1459) n1: 23893200 0x4E72735: opj_tcd_init_decode_tile (tcd.c:1225) n1: 23893200 0x4E4BE39: opj_j2k_read_tile_header (j2k.c:8617) n1: 23893200 0x4E4C902: opj_j2k_decode_tiles (j2k.c:10348) n1: 23893200 0x4E4E3CE: opj_j2k_decode (j2k.c:7846) n1: 23893200 0x4E53002: opj_jp2_decode (jp2.c:1564) n0: 23893200 0x40374E: main (opj_decompress.c:1459) n0: 17497464 in 52 places, all below massif's threshold (1.00%) 2017-08-07T16:32:52Z Even Rouault even.rouault@spatialys.com 2017-07-06T14:11:11Z urn:sha1:ca34d13e76a588a00171e57690c1deeaf068723a 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. New profile: n4: 1885648469 (heap allocation functions) malloc/new/new[], --alloc-fns, etc. n1: 1610689344 0x4E78287: opj_aligned_malloc (opj_malloc.c:61) n1: 1610689344 0x4E71D7B: opj_alloc_tile_component_data (tcd.c:676) n1: 1610689344 0x4E7272C: opj_tcd_init_decode_tile (tcd.c:816) n1: 1610689344 0x4E4BDD9: opj_j2k_read_tile_header (j2k.c:8618) n1: 1610689344 0x4E4C8A2: opj_j2k_decode_tiles (j2k.c:10349) n1: 1610689344 0x4E4E36E: opj_j2k_decode (j2k.c:7847) n1: 1610689344 0x4E52FA2: opj_jp2_decode (jp2.c:1564) n0: 1610689344 0x40374E: main (opj_decompress.c:1459) n1: 219232541 0x4E4BBF0: opj_j2k_read_tile_header (j2k.c:4685) n1: 219232541 0x4E4C8A2: opj_j2k_decode_tiles (j2k.c:10349) n1: 219232541 0x4E4E36E: opj_j2k_decode (j2k.c:7847) n1: 219232541 0x4E52FA2: opj_jp2_decode (jp2.c:1564) n0: 219232541 0x40374E: main (opj_decompress.c:1459) n1: 39822000 0x4E727A9: opj_tcd_init_decode_tile (tcd.c:1219) n1: 39822000 0x4E4BDD9: opj_j2k_read_tile_header (j2k.c:8618) n1: 39822000 0x4E4C8A2: opj_j2k_decode_tiles (j2k.c:10349) n1: 39822000 0x4E4E36E: opj_j2k_decode (j2k.c:7847) n1: 39822000 0x4E52FA2: opj_jp2_decode (jp2.c:1564) n0: 39822000 0x40374E: main (opj_decompress.c:1459) n0: 15904584 in 52 places, all below massif's threshold (1.00%) 2017-08-07T16:32:52Z Even Rouault even.rouault@spatialys.com 2017-07-06T11:23:29Z urn:sha1:373520db309430b68dd9ff09cba03a25f711a88e 2017-08-07T16:32:52Z Even Rouault even.rouault@spatialys.com 2017-07-06T00:17:26Z urn:sha1:434ace4ff74cc3eee401d4d3c02668c1d85f2a0d