Fork of openjpeg library for JPEG2000 encoding and decoding https://git.carlh.net/cgit/openjpeg/atom?h=floating_point_irreversible_encoding 2020-05-20T18:31:28Z 2020-05-20T18:31:28Z Even Rouault even.rouault@spatialys.com 2020-05-20T16:00:45Z urn:sha1:3cd1305596f191a01afdc11f9355f9c6590065dd 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-20T18:31:28Z Even Rouault even.rouault@spatialys.com 2020-05-19T16:03:58Z urn:sha1:fe4c15f12c562a42a6b0c4b0a0c5e42a25797235 2020-05-20T18:31:28Z Even Rouault even.rouault@spatialys.com 2020-05-19T16:03:29Z urn:sha1:c2b9d09c65ec5db4a94de961b0470923aec74e2e 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-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