jconfig.h: Restore BITS_IN_JSAMPLE macro
Because of e8b40f3c2b, we now support
multiple data precisions in the same libjpeg API library, so
BITS_IN_JSAMPLE is no longer used to specify the data precision at build
time. However, some downstream software expects the macro to be
defined. Since 12-bit data precision is an opt-in feature that requires
explicitly calling 12-bit-specific libjpeg API functions and using
12-bit-specific data types, the unmodified portion of the libjpeg API
still behaves as if it were built for 8-bit precision, and JSAMPLE is
still literally an 8-bit data type. Thus, it is correct to externally
define BITS_IN_JSAMPLE to 8 in jconfig.h. Since the build system also
uses BITS_IN_JSAMPLE internally to build both 8-bit and 12-bit versions
of relevant modules, the definition of BITS_IN_JSAMPLE in jconfig.h is
now guarded by #ifndef BITS_IN_JSAMPLE. (Hopefully that doesn't cause
any problems.)
Fixes #632
This commit is contained in:
13
jconfig.h.in
13
jconfig.h.in
@@ -21,6 +21,19 @@
|
||||
/* Use accelerated SIMD routines when using 8-bit samples */
|
||||
#cmakedefine WITH_SIMD 1
|
||||
|
||||
/* This version of libjpeg-turbo supports run-time selection of data precision,
|
||||
* so BITS_IN_JSAMPLE is no longer used to specify the data precision at build
|
||||
* time. However, some downstream software expects the macro to be defined.
|
||||
* Since 12-bit data precision is an opt-in feature that requires explicitly
|
||||
* calling 12-bit-specific libjpeg API functions and using 12-bit-specific data
|
||||
* types, the unmodified portion of the libjpeg API still behaves as if it were
|
||||
* built for 8-bit precision, and JSAMPLE is still literally an 8-bit data
|
||||
* type. Thus, it is correct to define BITS_IN_JSAMPLE to 8 here.
|
||||
*/
|
||||
#ifndef BITS_IN_JSAMPLE
|
||||
#define BITS_IN_JSAMPLE 8
|
||||
#endif
|
||||
|
||||
#ifdef _WIN32
|
||||
|
||||
#undef RIGHT_SHIFT_IS_UNSIGNED
|
||||
|
||||
Reference in New Issue
Block a user