| Age | Commit message (Collapse) | Author |
|
|
|
|
|
And save a useless loop, which should be a tiny faster.
|
|
later buffer overflow. Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3115. Credit to OSS Fuzz. master only
|
|
|
|
tile-component buffer.
|
|
tile-component buffer.
This lowers 'bin/opj_decompress -i ../MAPA.jp2 -o out.tif -d 0,0,256,256'
down to 0.860s
|
|
window specified in opj_set_decode_area()
|
|
write heap buffer overflow in opj_mqc_flush (#982)
|
|
error message when the output buffer is too small
|
|
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%)
|
|
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%)
|
|
|
|
As bin/common/color.c used to directly call malloc()/free(), we need
to export functions dedicated to allocating/freeing image component data.
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2799. Credit to OSS Fuzz
|
|
Tencent's Xuanwu LAB (#835)
|
|
CVE-2016-5152)
Fix derived from https://pdfium.googlesource.com/pdfium.git/+/d8cc503575463ff3d81b22dad292665f2c88911e/third_party/libopenjpeg20/0018-tcd_get_decoded_tile_size.patch
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2516. Credit to OSS Fuzz
|
|
load/store (#895)
When components don't have the same width, unaligned load/store are possible.
Fixes openjeg-crashes-2017-07-27/id:000000,sig:11,src:001342,op:flip4,pos:162.jp2 of #895
|
|
and emit a warning when errors are found
|
|
|
|
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.
|
|
There were a number of defects regarding when and how the termination of
passes had to done and the computation of their rate.
|
|
This saves comparing the current pointer with the end of buffer pointer.
This results at least in tiny speed improvement for raw decoding, and
smaller code size for MQC as well.
This kills the remains of the raw.h/.c files that were only used for
decoding. Encoding using the mqc structure already.
|
|
|
|
Decoding some valid .jp2 files like Sentinel2 datasets leads to warnings like:
No incltree created.
tgt_create tree->numnodes == 0, no tree created.
No imsbtree created.
tgt_create tree->numnodes == 0, no tree created.
Besides that, the image is correctly decoded. So there is no reason to emit
those warnings.
|
|
tier1_optimizations_multithreading_2
Conflicts:
src/lib/openjp2/t1.c
|
|
Coordinates are casted from OPJ_UINT32 to OPJ_INT32
Add sanity check for negative values and upper bound becoming lower
than lower bound.
See also
https://pdfium.googlesource.com/pdfium/+/b6befb2ed2485a3805cddea86dc7574510178ea9
|
|
|
|
|
|
|
|
pool to tcd level
By default, only the main thread is used. If opj_codec_set_threads() is not used,
but the OPJ_NUM_THREADS environment variable is set, its value will be
used to initialize the number of threads. The value can be either an integer
number, or "ALL_CPUS". If OPJ_NUM_THREADS is set and this function is called,
this function will override the behaviour of the environment variable.
|
|
Fix uclouvain/openjpeg#733
|
|
|
|
|
|
|
|
Follow-up of #757
This shall have no performance impact on 2’s complement machine where
the compiler replaces the multiplication by power of two (constant) by
a left shift.
Verified at least on MacOS Xcode 7.3, same assembly generated after fix.
|
|
Update #635
Update #625
|
|
Update #624
Update #625
|
|
|
|
This reverts commit 553714a87a92930dd69f5762e0615c12dfcbd873.
|
|
|
|
Remove float equality test. Such a test has no meaning.
|
|
|
|
It doesn't change the outcome of the test suite, that's weird...
|
|
Update uclouvain/openjpeg#571
|
|
Fixes #486
Fixes #394
Update #480
Update #388
|
|
Update uclouvain/openjpeg#246
|
|
Update #442
|
|
Update uclouvain/openjpeg#539
|