| Age | Commit message (Collapse) | Author |
|
organization
~ 9% speed improvement seen on 10980x10980 uint16 image, T36JTT_20160914T074612_B02.tif
opj_compress time from 17.2s to 15.8s
|
|
`bench_dwt -I -encode` times goes from 8.6s to 2.1s
|
|
`bench_dwt -encode` times goes from 7.9s to 1.7s
|
|
vertical pass
|
|
|
|
vertical pass
|
|
horizontal pass
|
|
"bench_dwt -I" time goes from 2.2s to 1.5s
|
|
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.
|
|
"bench_dwt -I" time goes from 2.8s to 2.2s
|
|
|
|
test suite
|
|
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 !
|
|
messing up with stepsize (no functional change)
|
|
side
|
|
potential division by zero
|
|
|
|
|
|
|
|
functional change)
|
|
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.
|
|
- API wise, opj_codec_set_threads() can be used on the encoding side
- opj_compress has a -threads switch similar to opj_uncompress
|
|
* -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
|
|
|
|
Fix warnings about signed/unsigned casts in pi.c
|
|
This issues were found by cppcheck and coverity.
|
|
|
|
opj_tcd_get_encoder_input_buffer_size()
|
|
Add -IMF switch to opj_compress as well
|
|
|
|
That could lead to later assertion failures.
Fixes #1231 / CVE-2020-8112
|
|
beyond INT_MAX (fixes #1228)
|
|
opj_t2_decode_packets(). Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18979
|
|
eal(): proper deal with a number of samples larger than 4 billion (refs #1151)
|
|
openjp2/j2k: Report error if all wanted components are not decoded.
|
|
|
|
no POC settings
|
|
|
|
The standard mandates that the layer index always starts at zero for every
progression.
|
|
|
|
|
|
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.
|
|
This reverts commit c277159986c80142180fbe5efb256bbf3bdf3edc.
The commit didn't compile. include_size is not defined in openmj2
|
|
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.
|
|
(CVE-2018-14423
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
opj_get_encoding_parameters
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
Signed-off-by: Young_X <YangX92@hotmail.com>
|
|
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.
|
|
* 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>
|