Fork of openjpeg library for JPEG2000 encoding and decoding https://git.carlh.net/cgit/openjpeg/atom?h=master-cdist 2020-05-20T19:10:55Z 2020-05-20T19:10:55Z Even Rouault even.rouault@spatialys.com 2020-05-20T19:10:55Z urn:sha1:19ef7f26c43f689b627aad642da7f6150893b863 Add check to validate SGcod/SPcoc/SPcod parameter values. 2020-04-21T13:55:44Z Even Rouault even.rouault@spatialys.com 2020-04-21T13:55:44Z urn:sha1:4edb8c83374f52cd6a8f2c7c875e8ffacccb5fa5 * -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-12T14:55:25Z Even Rouault even.rouault@spatialys.com 2020-02-12T14:55:16Z urn:sha1:84f3bebbff515f2b00ccf0c817930ebb10b91760 Add -IMF switch to opj_compress as well 2020-02-07T21:05:55Z Even Rouault even.rouault@spatialys.com 2020-02-07T20:53:10Z urn:sha1:b5cb419faff300fdbc0b4e98dab5c9010db6f39d 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-13T17:07:54Z Max Moroz dor3s1@gmail.com 2020-01-13T17:07:54Z urn:sha1:b63a433ba168bad5fa10e83de04d6305e6a222e2 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-09-04T03:14:41Z Sebastian Rasmussen sebras@gmail.com 2018-10-31T14:56:11Z urn:sha1:f3ee448815eb992b8d4746e32c05e8289f30415f 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. 2019-06-15T07:55:16Z Even Rouault even.rouault@spatialys.com 2019-06-15T07:55:16Z urn:sha1:8db9d25dcf360528fd1e094e4f9274c0635e90cc 2019-05-26T09:06:30Z Even Rouault even.rouault@spatialys.com 2019-05-26T09:06:01Z urn:sha1:f4d65783593fd0490e0fdb9f323f2d5aff81a21d 2019-04-25T12:40:56Z Even Rouault even.rouault@spatialys.com 2019-04-24T23:29:38Z urn:sha1:bdec5ae2723369be5abba7aaae398aa4ae3225cc 2019-04-25T12:40:56Z Even Rouault even.rouault@spatialys.com 2019-04-24T22:40:04Z urn:sha1:b86717fdd36b628ea7ecb5c24f7a086bf5bcd3a7