- 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.
-
- 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%)
-
-commit ca34d13e76a588a00171e57690c1deeaf068723a
-Author: Even Rouault <even.rouault@spatialys.com>
-Date: 2017-07-06 16:11: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.
-
- New profile:
+ 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)
+
+commit 559d16e8f43a0cd090d217d7d111820989299b85
+Author: Even Rouault <even.rouault@spatialys.com>
+Date: 2017-09-01 16:31:13 +0200
+
+ opj_t1_decode_cblk(): move some code to codeblock processor for (theoretical) better multi-threading in subtile decoding
+
+commit 7017e67a01c378a7a1ee5e34dd544c793b5c23e4
+Author: Even Rouault <even.rouault@spatialys.com>
+Date: 2017-09-01 16:31:10 +0200
+
+ sparse_array: optimizations for lossy case
+
+commit b428b8c7e7227cf96c83229df4d7bf009b6d2172
+Author: Even Rouault <even.rouault@spatialys.com>
+Date: 2017-09-01 20:01:39 +0200
+
+ opj_tcd_rateallocate(): make sure to use all passes for a lossless layer (#1009)