1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/media/libjpeg/README-turbo.txt Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,475 @@
1.4 +*******************************************************************************
1.5 +** Background
1.6 +*******************************************************************************
1.7 +
1.8 +libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
1.9 +NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64,
1.10 +and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as
1.11 +libjpeg, all else being equal. On other types of systems, libjpeg-turbo can
1.12 +still outperform libjpeg by a significant amount, by virtue of its
1.13 +highly-optimized Huffman coding routines. In many cases, the performance of
1.14 +libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.
1.15 +
1.16 +libjpeg-turbo implements both the traditional libjpeg API as well as the less
1.17 +powerful but more straightforward TurboJPEG API. libjpeg-turbo also features
1.18 +colorspace extensions that allow it to compress from/decompress to 32-bit and
1.19 +big-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Java
1.20 +interface.
1.21 +
1.22 +libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated
1.23 +derivative of libjpeg v6b developed by Miyasaka Masaru. The TigerVNC and
1.24 +VirtualGL projects made numerous enhancements to the codec in 2009, and in
1.25 +early 2010, libjpeg-turbo spun off into an independent project, with the goal
1.26 +of making high-speed JPEG compression/decompression technology available to a
1.27 +broader range of users and developers.
1.28 +
1.29 +
1.30 +*******************************************************************************
1.31 +** License
1.32 +*******************************************************************************
1.33 +
1.34 +Most of libjpeg-turbo inherits the non-restrictive, BSD-style license used by
1.35 +libjpeg (see README.) The TurboJPEG wrapper (both C and Java versions) and
1.36 +associated test programs bear a similar license, which is reproduced below:
1.37 +
1.38 +Redistribution and use in source and binary forms, with or without
1.39 +modification, are permitted provided that the following conditions are met:
1.40 +
1.41 +- Redistributions of source code must retain the above copyright notice,
1.42 + this list of conditions and the following disclaimer.
1.43 +- Redistributions in binary form must reproduce the above copyright notice,
1.44 + this list of conditions and the following disclaimer in the documentation
1.45 + and/or other materials provided with the distribution.
1.46 +- Neither the name of the libjpeg-turbo Project nor the names of its
1.47 + contributors may be used to endorse or promote products derived from this
1.48 + software without specific prior written permission.
1.49 +
1.50 +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS",
1.51 +AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
1.52 +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
1.53 +ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
1.54 +LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
1.55 +CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
1.56 +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
1.57 +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
1.58 +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
1.59 +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
1.60 +POSSIBILITY OF SUCH DAMAGE.
1.61 +
1.62 +
1.63 +*******************************************************************************
1.64 +** Using libjpeg-turbo
1.65 +*******************************************************************************
1.66 +
1.67 +libjpeg-turbo includes two APIs that can be used to compress and decompress
1.68 +JPEG images:
1.69 +
1.70 + TurboJPEG API: This API provides an easy-to-use interface for compressing
1.71 + and decompressing JPEG images in memory. It also provides some functionality
1.72 + that would not be straightforward to achieve using the underlying libjpeg
1.73 + API, such as generating planar YUV images and performing multiple
1.74 + simultaneous lossless transforms on an image. The Java interface for
1.75 + libjpeg-turbo is written on top of the TurboJPEG API.
1.76 +
1.77 + libjpeg API: This is the de facto industry-standard API for compressing and
1.78 + decompressing JPEG images. It is more difficult to use than the TurboJPEG
1.79 + API but also more powerful. The libjpeg API implementation in libjpeg-turbo
1.80 + is both API/ABI-compatible and mathematically compatible with libjpeg v6b.
1.81 + It can also optionally be configured to be API/ABI-compatible with libjpeg v7
1.82 + and v8 (see below.)
1.83 +
1.84 +There is no significant performance advantage to either API when both are used
1.85 +to perform similar operations.
1.86 +
1.87 +======================
1.88 +Installation Directory
1.89 +======================
1.90 +
1.91 +This document assumes that libjpeg-turbo will be installed in the default
1.92 +directory (/opt/libjpeg-turbo on Un*x and Mac systems and
1.93 +c:\libjpeg-turbo[-gcc][64] on Windows systems. If your installation of
1.94 +libjpeg-turbo resides in a different directory, then adjust the instructions
1.95 +accordingly.
1.96 +
1.97 +=============================
1.98 +Replacing libjpeg at Run Time
1.99 +=============================
1.100 +
1.101 +Un*x
1.102 +----
1.103 +
1.104 +If a Un*x application is dynamically linked with libjpeg, then you can replace
1.105 +libjpeg with libjpeg-turbo at run time by manipulating LD_LIBRARY_PATH.
1.106 +For instance:
1.107 +
1.108 + [Using libjpeg]
1.109 + > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
1.110 + real 0m0.392s
1.111 + user 0m0.074s
1.112 + sys 0m0.020s
1.113 +
1.114 + [Using libjpeg-turbo]
1.115 + > export LD_LIBRARY_PATH=/opt/libjpeg-turbo/{lib}:$LD_LIBRARY_PATH
1.116 + > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
1.117 + real 0m0.109s
1.118 + user 0m0.029s
1.119 + sys 0m0.010s
1.120 +
1.121 +({lib} = lib32 or lib64, depending on whether you wish to use the 32-bit or the
1.122 +64-bit version of libjpeg-turbo.)
1.123 +
1.124 +System administrators can also replace the libjpeg symlinks in /usr/lib* with
1.125 +links to the libjpeg-turbo dynamic library located in /opt/libjpeg-turbo/{lib}.
1.126 +This will effectively accelerate every application that uses the libjpeg
1.127 +dynamic library on the system.
1.128 +
1.129 +Windows
1.130 +-------
1.131 +
1.132 +If a Windows application is dynamically linked with libjpeg, then you can
1.133 +replace libjpeg with libjpeg-turbo at run time by backing up the application's
1.134 +copy of jpeg62.dll, jpeg7.dll, or jpeg8.dll (assuming the application has its
1.135 +own local copy of this library) and copying the corresponding DLL from
1.136 +libjpeg-turbo into the application's install directory. The official
1.137 +libjpeg-turbo binary packages only provide jpeg62.dll. If the application uses
1.138 +jpeg7.dll or jpeg8.dll instead, then it will be necessary to build
1.139 +libjpeg-turbo from source (see "libjpeg v7 and v8 API/ABI Emulation" below.)
1.140 +
1.141 +The following information is specific to the official libjpeg-turbo binary
1.142 +packages for Visual C++:
1.143 +
1.144 +-- jpeg62.dll requires the Visual C++ 2008 C run-time DLL (msvcr90.dll).
1.145 +msvcr90.dll ships with more recent versions of Windows, but users of older
1.146 +Windows releases can obtain it from the Visual C++ 2008 Redistributable
1.147 +Package, which is available as a free download from Microsoft's web site.
1.148 +
1.149 +-- Features of the libjpeg API that require passing a C run-time structure,
1.150 +such as a file handle, from an application to the library will probably not
1.151 +work with jpeg62.dll, unless the application is also built to use the Visual
1.152 +C++ 2008 C run-time DLL. In particular, this affects jpeg_stdio_dest() and
1.153 +jpeg_stdio_src().
1.154 +
1.155 +Mac
1.156 +---
1.157 +
1.158 +Mac applications typically embed their own copies of the libjpeg dylib inside
1.159 +the (hidden) application bundle, so it is not possible to globally replace
1.160 +libjpeg on OS X systems. Replacing the application's version of the libjpeg
1.161 +dylib would generally involve copying libjpeg.*.dylib from libjpeg-turbo into
1.162 +the appropriate place in the application bundle and using install_name_tool to
1.163 +repoint the libjpeg-turbo dylib to its new directory. This requires an
1.164 +advanced knowledge of OS X and would not survive an upgrade or a re-install of
1.165 +the application. Thus, it is not recommended for most users.
1.166 +
1.167 +========================================
1.168 +Using libjpeg-turbo in Your Own Programs
1.169 +========================================
1.170 +
1.171 +For the most part, libjpeg-turbo should work identically to libjpeg, so in
1.172 +most cases, an application can be built against libjpeg and then run against
1.173 +libjpeg-turbo. On Un*x systems and Cygwin, you can build against libjpeg-turbo
1.174 +instead of libjpeg by setting
1.175 +
1.176 + CPATH=/opt/libjpeg-turbo/include
1.177 + and
1.178 + LIBRARY_PATH=/opt/libjpeg-turbo/{lib}
1.179 +
1.180 +({lib} = lib32 or lib64, depending on whether you are building a 32-bit or a
1.181 +64-bit application.)
1.182 +
1.183 +If using MinGW, then set
1.184 +
1.185 + CPATH=/c/libjpeg-turbo-gcc[64]/include
1.186 + and
1.187 + LIBRARY_PATH=/c/libjpeg-turbo-gcc[64]/lib
1.188 +
1.189 +Building against libjpeg-turbo is useful, for instance, if you want to build an
1.190 +application that leverages the libjpeg-turbo colorspace extensions (see below.)
1.191 +On Un*x systems, you would still need to manipulate LD_LIBRARY_PATH or create
1.192 +appropriate symlinks to use libjpeg-turbo at run time. On such systems, you
1.193 +can pass -R /opt/libjpeg-turbo/{lib} to the linker to force the use of
1.194 +libjpeg-turbo at run time rather than libjpeg (also useful if you want to
1.195 +leverage the colorspace extensions), or you can link against the libjpeg-turbo
1.196 +static library.
1.197 +
1.198 +To force a Un*x or MinGW application to link against the static version of
1.199 +libjpeg-turbo, you can use the following linker options:
1.200 +
1.201 + -Wl,-Bstatic -ljpeg -Wl,-Bdynamic
1.202 +
1.203 +On OS X, simply add /opt/libjpeg-turbo/lib/libjpeg.a to the linker command
1.204 +line.
1.205 +
1.206 +To build Visual C++ applications using libjpeg-turbo, add
1.207 +c:\libjpeg-turbo[64]\include to the system or user INCLUDE environment
1.208 +variable and c:\libjpeg-turbo[64]\lib to the system or user LIB environment
1.209 +variable, and then link against either jpeg.lib (to use the DLL version of
1.210 +libjpeg-turbo) or jpeg-static.lib (to use the static version of libjpeg-turbo.)
1.211 +
1.212 +=====================
1.213 +Colorspace Extensions
1.214 +=====================
1.215 +
1.216 +libjpeg-turbo includes extensions that allow JPEG images to be compressed
1.217 +directly from (and decompressed directly to) buffers that use BGR, BGRX,
1.218 +RGBX, XBGR, and XRGB pixel ordering. This is implemented with ten new
1.219 +colorspace constants:
1.220 +
1.221 + JCS_EXT_RGB /* red/green/blue */
1.222 + JCS_EXT_RGBX /* red/green/blue/x */
1.223 + JCS_EXT_BGR /* blue/green/red */
1.224 + JCS_EXT_BGRX /* blue/green/red/x */
1.225 + JCS_EXT_XBGR /* x/blue/green/red */
1.226 + JCS_EXT_XRGB /* x/red/green/blue */
1.227 + JCS_EXT_RGBA /* red/green/blue/alpha */
1.228 + JCS_EXT_BGRA /* blue/green/red/alpha */
1.229 + JCS_EXT_ABGR /* alpha/blue/green/red */
1.230 + JCS_EXT_ARGB /* alpha/red/green/blue */
1.231 +
1.232 +Setting cinfo.in_color_space (compression) or cinfo.out_color_space
1.233 +(decompression) to one of these values will cause libjpeg-turbo to read the
1.234 +red, green, and blue values from (or write them to) the appropriate position in
1.235 +the pixel when compressing from/decompressing to an RGB buffer.
1.236 +
1.237 +Your application can check for the existence of these extensions at compile
1.238 +time with:
1.239 +
1.240 + #ifdef JCS_EXTENSIONS
1.241 +
1.242 +At run time, attempting to use these extensions with a libjpeg implementation
1.243 +that does not support them will result in a "Bogus input colorspace" error.
1.244 +Applications can trap this error in order to test whether run-time support is
1.245 +available for the colorspace extensions.
1.246 +
1.247 +When using the RGBX, BGRX, XBGR, and XRGB colorspaces during decompression, the
1.248 +X byte is undefined, and in order to ensure the best performance, libjpeg-turbo
1.249 +can set that byte to whatever value it wishes. If an application expects the X
1.250 +byte to be used as an alpha channel, then it should specify JCS_EXT_RGBA,
1.251 +JCS_EXT_BGRA, JCS_EXT_ABGR, or JCS_EXT_ARGB. When these colorspace constants
1.252 +are used, the X byte is guaranteed to be 0xFF, which is interpreted as opaque.
1.253 +
1.254 +Your application can check for the existence of the alpha channel colorspace
1.255 +extensions at compile time with:
1.256 +
1.257 + #ifdef JCS_ALPHA_EXTENSIONS
1.258 +
1.259 +jcstest.c, located in the libjpeg-turbo source tree, demonstrates how to check
1.260 +for the existence of the colorspace extensions at compile time and run time.
1.261 +
1.262 +===================================
1.263 +libjpeg v7 and v8 API/ABI Emulation
1.264 +===================================
1.265 +
1.266 +With libjpeg v7 and v8, new features were added that necessitated extending the
1.267 +compression and decompression structures. Unfortunately, due to the exposed
1.268 +nature of those structures, extending them also necessitated breaking backward
1.269 +ABI compatibility with previous libjpeg releases. Thus, programs that were
1.270 +built to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is
1.271 +based on the libjpeg v6b code base. Although libjpeg v7 and v8 are still not
1.272 +as widely used as v6b, enough programs (including a few Linux distros) made
1.273 +the switch that there was a demand to emulate the libjpeg v7 and v8 ABIs
1.274 +in libjpeg-turbo. It should be noted, however, that this feature was added
1.275 +primarily so that applications that had already been compiled to use libjpeg
1.276 +v7+ could take advantage of accelerated baseline JPEG encoding/decoding
1.277 +without recompiling. libjpeg-turbo does not claim to support all of the
1.278 +libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
1.279 +cases (see below.)
1.280 +
1.281 +By passing an argument of --with-jpeg7 or --with-jpeg8 to configure, or an
1.282 +argument of -DWITH_JPEG7=1 or -DWITH_JPEG8=1 to cmake, you can build a version
1.283 +of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that programs
1.284 +that are built against libjpeg v7 or v8 can be run with libjpeg-turbo. The
1.285 +following section describes which libjpeg v7+ features are supported and which
1.286 +aren't.
1.287 +
1.288 +Support for libjpeg v7 and v8 Features:
1.289 +---------------------------------------
1.290 +
1.291 +Fully supported:
1.292 +
1.293 +-- libjpeg: IDCT scaling extensions in decompressor
1.294 + libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
1.295 + 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
1.296 + and 1/2 are SIMD-accelerated.)
1.297 +
1.298 +-- libjpeg: arithmetic coding
1.299 +
1.300 +-- libjpeg: In-memory source and destination managers
1.301 + See notes below.
1.302 +
1.303 +-- cjpeg: Separate quality settings for luminance and chrominance
1.304 + Note that the libpjeg v7+ API was extended to accommodate this feature only
1.305 + for convenience purposes. It has always been possible to implement this
1.306 + feature with libjpeg v6b (see rdswitch.c for an example.)
1.307 +
1.308 +-- cjpeg: 32-bit BMP support
1.309 +
1.310 +-- cjpeg: -rgb option
1.311 +
1.312 +-- jpegtran: lossless cropping
1.313 +
1.314 +-- jpegtran: -perfect option
1.315 +
1.316 +-- jpegtran: forcing width/height when performing lossless crop
1.317 +
1.318 +-- rdjpgcom: -raw option
1.319 +
1.320 +-- rdjpgcom: locale awareness
1.321 +
1.322 +
1.323 +Not supported:
1.324 +
1.325 +NOTE: As of this writing, extensive research has been conducted into the
1.326 +usefulness of DCT scaling as a means of data reduction and SmartScale as a
1.327 +means of quality improvement. The reader is invited to peruse the research at
1.328 +http://www.libjpeg-turbo.org/About/SmartScale and draw his/her own conclusions,
1.329 +but it is the general belief of our project that these features have not
1.330 +demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
1.331 +
1.332 +-- libjpeg: DCT scaling in compressor
1.333 + cinfo.scale_num and cinfo.scale_denom are silently ignored.
1.334 + There is no technical reason why DCT scaling could not be supported when
1.335 + emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
1.336 + below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
1.337 + 8/9 would be available, which is of limited usefulness.
1.338 +
1.339 +-- libjpeg: SmartScale
1.340 + cinfo.block_size is silently ignored.
1.341 + SmartScale is an extension to the JPEG format that allows for DCT block
1.342 + sizes other than 8x8. Providing support for this new format would be
1.343 + feasible (particularly without full acceleration.) However, until/unless
1.344 + the format becomes either an official industry standard or, at minimum, an
1.345 + accepted solution in the community, we are hesitant to implement it, as
1.346 + there is no sense of whether or how it might change in the future. It is
1.347 + our belief that SmartScale has not demonstrated sufficient usefulness as a
1.348 + lossless format nor as a means of quality enhancement, and thus, our primary
1.349 + interest in providing this feature would be as a means of supporting
1.350 + additional DCT scaling factors.
1.351 +
1.352 +-- libjpeg: Fancy downsampling in compressor
1.353 + cinfo.do_fancy_downsampling is silently ignored.
1.354 + This requires the DCT scaling feature, which is not supported.
1.355 +
1.356 +-- jpegtran: Scaling
1.357 + This requires both the DCT scaling and SmartScale features, which are not
1.358 + supported.
1.359 +
1.360 +-- Lossless RGB JPEG files
1.361 + This requires the SmartScale feature, which is not supported.
1.362 +
1.363 +What About libjpeg v9?
1.364 +----------------------
1.365 +
1.366 +libjpeg v9 introduced yet another field to the JPEG compression structure
1.367 +(color_transform), thus making the ABI backward incompatible with that of
1.368 +libjpeg v8. This new field was introduced solely for the purpose of supporting
1.369 +lossless SmartScale encoding. Further, there was actually no reason to extend
1.370 +the API in this manner, as the color transform could have just as easily been
1.371 +activated by way of a new JPEG colorspace constant, thus preserving backward
1.372 +ABI compatibility.
1.373 +
1.374 +Our research (see link above) has shown that lossless SmartScale does not
1.375 +generally accomplish anything that can't already be accomplished better with
1.376 +existing, standard lossless formats. Thus, at this time, it is our belief that
1.377 +there is not sufficient technical justification for software to upgrade from
1.378 +libjpeg v8 to libjpeg v9, and therefore, not sufficient technical justification
1.379 +for us to emulate the libjpeg v9 ABI.
1.380 +
1.381 +=====================================
1.382 +In-Memory Source/Destination Managers
1.383 +=====================================
1.384 +
1.385 +By default, libjpeg-turbo 1.3 and later includes the jpeg_mem_src() and
1.386 +jpeg_mem_dest() functions, even when not emulating the libjpeg v8 API/ABI.
1.387 +Previously, it was necessary to build libjpeg-turbo from source with libjpeg v8
1.388 +API/ABI emulation in order to use the in-memory source/destination managers,
1.389 +but several projects requested that those functions be included when emulating
1.390 +the libjpeg v6b API/ABI as well. This allows the use of those functions by
1.391 +programs that need them without breaking ABI compatibility for programs that
1.392 +don't, and it allows those functions to be provided in the "official"
1.393 +libjpeg-turbo binaries.
1.394 +
1.395 +Those who are concerned about maintaining strict conformance with the libjpeg
1.396 +v6b or v7 API can pass an argument of --without-mem-srcdst to configure or
1.397 +an argument of -DWITH_MEM_SRCDST=0 to CMake prior to building libjpeg-turbo.
1.398 +This will restore the pre-1.3 behavior, in which jpeg_mem_src() and
1.399 +jpeg_mem_dest() are only included when emulating the libjpeg v8 API/ABI.
1.400 +
1.401 +On Un*x systems, including the in-memory source/destination managers changes
1.402 +the dynamic library version from 62.0.0 to 62.1.0 if using libjpeg v6b API/ABI
1.403 +emulation and from 7.0.0 to 7.1.0 if using libjpeg v7 API/ABI emulation.
1.404 +
1.405 +Note that, on most Un*x systems, the dynamic linker will not look for a
1.406 +function in a library until that function is actually used. Thus, if a program
1.407 +is built against libjpeg-turbo 1.3+ and uses jpeg_mem_src() or jpeg_mem_dest(),
1.408 +that program will not fail if run against an older version of libjpeg-turbo or
1.409 +against libjpeg v7- until the program actually tries to call jpeg_mem_src() or
1.410 +jpeg_mem_dest(). Such is not the case on Windows. If a program is built
1.411 +against the libjpeg-turbo 1.3+ DLL and uses jpeg_mem_src() or jpeg_mem_dest(),
1.412 +then it must use the libjpeg-turbo 1.3+ DLL at run time.
1.413 +
1.414 +Both cjpeg and djpeg have been extended to allow testing the in-memory
1.415 +source/destination manager functions. See their respective man pages for more
1.416 +details.
1.417 +
1.418 +
1.419 +*******************************************************************************
1.420 +** Mathematical Compatibility
1.421 +*******************************************************************************
1.422 +
1.423 +For the most part, libjpeg-turbo should produce identical output to libjpeg
1.424 +v6b. The one exception to this is when using the floating point DCT/IDCT, in
1.425 +which case the outputs of libjpeg v6b and libjpeg-turbo are not guaranteed to
1.426 +be identical (the accuracy of the floating point DCT/IDCT is constant when
1.427 +using libjpeg-turbo's SIMD extensions, but otherwise, it can depend heavily on
1.428 +the compiler and compiler settings.)
1.429 +
1.430 +While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood, it is
1.431 +still using the same algorithms as libjpeg v6b, so there are several specific
1.432 +cases in which libjpeg-turbo cannot be expected to produce the same output as
1.433 +libjpeg v8:
1.434 +
1.435 +-- When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8
1.436 + implements those scaling algorithms a bit differently than libjpeg v6b does,
1.437 + and libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.
1.438 +
1.439 +-- When using chrominance subsampling, because libjpeg v8 implements this
1.440 + with its DCT/IDCT scaling algorithms rather than with a separate
1.441 + downsampling/upsampling algorithm.
1.442 +
1.443 +-- When using the floating point IDCT, for the reasons stated above and also
1.444 + because the floating point IDCT algorithm was modified in libjpeg v8a to
1.445 + improve accuracy.
1.446 +
1.447 +-- When decompressing using a scaling factor > 1 and merged (AKA "non-fancy" or
1.448 + "non-smooth") chrominance upsampling, because libjpeg v8 does not support
1.449 + merged upsampling with scaling factors > 1.
1.450 +
1.451 +
1.452 +*******************************************************************************
1.453 +** Performance Pitfalls
1.454 +*******************************************************************************
1.455 +
1.456 +===============
1.457 +Restart Markers
1.458 +===============
1.459 +
1.460 +The optimized Huffman decoder in libjpeg-turbo does not handle restart markers
1.461 +in a way that makes the rest of the libjpeg infrastructure happy, so it is
1.462 +necessary to use the slow Huffman decoder when decompressing a JPEG image that
1.463 +has restart markers. This can cause the decompression performance to drop by
1.464 +as much as 20%, but the performance will still be much greater than that of
1.465 +libjpeg. Many consumer packages, such as PhotoShop, use restart markers when
1.466 +generating JPEG images, so images generated by those programs will experience
1.467 +this issue.
1.468 +
1.469 +===============================================
1.470 +Fast Integer Forward DCT at High Quality Levels
1.471 +===============================================
1.472 +
1.473 +The algorithm used by the SIMD-accelerated quantization function cannot produce
1.474 +correct results whenever the fast integer forward DCT is used along with a JPEG
1.475 +quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization
1.476 +function in those cases. This causes performance to drop by as much as 40%.
1.477 +It is therefore strongly advised that you use the slow integer forward DCT
1.478 +whenever encoding images with a JPEG quality of 98 or higher.
