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).
Using CMakePackageConfigHelpers, we can generate a relocatable
OpenJPEGConfig.config, using the PATH_VARS feature to make
CMAKE_INSTALL_LIBDIR relative to the installed location.
This change is needed for me when cross-compiling since
CMAKE_INSTALL_FULL_LIBDIR is a path inside the sysroot rather than
an absolute path to the actual includes. Without this change poppler
ends up passing a -I flag that does not exist.
This includes fallback code for CMake 2.8, which adds a bit of complexity,
since I'm not sure if raising the minimum to 3.0 (now over 8 years old)
is acceptable.
* 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.