README.md

   1 Background
   2 ==========
   3
   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.
  12
  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
  17 interface.
  18
  19 libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated
  20 derivative of libjpeg v6b developed by Miyasaka Masaru.  The TigerVNC and
  21 VirtualGL projects made numerous enhancements to the codec in 2009, and in
  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
  24 broader range of users and developers.  libjpeg-turbo is an ISO/IEC and ITU-T
  25 reference implementation of the JPEG standard.
  26
  27 More information about libjpeg-turbo can be found at
  28 <https://libjpeg-turbo.org>.
  29
  30
  31 Funding
  32 =======
  33
  34 libjpeg-turbo is an independent open source project, but we rely on patronage
  35 and funded development in order to maintain that independence.  The easiest way
  36 to ensure that libjpeg-turbo remains community-focused and free of any one
  37 organization's agenda is to
  38 [sponsor our project through GitHub](https://github.com/sponsors/libjpeg-turbo).
  39 All sponsorship money goes directly toward funding the labor necessary to
  40 maintain libjpeg-turbo, support the user community, and implement bug fixes and
  41 strategically important features.
  42
  43 [![Sponsor libjpeg-turbo](https://img.shields.io/github/sponsors/libjpeg-turbo?label=Sponsor&logo=GitHub)](https://github.com/sponsors/libjpeg-turbo)
  44
  45
  46 License
  47 =======
  48
  49 libjpeg-turbo is covered by three compatible BSD-style open source licenses.
  50 Refer to [LICENSE.md](LICENSE.md) for a roll-up of license terms.
  51
  52
  53 Building libjpeg-turbo
  54 ======================
  55
  56 Refer to [BUILDING.md](BUILDING.md) for complete instructions.
  57
  58
  59 Using libjpeg-turbo
  60 ===================
  61
  62 libjpeg-turbo includes two APIs that can be used to compress and decompress
  63 JPEG images:
  64
  65 - **TurboJPEG API**<br>
  66   This API provides an easy-to-use interface for compressing and decompressing
  67   JPEG images in memory.  It also provides some functionality that would not be
  68   straightforward to achieve using the underlying libjpeg API, such as
  69   generating planar YUV images and performing multiple simultaneous lossless
  70   transforms on an image.  The Java interface for libjpeg-turbo is written on
  71   top of the TurboJPEG API.  The TurboJPEG API is recommended for first-time
  72   users of libjpeg-turbo.  Refer to [tjexample.c](tjexample.c) and
  73   [TJExample.java](java/TJExample.java) for examples of its usage and to
  74   <http://libjpeg-turbo.org/Documentation/Documentation> for API documentation.
  75
  76 - **libjpeg API**<br>
  77   This is the de facto industry-standard API for compressing and decompressing
  78   JPEG images.  It is more difficult to use than the TurboJPEG API but also
  79   more powerful.  The libjpeg API implementation in libjpeg-turbo is both
  80   API/ABI-compatible and mathematically compatible with libjpeg v6b.  It can
  81   also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8
  82   (see below.)  Refer to [cjpeg.c](cjpeg.c) and [djpeg.c](djpeg.c) for examples
  83   of its usage and to [libjpeg.txt](libjpeg.txt) for API documentation.
  84
  85 There is no significant performance advantage to either API when both are used
  86 to perform similar operations.
  87
  88 Colorspace Extensions
  89 ---------------------
  90
  91 libjpeg-turbo includes extensions that allow JPEG images to be compressed
  92 directly from (and decompressed directly to) buffers that use BGR, BGRX,
  93 RGBX, XBGR, and XRGB pixel ordering.  This is implemented with ten new
  94 colorspace constants:
  95
  96     JCS_EXT_RGB   /* red/green/blue */
  97     JCS_EXT_RGBX  /* red/green/blue/x */
  98     JCS_EXT_BGR   /* blue/green/red */
  99     JCS_EXT_BGRX  /* blue/green/red/x */
 100     JCS_EXT_XBGR  /* x/blue/green/red */
 101     JCS_EXT_XRGB  /* x/red/green/blue */
 102     JCS_EXT_RGBA  /* red/green/blue/alpha */
 103     JCS_EXT_BGRA  /* blue/green/red/alpha */
 104     JCS_EXT_ABGR  /* alpha/blue/green/red */
 105     JCS_EXT_ARGB  /* alpha/red/green/blue */
 106
 107 Setting `cinfo.in_color_space` (compression) or `cinfo.out_color_space`
 108 (decompression) to one of these values will cause libjpeg-turbo to read the
 109 red, green, and blue values from (or write them to) the appropriate position in
 110 the pixel when compressing from/decompressing to an RGB buffer.
 111
 112 Your application can check for the existence of these extensions at compile
 113 time with:
 114
 115     #ifdef JCS_EXTENSIONS
 116
 117 At run time, attempting to use these extensions with a libjpeg implementation
 118 that does not support them will result in a "Bogus input colorspace" error.
 119 Applications can trap this error in order to test whether run-time support is
 120 available for the colorspace extensions.
 121
 122 When using the RGBX, BGRX, XBGR, and XRGB colorspaces during decompression, the
 123 X byte is undefined, and in order to ensure the best performance, libjpeg-turbo
 124 can set that byte to whatever value it wishes.  If an application expects the X
 125 byte to be used as an alpha channel, then it should specify `JCS_EXT_RGBA`,
 126 `JCS_EXT_BGRA`, `JCS_EXT_ABGR`, or `JCS_EXT_ARGB`.  When these colorspace
 127 constants are used, the X byte is guaranteed to be 0xFF, which is interpreted
 128 as opaque.
 129
 130 Your application can check for the existence of the alpha channel colorspace
 131 extensions at compile time with:
 132
 133     #ifdef JCS_ALPHA_EXTENSIONS
 134
 135 [jcstest.c](jcstest.c), located in the libjpeg-turbo source tree, demonstrates
 136 how to check for the existence of the colorspace extensions at compile time and
 137 run time.
 138
 139 libjpeg v7 and v8 API/ABI Emulation
 140 -----------------------------------
 141
 142 With libjpeg v7 and v8, new features were added that necessitated extending the
 143 compression and decompression structures.  Unfortunately, due to the exposed
 144 nature of those structures, extending them also necessitated breaking backward
 145 ABI compatibility with previous libjpeg releases.  Thus, programs that were
 146 built to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is
 147 based on the libjpeg v6b code base.  Although libjpeg v7 and v8 are not
 148 as widely used as v6b, enough programs (including a few Linux distros) made
 149 the switch that there was a demand to emulate the libjpeg v7 and v8 ABIs
 150 in libjpeg-turbo.  It should be noted, however, that this feature was added
 151 primarily so that applications that had already been compiled to use libjpeg
 152 v7+ could take advantage of accelerated baseline JPEG encoding/decoding
 153 without recompiling.  libjpeg-turbo does not claim to support all of the
 154 libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
 155 cases (see below.)
 156
 157 By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you
 158 can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so
 159 that programs that are built against libjpeg v7 or v8 can be run with
 160 libjpeg-turbo.  The following section describes which libjpeg v7+ features are
 161 supported and which aren't.
 162
 163 ### Support for libjpeg v7 and v8 Features
 164
 165 #### Fully supported
 166
 167 - **libjpeg API: IDCT scaling extensions in decompressor**<br>
 168   libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
 169   1/2, 5/8, 3/4, 7/8, 9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2/1 (only 1/4
 170   and 1/2 are SIMD-accelerated.)
 171
 172 - **libjpeg API: Arithmetic coding**
 173
 174 - **libjpeg API: In-memory source and destination managers**<br>
 175   See notes below.
 176
 177 - **cjpeg: Separate quality settings for luminance and chrominance**<br>
 178   Note that the libpjeg v7+ API was extended to accommodate this feature only
 179   for convenience purposes.  It has always been possible to implement this
 180   feature with libjpeg v6b (see rdswitch.c for an example.)
 181
 182 - **cjpeg: 32-bit BMP support**
 183
 184 - **cjpeg: `-rgb` option**
 185
 186 - **jpegtran: Lossless cropping**
 187
 188 - **jpegtran: `-perfect` option**
 189
 190 - **jpegtran: Forcing width/height when performing lossless crop**
 191
 192 - **rdjpgcom: `-raw` option**
 193
 194 - **rdjpgcom: Locale awareness**
 195
 196
 197 #### Not supported
 198
 199 NOTE:  As of this writing, extensive research has been conducted into the
 200 usefulness of DCT scaling as a means of data reduction and SmartScale as a
 201 means of quality improvement.  Readers are invited to peruse the research at
 202 <http://www.libjpeg-turbo.org/About/SmartScale> and draw their own conclusions,
 203 but it is the general belief of our project that these features have not
 204 demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
 205
 206 - **libjpeg API: DCT scaling in compressor**<br>
 207   `cinfo.scale_num` and `cinfo.scale_denom` are silently ignored.
 208   There is no technical reason why DCT scaling could not be supported when
 209   emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
 210   below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
 211   8/9 would be available, which is of limited usefulness.
 212
 213 - **libjpeg API: SmartScale**<br>
 214   `cinfo.block_size` is silently ignored.
 215   SmartScale is an extension to the JPEG format that allows for DCT block
 216   sizes other than 8x8.  Providing support for this new format would be
 217   feasible (particularly without full acceleration.)  However, until/unless
 218   the format becomes either an official industry standard or, at minimum, an
 219   accepted solution in the community, we are hesitant to implement it, as
 220   there is no sense of whether or how it might change in the future.  It is
 221   our belief that SmartScale has not demonstrated sufficient usefulness as a
 222   lossless format nor as a means of quality enhancement, and thus our primary
 223   interest in providing this feature would be as a means of supporting
 224   additional DCT scaling factors.
 225
 226 - **libjpeg API: Fancy downsampling in compressor**<br>
 227   `cinfo.do_fancy_downsampling` is silently ignored.
 228   This requires the DCT scaling feature, which is not supported.
 229
 230 - **jpegtran: Scaling**<br>
 231   This requires both the DCT scaling and SmartScale features, which are not
 232   supported.
 233
 234 - **Lossless RGB JPEG files**<br>
 235   This requires the SmartScale feature, which is not supported.
 236
 237 ### What About libjpeg v9?
 238
 239 libjpeg v9 introduced yet another field to the JPEG compression structure
 240 (`color_transform`), thus making the ABI backward incompatible with that of
 241 libjpeg v8.  This new field was introduced solely for the purpose of supporting
 242 lossless SmartScale encoding.  Furthermore, there was actually no reason to
 243 extend the API in this manner, as the color transform could have just as easily
 244 been activated by way of a new JPEG colorspace constant, thus preserving
 245 backward ABI compatibility.
 246
 247 Our research (see link above) has shown that lossless SmartScale does not
 248 generally accomplish anything that can't already be accomplished better with
 249 existing, standard lossless formats.  Therefore, at this time it is our belief
 250 that there is not sufficient technical justification for software projects to
 251 upgrade from libjpeg v8 to libjpeg v9, and thus there is not sufficient
 252 technical justification for us to emulate the libjpeg v9 ABI.
 253
 254 In-Memory Source/Destination Managers
 255 -------------------------------------
 256
 257 By default, libjpeg-turbo 1.3 and later includes the `jpeg_mem_src()` and
 258 `jpeg_mem_dest()` functions, even when not emulating the libjpeg v8 API/ABI.
 259 Previously, it was necessary to build libjpeg-turbo from source with libjpeg v8
 260 API/ABI emulation in order to use the in-memory source/destination managers,
 261 but several projects requested that those functions be included when emulating
 262 the libjpeg v6b API/ABI as well.  This allows the use of those functions by
 263 programs that need them, without breaking ABI compatibility for programs that
 264 don't, and it allows those functions to be provided in the "official"
 265 libjpeg-turbo binaries.
 266
 267 Note that, on most Un*x systems, the dynamic linker will not look for a
 268 function in a library until that function is actually used.  Thus, if a program
 269 is built against libjpeg-turbo 1.3+ and uses `jpeg_mem_src()` or
 270 `jpeg_mem_dest()`, that program will not fail if run against an older version
 271 of libjpeg-turbo or against libjpeg v7- until the program actually tries to
 272 call `jpeg_mem_src()` or `jpeg_mem_dest()`.  Such is not the case on Windows.
 273 If a program is built against the libjpeg-turbo 1.3+ DLL and uses
 274 `jpeg_mem_src()` or `jpeg_mem_dest()`, then it must use the libjpeg-turbo 1.3+
 275 DLL at run time.
 276
 277 Both cjpeg and djpeg have been extended to allow testing the in-memory
 278 source/destination manager functions.  See their respective man pages for more
 279 details.
 280
 281
 282 Mathematical Compatibility
 283 ==========================
 284
 285 For the most part, libjpeg-turbo should produce identical output to libjpeg
 286 v6b.  There are two exceptions:
 287
 288 1. When decompressing a JPEG image that uses 4:4:0 chrominance subsampling, the
 289 outputs of libjpeg v6b and libjpeg-turbo can differ because libjpeg-turbo
 290 implements a "fancy" (smooth) 4:4:0 upsampling algorithm and libjpeg did not.
 291
 292 2. When using the floating point DCT/IDCT, the outputs of libjpeg v6b and
 293 libjpeg-turbo can differ for the following reasons:
 294
 295     - The SSE/SSE2 floating point DCT implementation in libjpeg-turbo is ever
 296       so slightly more accurate than the implementation in libjpeg v6b, but not
 297       by any amount perceptible to human vision (generally in the range of 0.01
 298       to 0.08 dB gain in PNSR.)
 299
 300     - When not using the SIMD extensions, libjpeg-turbo uses the more accurate
 301       (and slightly faster) floating point IDCT algorithm introduced in libjpeg
 302       v8a as opposed to the algorithm used in libjpeg v6b.  It should be noted,
 303       however, that this algorithm basically brings the accuracy of the
 304       floating point IDCT in line with the accuracy of the accurate integer
 305       IDCT.  The floating point DCT/IDCT algorithms are mainly a legacy
 306       feature, and they do not produce significantly more accuracy than the
 307       accurate integer algorithms.  (To put numbers on this, the typical
 308       difference in PNSR between the two algorithms is less than 0.10 dB,
 309       whereas changing the quality level by 1 in the upper range of the quality
 310       scale is typically more like a 1.0 dB difference.)
 311
 312     - If the floating point algorithms in libjpeg-turbo are not implemented
 313       using SIMD instructions on a particular platform, then the accuracy of
 314       the floating point DCT/IDCT can depend on the compiler settings.
 315
 316 While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood it is
 317 still using the same algorithms as libjpeg v6b, so there are several specific
 318 cases in which libjpeg-turbo cannot be expected to produce the same output as
 319 libjpeg v8:
 320
 321 - When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8
 322   implements those scaling algorithms differently than libjpeg v6b does, and
 323   libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.
 324
 325 - When using chrominance subsampling, because libjpeg v8 implements this
 326   with its DCT/IDCT scaling algorithms rather than with a separate
 327   downsampling/upsampling algorithm.  In our testing, the subsampled/upsampled
 328   output of libjpeg v8 is less accurate than that of libjpeg v6b for this
 329   reason.
 330
 331 - When decompressing using a scaling factor > 1 and merged (AKA "non-fancy" or
 332   "non-smooth") chrominance upsampling, because libjpeg v8 does not support
 333   merged upsampling with scaling factors > 1.
 334
 335
 336 Performance Pitfalls
 337 ====================
 338
 339 Restart Markers
 340 ---------------
 341
 342 The optimized Huffman decoder in libjpeg-turbo does not handle restart markers
 343 in a way that makes the rest of the libjpeg infrastructure happy, so it is
 344 necessary to use the slow Huffman decoder when decompressing a JPEG image that
 345 has restart markers.  This can cause the decompression performance to drop by
 346 as much as 20%, but the performance will still be much greater than that of
 347 libjpeg.  Many consumer packages, such as Photoshop, use restart markers when
 348 generating JPEG images, so images generated by those programs will experience
 349 this issue.
 350
 351 Fast Integer Forward DCT at High Quality Levels
 352 -----------------------------------------------
 353
 354 The algorithm used by the SIMD-accelerated quantization function cannot produce
 355 correct results whenever the fast integer forward DCT is used along with a JPEG
 356 quality of 98-100.  Thus, libjpeg-turbo must use the non-SIMD quantization
 357 function in those cases.  This causes performance to drop by as much as 40%.
 358 It is therefore strongly advised that you use the accurate integer forward DCT
 359 whenever encoding images with a JPEG quality of 98 or higher.
 360
 361
 362 Memory Debugger Pitfalls
 363 ========================
 364
 365 Valgrind and Memory Sanitizer (MSan) can generate false positives
 366 (specifically, incorrect reports of uninitialized memory accesses) when used
 367 with libjpeg-turbo's SIMD extensions.  It is generally recommended that the
 368 SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0`
 369 to `cmake` when configuring the build or by setting the environment variable
 370 `JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind,
 371 MSan, or other memory debuggers.