summaryrefslogtreecommitdiff
path: root/tests
AgeCommit message (Collapse)Author
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-20Testing: revise testing of lossy encoding by comparing PEAK and MSE with ↵Even Rouault
original image
2020-05-20compare_images.c: code reformattingEven Rouault
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-02-12Implement writing of IMF profilesEven Rouault
Add -IMF switch to opj_compress as well
2020-02-07tests: add alternate checksums for libtiff 4.1Even Rouault
Fixes #1233 libtiff 4.1 slightly modifies the way it generates files. So add the new expected md5sum. Not super elegant solution admitedly.
2020-01-13tests/fuzzers: link fuzz binaries using $LIB_FUZZING_ENGINE. (#1230)Max Moroz
This was changed some time ago (https://google.github.io/oss-fuzz/getting-started/new-project-guide/) but the build didn't fail as there is a fallback mechanism. The main advantage of the new approach is that for libFuzzer this produces more performant binaries (as `$LIB_FUZZING_ENGINE` expands into `-fsanitize=fuzzer`, which links libFuzzer from the compiler-rt, allowing better optimization tricks). I'm also experimenting with dataflow (https://github.com/google/oss-fuzz/issues/1632) on your project, and the dataflow config doesn't have a fallback (as it's a new configuration), therefore I'm proposing a change to migrate from `-lFuzzingEngine` to `$LIB_FUZZING_ENGINE`.
2019-06-15opj_decompress_fuzzer: remove checks regarding input dimensions (fixes #1079)Even Rouault
2019-05-26test_decode_area.c: assign tdy to *ptileh instead of *ptilew (fixes #1195)Even Rouault
2019-04-25Add test for previous commitEven Rouault
2019-04-25Add test for previous commitEven Rouault
2019-04-25compression: emit POC marker when only one single POC is requested (fixes #1191)Even Rouault
2018-06-20Add test cases for https://github.com/uclouvain/openjpeg/issues/1120 and ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2785
2017-11-30opj_j2k_read_cod: remove check for 'No more than one COD marker per tile' ↵Even Rouault
(fixes #1043) This check was added per https://github.com/uclouvain/openjpeg/commit/daed8cc9195555e101ab708a501af2dfe6d5e001 to fix https://github.com/uclouvain/openjpeg/issues/476 , but it does not seem to be necessary with latest master (issue476.jp2 doesn't cause memory issues), and breaks reading legit files.
2017-09-19Add capability to decode only a subset of all components of an image.Even Rouault
This adds a opj_set_decoded_components(opj_codec_t *p_codec, OPJ_UINT32 numcomps, const OPJ_UINT32* comps_indices) function, and equivalent "opj_decompress -c compno[,compno]*" option. When specified, neither the MCT transform nor JP2 channel transformations will be applied. Tests added for various combinations of whole image vs tiled-based decoding, full or reduced resolution, use of decode area or not.
2017-09-01test_decode_area: accept user bounds in -strip_height modeEven Rouault
2017-09-01Allow several repeated calls to opj_set_decode_area() and opj_decode() for ↵Even Rouault
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.
2017-08-28Add test for fix of a55c024fc6b917a409b85aeafd7326421c4aea34Even Rouault
2017-08-24issue104_jpxstream.jp2 decompresses just fine (and like Kakadu). Update ↵Even Rouault
md5refs.txt and remove from knownfailures
2017-08-24Remove broken.jpc test from known failures, by avoiding too long processing timeEven Rouault
2017-08-24Remove -NR-DEC-p1_06.j2k-156-decode and NR-DEC-p1_06.j2k-164-decode from ↵Even Rouault
knownfailures and make them explicit failures. The result images are empty at the requested resolution
2017-08-21test_tile_encoder: fix checks on argcEven Rouault
2017-08-20Subtile decoding: only do 9x7 IDWT computations on relevant areas of ↵Even Rouault
tile-component buffer.
2017-08-18Subtile decoding: only do 5x3 IDWT computations on relevant areas of ↵Even Rouault
tile-component buffer. This lowers 'bin/opj_decompress -i ../MAPA.jp2 -o out.tif -d 0,0,256,256' down to 0.860s
2017-08-18test_decode_area: fix to make it work with odd image dimensionsEven Rouault
2017-08-17Sub-tile decoding: only decode precincts and codeblocks that intersect the ↵Even Rouault
window specified in opj_set_decode_area()
2017-08-17opj_decompress_fuzzer.cpp: reject images with too big tiles. Fixes ↵Even Rouault
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2918. Credit to OSS Fuzz
2017-08-14Encoder: grow buffer size in opj_tcd_code_block_enc_allocate_data() to avoid ↵Even Rouault
write heap buffer overflow in opj_mqc_flush (#982)
2017-08-10Reformat tests/test_tile_encoder.cEven Rouault
2017-08-09Partial revert BPC related check of #975 (#979)Even Rouault
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-07-27Avoids undefined shift behaviour in m_dc_level_shift computationEven Rouault
Fixes warning found on clusterfuzz-testcase-minimized-5146316340461568 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2495 Credit to OSS Fuzz
2017-07-26Spelling fixes (patch by ka7, #890, rebased on top of master)Even Rouault
2017-07-03Add tests/fuzzers for OSS Fuzz (#965)Even Rouault
2017-06-12Encoder: fix packet writing of empty sub-bands (#891, #892)Even Rouault
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.
2017-06-09T1: fix BYPASS/LAZY, TERMALL/RESTART and PTERM/ERTERM encoding modes. (#674)fix_bypass_pterm_termallEven Rouault
There were a number of defects regarding when and how the termination of passes had to done and the computation of their rate.
2017-05-23Tests: test opj_compress in VSC mode (related to #172)Even Rouault
2017-05-11perf_test.py: implement -i optionEven Rouault
2017-05-09Add profiling of CPU and memory usage (#912)Even Rouault
2017-05-06Add performance benchmarking scriptsEven Rouault
And run them by Travis-CI
2016-09-22Fix PNM file reading (#847)Matthieu Darbois
Malformed PNM file could cause a crash in opj_compress. Checks were added to prevent this. Fixes #843 Updates #440
2016-09-21Fix some issues reported by Coverity Scan (#846)Stefan Weil
* test_tile_decoder: Fix potential buffer overflow (coverity) CID 1190155 (#1 of 1): Unbounded source buffer (STRING_SIZE) Using a pointer instead of buffer of fixed size avoids the limit for the length of the input file name. Signed-off-by: Stefan Weil <sw@weilnetz.de> * test_tile_encoder: Fix potential buffer overflow (coverity) CID 1190154 (#1 of 1): Unbounded source buffer (STRING_SIZE) Using a pointer instead of buffer of fixed size avoids the limit for the length of the output file name. This implies that the length can exceed 255, so the data type for variable len had to be fixed, too. Signed-off-by: Stefan Weil <sw@weilnetz.de> * openjpip: Initialize data before returning it This fixes an error reported by Coverity: CID 1190143 (#1 of 1): Uninitialized scalar variable (UNINIT) Signed-off-by: Stefan Weil <sw@weilnetz.de>
2016-09-11Add test for issue 820 (#829)Matthieu Darbois
Update uclouvain/openjpeg#820
2016-09-08Add test for issue 826 (#827)Matthieu Darbois
Update uclouvain/openjpeg#826 Also correct names for data of issue uclouvain/openjpeg#823
2016-09-08Add sanity check for tile coordinates (#823)Matthieu Darbois
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
2016-09-07Add test for PR 818 (#822)Matthieu Darbois
update uclouvain/openjpeg#818
2016-07-14Add compilation test for standalone inclusion of openjpeg.h (#798)Matthieu Darbois
This ensures all openjpeg.h dependencies are met. Fix #673
2016-05-08Correct expected result for test of issue 495mayeut
2016-05-08Fix Out-of-Bounds Access in function opj_tgt_resetmayeut
Fix uclouvain/openjpeg#775
2016-05-08Fix Heap Buffer Overflow in function color_cmyk_to_rgbmayeut
Fix uclouvain/openjpeg#774
2016-05-08Fix division by zeromayeut
Fix uclouvain/openjpeg#733
generated by cgit v1.2.3 (git 2.46.0) at 2026-04-10 02:38:32 +0000