* Add GNUInstallDirs for standard installation directories
Distributions are given standard variables for already existing hooks.
Multiarch libdirs is taken care of automagically.
Raises minimum cmake version by a little.
* Handle CMAKE_INSTALL_xxx being absolute paths for .pc file generation
In some cases the CMAKE_INSTAL_{BIN,MAN,DOC,LIB,INCLUDE}DIR variables
may turn out to be absolute paths in which case prepending ${prefix} in
the pkg-config .pc files will result in incorrect values.
For .pc file generation, figure out if these variables are absolute and
omit the prefix in the configured file when so.
See: ab25e4b7ed
Add a -allow-partial option to opj_decompress utility and a opj_decoder_set_strict_mode() option to the API
Co-authored-by: Chris Hafey <chafey@gmail.com>
and add a -GuardBits option to opj_compress.
The recently-released SMPTE DCP Bv2.1 Application Profile (link below)
says that the number of guard bits in the QCD marker shall be 1 for 2K
content and 2 for 4K content. This change allows the number of guard bits
to be configured, so that users of openjpeg have the control they need to meet the specification.
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9161348
This is an alternative implementation of https://github.com/uclouvain/openjpeg/pull/1388
that keeps ABI unchanged.
As discussed in pull request 1396, added a check for integer overflow.
Change list:
Defined num_images as unsigned int
Moved the if statement to check for an empty directory to the beginning of the read directory section
Added a check to see if num images would roll back to zero when incrementing.
Sometimes, given the same (16-bit TIF) input, one wants to generate a variety of J2C outputs (say, 16-, 12-, and 10-bit). This patch allows one to downsample input files, and so makes it easier to automate OpenJPEG in mass generation of J2Cs without having to pipe though an image processing program.
in opj_image_comp and opj_image_comptparm structures.
bpp was redundant with prec, and almost never set by the library, except
by opj_image_create(). This change should hopefully not impact existing,
working, users of the API, which should already have used prec to get
things working.
Fixes#1379
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.
* -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
width/length dimensions read from bmp headers are not necessarily
valid. For instance they may have been maliciously set to very large
values with the intention to cause DoS (large memory allocation, stack
overflow). In these cases we want to detect the invalid size as early
as possible.
This commit introduces a counter which verifies that the number of
written bytes corresponds to the advertized width/length.
See commit 8ee335227b for details.
Signed-off-by: Young Xiao <YangX92@hotmail.com>
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.
width/length dimensions read from bmp headers are not necessarily
valid. For instance they may have been maliciously set to very large
values with the intention to cause DoS (large memory allocation, stack
overflow). In these cases we want to detect the invalid size as early
as possible.
This commit introduces a counter which verifies that the number of
written bytes corresponds to the advertized width/length.
Fixes#1059 (CVE-2018-6616).
Tile components in a JP2 image might have null data pointer by defining a
zero component size (for example using large horizontal or vertical
sampling periods). This null data pointer leads to null image component
data pointer, causing crash when dereferenced without != null check in
imagetopnm.
Add != null check.
This commit addresses #1152 (CVE-2018-18088).
Even Rouault
Thomas Bracht Laumann Jespersen
Pei Jia
Robert Gabriel Jakabosky
Eric Harvey
Brad Parham
Stefan Weil
msheby
Jamaika1
Dimitri Papadopoulos
xiaoxiaoafeifei
szukw000
Eduardo Barretto
Robert Ancell
Young Xiao
Sebastian Rasmussen
Hugo Lefeuvre
Even Rouault