With #1450 which goes with 480cc9d49775d018c19ce0e01f6be27858d63d39 "Remove support for non-C99 compilers (like VS2010) that don't support snprintf()",
support for MSVC versions prior to vs2015 is dropped: https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010
This means that all supported MSVC versions do have `stdint.h` & `inttypes.h` now.
For non windows platforms, those headers were already mandatory.
Make them mandatory for all builds.
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
This makes it possible to build j2k.c without warnings using the macOS
13 SDK. Calls to sprintf are replaced with snprintf, passing appropriate
buffer sizes.
It doesn’t appear that any of the changed uses of sprintf were actually
unsafe, so no behavior change is expected aside from SDK compatibility.
The macOS 13 SDK deprecates sprintf as it’s difficult to use safely. The
deprecation warning message is visible when building C++, but it is not
normally visible when building plain C code due to a quirk in how
sprintf is declared in the SDK. However, the deprecation message is
visible when building plain C under Address Sanitizer
(-fsanitize=address). This discrepancy was discovered at
https://crbug.com/1381706 and reported to Apple with a copy at
https://openradar.appspot.com/FB11761475.
The macOS 13 SDK is packaged in Xcode 14.1, released on 2022-11-01. This
also affects the iOS 16 SDK and other 2022-era Apple OS SDKs packaged in
Xcode 14.0, released on 2022-09-12.
j2k.c is visible to the Chromium build via PDFium, and this change is
needed to allow Chromium to move forward to the macOS 13 SDK.
This change is limited to src/lib/openjp2. Other uses of sprintf were
found throughout openjpeg.
The issue was found while fuzzing opencv:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47342
The read overflow triggered by reading `src[j]` in
```cpp
for (j = 0; j < max; ++j) {
dst[j] = src[j];
}
```
The max is calculated as `new_comps[pcol].w * new_comps[pcol].h`, however the `src = old_comps[cmp].data;` which may have different `w` and `h` dimensions.
Modified the mel_init code to replace the assert statement with an if statement, returning false when an incorrect sequence of bytes are encountered in the MEL segment. Similar code should be added to the main MEL decoding subrountine, but the change is more involved; in any case, an incorrect sequence produces incorrect results, but should not be harmful or cause a crash.
- Avoid doing 128 iterations all the time, and stop when the threshold
doesn't vary much
- Avoid calling costly opj_t2_encode_packets() repeatdly when bisecting the
layer ratio if the truncation points haven't changed since the last
iteration.
When used with the GDAL gdal_translate application to convert a 11977 x
8745 raster with data type UInt16 and 8 channels, the conversion time
to JPEG2000 with 20 quality layers using disto/rate allocation (
-co "IC=C8" -co "JPEG2000_DRIVER=JP2OPENJPEG" -co "PROFILE=NPJE_NUMERICALLY_LOSSLESS"
creation options of the GDAL NITF driver) goes from 5m56 wall clock
(8m20s total, 12 vCPUs) down to 1m16 wall clock (3m45 total).
* 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
allows for the usage of $(pkgconf --static --cflags libopenjp2) to produce
the proper CFLAGS for static linking. Relies on pkgconf rather than pkg-config
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
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.
