| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Stefan Weil <sw@weilnetz.de>
|
|
Compatibility for cmake version < 3.5 is now deprecated in cmake and
specifing version below 3.5 in cmake_minimum_required produces a
warning.[1]
[1] https://cmake.org/cmake/help/latest/release/3.27.html#deprecated-and-removed-features
|
|
|
|
There are a bunch of loc where we can see a usage of `opj_int_ceildiv`:
```
(OPJ_UINT32)opj_int_ceildiv((OPJ_INT32)a, (OPJ_INT32)b);
```
where a & b are `OPJ_UINT32`.
This can lead to overflow/underflow for some a/b combinations.
Replace those calls by `opj_uint_ceildiv` instead to always get a correct result.
This also allows some valid single tile images with huge tile size to be decoded properly.
Fix #1438
|
|
|
|
|
|
There are a few limitations:
- mixed mode (HT and regular code blocks) is not supported.
- ROI in HT blocks is not supported.
- Placeholder passes are not supported.
- MultiHT sets are not support, only a singleHT set.
- there are known issues with some compliance testing files related to
the parsing of packet header.
|
|
Support was already there, but restricted to Cinema and IMF profiles,
and 255 tiles
* Add -TLM switch added to opj_compress
* Make opj_encoder_set_extra_options() function accept a TLM=YES option.
|
|
tile-part with TPsot == 0 and TNsot == 0, and with missing EOC
|
|
Single-threaded performance improvements in forward DWT for 5-3 and 9-7 (and other improvements)
|
|
Add check to validate SGcod/SPcoc/SPcod parameter values.
|
|
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 !
|
|
original image
|
|
* -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
|
|
Add -IMF switch to opj_compress as well
|
|
Fixes #1233
libtiff 4.1 slightly modifies the way it generates files. So
add the new expected md5sum.
Not super elegant solution admitedly.
|
|
Previously the multiple component transformation SGcod(C)
and wavelet transformation SPcod(H)/SPcoc(E) parameter
values were never checked, allowing for out of range values.
The lack of validation allowed the bit stream provided in
issue #1158 through. After this commit an error message
points to the marker segments' parameters as being out of
range.
input/nonregression/edf_c2_20.jp2 contains an SPcod(H) value
of 17, but according to Table A-20 of the specification only
values 0 and 1 are valid. input/nonregression/issue826.jp2
contains a SGcod(B) value of 2, but according to Table A-17
of the specification only values 0 and 1 are valid.
input/nonregression/oss-fuzz2785.jp2 contains a SGcod(B)
value of 32, but it is likewise limited to 0 or 1. These test
cases have been updated to consistently fail to parse the
headers since they contain out of bounds values.
This fixes issue #1210.
|
|
|
|
|
|
|
|
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2785
|
|
(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.
|
|
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.
|
|
|
|
md5refs.txt and remove from knownfailures
|
|
|
|
knownfailures
and make them explicit failures. The result images are empty at the requested resolution
|
|
write heap buffer overflow in opj_mqc_flush (#982)
|
|
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.
|
|
Fixes warning found on clusterfuzz-testcase-minimized-5146316340461568
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2495
Credit to OSS Fuzz
|
|
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.
|
|
|
|
Malformed PNM file could cause a crash in opj_compress.
Checks were added to prevent this.
Fixes #843
Updates #440
|
|
Update uclouvain/openjpeg#820
|
|
Update uclouvain/openjpeg#826
Also correct names for data of issue uclouvain/openjpeg#823
|
|
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
|
|
update uclouvain/openjpeg#818
|
|
|
|
Fix uclouvain/openjpeg#775
|
|
Fix uclouvain/openjpeg#774
|
|
Fix uclouvain/openjpeg#733
|
|
Inspired from https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Maintenance/HowToCreateTheCMakeCaseConversion.txt
This needs vim 7.3 and fails with vim 7.4
This also fixes a number of :
- missing empty line at end of files
- useless space at end of lines
|
|
Update uclouvain/openjpeg#725
Update uclouvain/openjpeg#726
|
|
Update to mm2/Little-CMS@0e8234e090d6aab33f90e2eb0296f30aa0705e57
|
|
Fix issue 135
The fix is legal regarding the standard but I did not manage to find out if it covers a bug in opj_t2_read_packet_data or if the file is corrupted
|
|
|
|
dwt_interleave_h.gsr105.jp2 now has the same output as kakadu
issue399 is corrupted. Only the corrupted part changes.
Update known failures for x86 MD5
NR-DEC-kodak_2layers_lrcp.j2c-31-decode-md5
NR-DEC-kodak_2layers_lrcp.j2c-32-decode-md5
NR-DEC-issue135.j2k-68-decode-md5
|
|
Update uclouvain/openjpeg#729
|
|
|
