Lines Matching +full:check +full:- +full:api +full:- +full:compatibility
4 libjpeg-turbo is a JPEG image codec that uses SIMD instructions to accelerate
5 baseline JPEG compression and decompression on x86, x86-64, Arm, PowerPC, and
6 MIPS systems, as well as progressive JPEG compression on x86, x86-64, and Arm
7 systems. On such systems, libjpeg-turbo is generally 2-6x as fast as libjpeg,
8 all else being equal. On other types of systems, libjpeg-turbo can still
9 outperform libjpeg by a significant amount, by virtue of its highly-optimized
10 Huffman coding routines. In many cases, the performance of libjpeg-turbo
11 rivals that of proprietary high-speed JPEG codecs.
13 libjpeg-turbo implements both the traditional libjpeg API as well as the less
14 powerful but more straightforward TurboJPEG API. libjpeg-turbo also features
15 colorspace extensions that allow it to compress from/decompress to 32-bit and
16 big-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Java
19 libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated
22 early 2010, libjpeg-turbo spun off into an independent project, with the goal
23 of making high-speed JPEG compression/decompression technology available to a
30 libjpeg-turbo is covered by three compatible BSD-style open source licenses.
31 Refer to [LICENSE.md](LICENSE.md) for a roll-up of license terms.
34 Building libjpeg-turbo
40 Using libjpeg-turbo
43 libjpeg-turbo includes two APIs that can be used to compress and decompress
46 - **TurboJPEG API**<br>
47 This API provides an easy-to-use interface for compressing and decompressing
49 straightforward to achieve using the underlying libjpeg API, such as
51 transforms on an image. The Java interface for libjpeg-turbo is written on
52 top of the TurboJPEG API. The TurboJPEG API is recommended for first-time
53 users of libjpeg-turbo. Refer to [tjexample.c](tjexample.c) and
55 <http://libjpeg-turbo.org/Documentation/Documentation> for API documentation.
57 - **libjpeg API**<br>
58 This is the de facto industry-standard API for compressing and decompressing
59 JPEG images. It is more difficult to use than the TurboJPEG API but also
60 more powerful. The libjpeg API implementation in libjpeg-turbo is both
61 API/ABI-compatible and mathematically compatible with libjpeg v6b. It can
62 also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8
64 of its usage and to [libjpeg.txt](libjpeg.txt) for API documentation.
66 There is no significant performance advantage to either API when both are used
70 ---------------------
72 libjpeg-turbo includes extensions that allow JPEG images to be compressed
89 (decompression) to one of these values will cause libjpeg-turbo to read the
93 Your application can check for the existence of these extensions at compile
100 Applications can trap this error in order to test whether run-time support is
104 X byte is undefined, and in order to ensure the best performance, libjpeg-turbo
111 Your application can check for the existence of the alpha channel colorspace
116 [jcstest.c](jcstest.c), located in the libjpeg-turbo source tree, demonstrates
117 how to check for the existence of the colorspace extensions at compile time and
120 libjpeg v7 and v8 API/ABI Emulation
121 -----------------------------------
126 ABI compatibility with previous libjpeg releases. Thus, programs that were
127 built to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is
131 in libjpeg-turbo. It should be noted, however, that this feature was added
134 without recompiling. libjpeg-turbo does not claim to support all of the
138 By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you
139 can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so
141 libjpeg-turbo. The following section describes which libjpeg v7+ features are
148 - **libjpeg API: IDCT scaling extensions in decompressor**<br>
149 libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
151 and 1/2 are SIMD-accelerated.)
153 - **libjpeg API: Arithmetic coding**
155 - **libjpeg API: In-memory source and destination managers**<br>
158 - **cjpeg: Separate quality settings for luminance and chrominance**<br>
159 Note that the libpjeg v7+ API was extended to accommodate this feature only
163 - **cjpeg: 32-bit BMP support**
165 - **cjpeg: `-rgb` option**
167 - **jpegtran: Lossless cropping**
169 - **jpegtran: `-perfect` option**
171 - **jpegtran: Forcing width/height when performing lossless crop**
173 - **rdjpgcom: `-raw` option**
175 - **rdjpgcom: Locale awareness**
183 <http://www.libjpeg-turbo.org/About/SmartScale> and draw their own conclusions,
185 demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
187 - **libjpeg API: DCT scaling in compressor**<br>
190 emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
194 - **libjpeg API: SmartScale**<br>
207 - **libjpeg API: Fancy downsampling in compressor**<br>
211 - **jpegtran: Scaling**<br>
215 - **Lossless RGB JPEG files**<br>
224 extend the API in this manner, as the color transform could have just as easily
226 backward ABI compatibility.
235 In-Memory Source/Destination Managers
236 -------------------------------------
238 By default, libjpeg-turbo 1.3 and later includes the `jpeg_mem_src()` and
239 `jpeg_mem_dest()` functions, even when not emulating the libjpeg v8 API/ABI.
240 Previously, it was necessary to build libjpeg-turbo from source with libjpeg v8
241 API/ABI emulation in order to use the in-memory source/destination managers,
243 the libjpeg v6b API/ABI as well. This allows the use of those functions by
244 programs that need them, without breaking ABI compatibility for programs that
246 libjpeg-turbo binaries.
249 v6b or v7 API can pass an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to
250 building libjpeg-turbo. This will restore the pre-1.3 behavior, in which
252 libjpeg v8 API/ABI.
254 On Un*x systems, including the in-memory source/destination managers changes
255 the dynamic library version from 62.2.0 to 62.3.0 if using libjpeg v6b API/ABI
256 emulation and from 7.2.0 to 7.3.0 if using libjpeg v7 API/ABI emulation.
260 is built against libjpeg-turbo 1.3+ and uses `jpeg_mem_src()` or
262 of libjpeg-turbo or against libjpeg v7- until the program actually tries to
264 If a program is built against the libjpeg-turbo 1.3+ DLL and uses
265 `jpeg_mem_src()` or `jpeg_mem_dest()`, then it must use the libjpeg-turbo 1.3+
268 Both cjpeg and djpeg have been extended to allow testing the in-memory
273 Mathematical Compatibility
276 For the most part, libjpeg-turbo should produce identical output to libjpeg
278 which case the outputs of libjpeg v6b and libjpeg-turbo can differ for the
281 - The SSE/SSE2 floating point DCT implementation in libjpeg-turbo is ever so
286 - When not using the SIMD extensions, libjpeg-turbo uses the more accurate
298 - If the floating point algorithms in libjpeg-turbo are not implemented using
302 While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood it is
304 cases in which libjpeg-turbo cannot be expected to produce the same output as
307 - When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8
309 libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.
311 - When using chrominance subsampling, because libjpeg v8 implements this
317 - When decompressing using a scaling factor > 1 and merged (AKA "non-fancy" or
318 "non-smooth") chrominance upsampling, because libjpeg v8 does not support
326 ---------------
328 The optimized Huffman decoder in libjpeg-turbo does not handle restart markers
338 -----------------------------------------------
340 The algorithm used by the SIMD-accelerated quantization function cannot produce
342 quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization
353 with libjpeg-turbo's SIMD extensions. It is generally recommended that the
354 SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0`
356 `JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind,