summaryrefslogtreecommitdiff
path: root/src/lib
AgeCommit message (Collapse)Author
2020-05-24T1 encoder: speed-up by aggressive inlining and more cache friendly data ↵Even Rouault
organization ~ 9% speed improvement seen on 10980x10980 uint16 image, T36JTT_20160914T074612_B02.tif opj_compress time from 17.2s to 15.8s
2020-05-23Forward DWT 9-7: major speed up by vectorizing vertical passEven Rouault
`bench_dwt -I -encode` times goes from 8.6s to 2.1s
2020-05-23Forward DWT 5-3: major speed up by vectorizing vertical passEven Rouault
`bench_dwt -encode` times goes from 7.9s to 1.7s
2020-05-22Forward DWT: small code refactoring to allow future improvements for the ↵Even Rouault
vertical pass
2020-05-22dwt.c: remove unused typedefEven Rouault
2020-05-22Forward DWT 5x3: performance improvements in horizontal pass, and modest in ↵Even Rouault
vertical pass
2020-05-22Forward DWT: small code refactoring to allow future improvements for the ↵Even Rouault
horizontal pass
2020-05-21Speed-up 9x7 IDWD by ~30% with OPJ_NUM_THREADS=2Even Rouault
"bench_dwt -I" time goes from 2.2s to 1.5s
2020-05-21Remove useless + 5U margin in opj_dwt_decode_tile_97()Even Rouault
Nothing in code analysis nor test suite shows that this margin is needed. It dates back to commit dbeebe72b9d35f6ff807c21c7f217b569fa894f6 where vector 9x7 decoding was introduced.
2020-05-21Speed-up 9x7 IDWD by ~20%Even Rouault
"bench_dwt -I" time goes from 2.8s to 2.2s
2020-05-20bench_dwt.c: add a -I switch to test irreversible FWDT/IDWTEven Rouault
2020-05-20Irreversible decoding: partially revert previous commit, to fix failures in ↵Even Rouault
test suite
2020-05-20Irreversible compression/decompression DWT: use 1/K constant as per standardEven Rouault
The previous constant opj_c13318 was mysteriously equal to 2/K , and in the DWT, we had to divide K and opj_c13318 by 2... The issue was that the band->stepsize computation in tcd.c didn't take into account the log2gain of the band. The effect of this change is expected to be mostly equivalent to the previous situation, except some difference in rounding. But it leads to a dramatic reduction of the mean square error and peak error in the irreversible encoding of issue141.tif !
2020-05-20Irreversible decoding: align code more closely to the standard by avoid ↵Even Rouault
messing up with stepsize (no functional change)
2020-05-20opj_dwt_encode_1_real(): avoid many bound comparisons, similarly to decoding ↵Even Rouault
side
2020-05-20opj_j2k_setup_encoder(): add validation of tile width and height to avoid ↵Even Rouault
potential division by zero
2020-05-20opj_mct_encode_real(): add SSE optimizationEven Rouault
2020-05-20tcd.c: add commentEven Rouault
2020-05-20Encoder: use floating-point operations for irreversible transformationEven Rouault
2020-05-20dwt.c: change sign of constants to match standard and compensate (no ↵Even Rouault
functional change)
2020-05-20Add multithreaded support in the DWT encoder.Even Rouault
Update the bench_dwt utility to have a -decode/-encode switch Measured performance gains for DWT encoder on a Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (4 cores, hyper threaded) Encoding time: $ ./bin/bench_dwt -encode -num_threads 1 time for dwt_encode: total = 8.348 s, wallclock = 8.352 s $ ./bin/bench_dwt -encode -num_threads 2 time for dwt_encode: total = 9.776 s, wallclock = 4.904 s $ ./bin/bench_dwt -encode -num_threads 4 time for dwt_encode: total = 13.188 s, wallclock = 3.310 s $ ./bin/bench_dwt -encode -num_threads 8 time for dwt_encode: total = 30.024 s, wallclock = 4.064 s Scaling is probably limited by memory access patterns causing memory access to be the bottleneck. The slightly worse results with threads==8 than with thread==4 is due to hyperthreading being not appropriate here.
2020-05-20Add multithreading support in the T1 (entropy phase) encoderEven Rouault
- API wise, opj_codec_set_threads() can be used on the encoding side - opj_compress has a -threads switch similar to opj_uncompress
2020-04-21Add support for generation of PLT markers in encoderEven Rouault
* -PLT switch added to opj_compress * Add a opj_encoder_set_extra_options() function that accepts a PLT=YES option, and could be expanded later for other uses. ------- Testing with a Sentinel2 10m band, T36JTT_20160914T074612_B02.jp2, coming from S2A_MSIL1C_20160914T074612_N0204_R135_T36JTT_20160914T081456.SAFE Decompress it to TIFF: ``` opj_uncompress -i T36JTT_20160914T074612_B02.jp2 -o T36JTT_20160914T074612_B02.tif ``` Recompress it with similar parameters as original: ``` opj_compress -n 5 -c [256,256],[256,256],[256,256],[256,256],[256,256] -t 1024,1024 -PLT -i T36JTT_20160914T074612_B02.tif -o T36JTT_20160914T074612_B02_PLT.jp2 ``` Dump codestream detail with GDAL dump_jp2.py utility (https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/samples/dump_jp2.py) ``` python dump_jp2.py T36JTT_20160914T074612_B02.jp2 > /tmp/dump_sentinel2_ori.txt python dump_jp2.py T36JTT_20160914T074612_B02_PLT.jp2 > /tmp/dump_sentinel2_openjpeg_plt.txt ``` The diff between both show very similar structure, and identical number of packets in PLT markers Now testing with Kakadu (KDU803_Demo_Apps_for_Linux-x86-64_200210) Full file decompression: ``` kdu_expand -i T36JTT_20160914T074612_B02_PLT.jp2 -o tmp.tif Consumed 121 tile-part(s) from a total of 121 tile(s). Consumed 80,318,806 codestream bytes (excluding any file format) = 5.329697 bits/pel. Processed using the multi-threaded environment, with 8 parallel threads of execution ``` Partial decompresson (presumably using PLT markers): ``` kdu_expand -i T36JTT_20160914T074612_B02.jp2 -o tmp.pgm -region "{0.5,0.5},{0.01,0.01}" kdu_expand -i T36JTT_20160914T074612_B02_PLT.jp2 -o tmp2.pgm -region "{0.5,0.5},{0.01,0.01}" diff tmp.pgm tmp2.pgm && echo "same !" ``` ------- Funded by ESA for S2-MPC project
2020-04-18struct opj_j2k: remove unused fields, and add some documentationEven Rouault
2020-04-17Merge pull request #1244 from rouault/fix_pi_warningsEven Rouault
Fix warnings about signed/unsigned casts in pi.c
2020-04-17jp3d/jpwl/mj2/jpip: Fix resource leaks (#1226)Eduardo Barretto
This issues were found by cppcheck and coverity.
2020-04-16Fix warnings about signed/unsigned casts in pi.cEven Rouault
2020-04-16Rename mis-named function opj_tcd_get_encoded_tile_size() to ↵Even Rouault
opj_tcd_get_encoder_input_buffer_size()
2020-02-12Implement writing of IMF profilesEven Rouault
Add -IMF switch to opj_compress as well
2020-02-12openjpeg.h: fix values of OPJ_PROFILE_IMF_ constantsEven Rouault
2020-01-30opj_tcd_init_tile(): avoid integer overflowEven Rouault
That could lead to later assertion failures. Fixes #1231 / CVE-2020-8112
2020-01-11opj_j2k_update_image_dimensions(): reject images whose coordinates are ↵Even Rouault
beyond INT_MAX (fixes #1228)
2019-11-17pi.c: avoid integer overflow, resulting in later invalid access to memory in ↵Even Rouault
opj_t2_decode_packets(). Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18979
2019-10-03opj_tcd_mct_decode()/opj_mct_decode()/opj_mct_encode_real()/opj_mct_decode_r ↵Even Rouault
eal(): proper deal with a number of samples larger than 4 billion (refs #1151)
2019-09-03Merge pull request #1164 from sebras/masterEven Rouault
openjp2/j2k: Report error if all wanted components are not decoded.
2019-04-25Change opj_j2k_check_poc_val() to take into account tile numberEven Rouault
2019-04-25Fix POC in multi-tile scenarios: avoid almost endless loop when a tile has ↵Even Rouault
no POC settings
2019-04-25opj_j2k_check_poc_val(): prevent potential write outside of allocated arrayEven Rouault
2019-04-25opj_j2k_check_poc_val(): fix starting index for checking layer dimensionEven Rouault
The standard mandates that the layer index always starts at zero for every progression.
2019-04-25compression: emit POC marker when only one single POC is requested (fixes #1191)Even Rouault
2019-04-23j2k.c: use correct naming convention for total_data_size variableEven Rouault
2019-03-29opj_t1_encode_cblks: fix UBSAN signed integer overflowEven Rouault
Fixes #1053 / CVE-2018-5727 Note: I don't consider this issue to be a security vulnerability, in practice. At least with gcc or clang compilers on x86_64 which generate the same assembly code with or without that fix.
2019-03-29Revert "[MJ2] Avoid index out of bounds access to pi->include[]"Even Rouault
This reverts commit c277159986c80142180fbe5efb256bbf3bdf3edc. The commit didn't compile. include_size is not defined in openmj2
2019-02-21openjp2/j2k: Report error if all wanted components are not decoded.Sebastian Rasmussen
Previously the caller had to check whether each component data had been decoded. This means duplicating the checking in every user of openjpeg which is unnecessary. If the caller wantes to decode all or a set of, or a specific component then openjpeg ought to error out if it was unable to do so. Fixes #1158.
2018-11-28 [JP3D] To avoid divisions by zero / undefined behaviour on shift ↵Young_X
(CVE-2018-14423 Signed-off-by: Young_X <YangX92@hotmail.com>
2018-11-28[OPENJP2] change the way to compute *p_tx0, *p_tx1, *p_ty0, *p_ty1 in functionYoung_X
opj_get_encoding_parameters Signed-off-by: Young_X <YangX92@hotmail.com>
2018-11-28[MJ2] Avoid index out of bounds access to pi->include[]Young_X
Signed-off-by: Young_X <YangX92@hotmail.com>
2018-11-23[MJ2] To avoid divisions by zero / undefined behaviour on shiftYoung_X
Signed-off-by: Young_X <YangX92@hotmail.com>
2018-11-16openjp3d: Int overflow fixed (#1159)ichlubna
When compressing a lot of slices (starting from 44 FullHD slices with 3 8bit components in our experiments) the rate values are high enough to cause an int overflow that leads to negative lengths and wrong results. The cast happens too late.
2018-10-31Fix some potential overflow issues (#1161)Stefan Weil
* Fix some potential overflow issues Put sizeof to the beginning of the multiplication to enforce that size_t instead of smaller integer types is used for the calculation. This fixes warnings from LGTM: Multiplication result may overflow 'unsigned int' before it is converted to 'unsigned long'. It also allows removing some type casts. Signed-off-by: Stefan Weil <sw@weilnetz.de> * Fix code indentation Signed-off-by: Stefan Weil <sw@weilnetz.de>