image_pack 0.2.0

data/ext/image_pack/vendor/mozjpeg/LICENSE.md

@@ -0,0 +1,132 @@
+libjpeg-turbo Licenses
+======================
+
+libjpeg-turbo is covered by three compatible BSD-style open source licenses:
+
+- The IJG (Independent JPEG Group) License, which is listed in
+  [README.ijg](README.ijg)
+
+  This license applies to the libjpeg API library and associated programs
+  (any code inherited from libjpeg, and any modifications to that code.)
+
+- The Modified (3-clause) BSD License, which is listed below
+
+  This license covers the TurboJPEG API library and associated programs, as
+  well as the build system.
+
+- The [zlib License](https://opensource.org/licenses/Zlib)
+
+  This license is a subset of the other two, and it covers the libjpeg-turbo
+  SIMD extensions.
+
+
+Complying with the libjpeg-turbo Licenses
+=========================================
+
+This section provides a roll-up of the libjpeg-turbo licensing terms, to the
+best of our understanding.
+
+1.  If you are distributing a modified version of the libjpeg-turbo source,
+    then:
+
+    1.  You cannot alter or remove any existing copyright or license notices
+        from the source.
+
+        **Origin**
+        - Clause 1 of the IJG License
+        - Clause 1 of the Modified BSD License
+        - Clauses 1 and 3 of the zlib License
+
+    2.  You must add your own copyright notice to the header of each source
+        file you modified, so others can tell that you modified that file (if
+        there is not an existing copyright header in that file, then you can
+        simply add a notice stating that you modified the file.)
+
+        **Origin**
+        - Clause 1 of the IJG License
+        - Clause 2 of the zlib License
+
+    3.  You must include the IJG README file, and you must not alter any of the
+        copyright or license text in that file.
+
+        **Origin**
+        - Clause 1 of the IJG License
+
+2.  If you are distributing only libjpeg-turbo binaries without the source, or
+    if you are distributing an application that statically links with
+    libjpeg-turbo, then:
+
+    1.  Your product documentation must include a message stating:
+
+        This software is based in part on the work of the Independent JPEG
+        Group.
+
+        **Origin**
+        - Clause 2 of the IJG license
+
+    2.  If your binary distribution includes or uses the TurboJPEG API, then
+        your product documentation must include the text of the Modified BSD
+        License (see below.)
+
+        **Origin**
+        - Clause 2 of the Modified BSD License
+
+3.  You cannot use the name of the IJG or The libjpeg-turbo Project or the
+    contributors thereof in advertising, publicity, etc.
+
+    **Origin**
+    - IJG License
+    - Clause 3 of the Modified BSD License
+
+4.  The IJG and The libjpeg-turbo Project do not warrant libjpeg-turbo to be
+    free of defects, nor do we accept any liability for undesirable
+    consequences resulting from your use of the software.
+
+    **Origin**
+    - IJG License
+    - Modified BSD License
+    - zlib License
+
+
+The Modified (3-clause) BSD License
+===================================
+
+Copyright (C)2009-2023 D. R. Commander.  All Rights Reserved.<br>
+Copyright (C)2015 Viktor Szathmáry.  All Rights Reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+- Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+- Redistributions in binary form must reproduce the above copyright notice,
+  this list of conditions and the following disclaimer in the documentation
+  and/or other materials provided with the distribution.
+- Neither the name of the libjpeg-turbo Project nor the names of its
+  contributors may be used to endorse or promote products derived from this
+  software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS",
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
+LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
+
+
+Why Three Licenses?
+===================
+
+The zlib License could have been used instead of the Modified (3-clause) BSD
+License, and since the IJG License effectively subsumes the distribution
+conditions of the zlib License, this would have effectively placed
+libjpeg-turbo binary distributions under the IJG License.  However, the IJG
+License specifically refers to the Independent JPEG Group and does not extend
+attribution and endorsement protections to other entities.  Thus, it was
+desirable to choose a license that granted us the same protections for new code
+that were granted to the IJG for code derived from their software.

data/ext/image_pack/vendor/mozjpeg/README-mozilla.txt

@@ -0,0 +1,194 @@
+Mozilla JPEG Encoder Project
+============================
+
+mozjpeg is a fork of libjpeg-turbo that aims to speed up load times of web
+pages by reducing the size (and, by extension, the transmission time) of JPEG
+files.  It accomplishes this by enabling optimized Huffman trees and
+progressive entropy coding by default in the JPEG compressor, as well as
+splitting the spectrum of DCT coefficients into separate scans and using
+Trellis quantisation.
+
+Although it is based on libjpeg-turbo, mozjpeg is not intended to be a
+general-purpose or high-performance JPEG library.  Its performance is highly
+"asymmetric".  That is, the JPEG files it generates require much more time to
+compress than to decompress.  When the default settings are used, mozjpeg is
+considerably slower than libjpeg-turbo or even libjpeg at compressing images.
+Thus, it is not generally suitable for real-time compression.  It is best used
+as part of a web encoding workflow.
+
+
+libjpeg API Extensibility Framework
+===================================
+
+mozjpeg's implementation of the libjpeg API includes an extensibility framework
+that allows new features to be added without modifying the transparent libjpeg
+compress/decompress structures (which would break backward ABI compatibility.)
+Extension parameters are placed into the opaque jpeg_comp_master structure, and
+a set of accessor functions and globally unique tokens allows for
+getting/setting those parameters without directly accessing the structure.
+
+Currently, only the accessor functions necessary to support the mozjpeg
+extensions are implemented, but the framework can be easily extended in the
+future to accommodate additional simple parameter types, complex or
+multi-valued parameters, or decompressor extensions.
+
+
+The currently-implemented accessor functions are as follows:
+
+boolean jpeg_c_bool_param_supported (j_compress_ptr cinfo,
+                                     J_BOOLEAN_PARAM param)
+        Returns TRUE if the given boolean extension parameter is supported by
+        this implementation of the libjpeg API, or FALSE otherwise.
+
+void jpeg_c_set_bool_param (j_compress_ptr cinfo,
+                            J_BOOLEAN_PARAM param, boolean value);
+        Set the given boolean extension parameter to the given value (TRUE or
+        FALSE.)
+
+boolean jpeg_c_get_bool_param (j_compress_ptr cinfo, J_BOOLEAN_PARAM param)
+        Get the value of the given boolean extension parameter (TRUE or FALSE.)
+
+boolean jpeg_c_float_param_supported (j_compress_ptr cinfo,
+                                      J_FLOAT_PARAM param)
+        Returns TRUE if the given floating point extension parameter is
+        supported by this implementation of the libjpeg API, or FALSE
+        otherwise.
+
+void jpeg_c_set_float_param (j_compress_ptr cinfo, J_FLOAT_PARAM param,
+                             float value)
+        Set the given floating point extension parameter to the given value.
+
+float jpeg_c_get_float_param (j_compress_ptr cinfo, J_FLOAT_PARAM param);
+        Get the value of the given floating point extension parameter.
+
+boolean jpeg_c_int_param_supported (j_compress_ptr cinfo,
+                                    J_INT_PARAM param)
+        Returns TRUE if the given integer extension parameter is supported by
+        this implementation of the libjpeg API, or FALSE otherwise.
+
+void jpeg_c_set_int_param (j_compress_ptr cinfo, J_INT_PARAM param,
+                          int value)
+        Set the given integer extension parameter to the given value.
+
+int jpeg_c_get_int_param (j_compress_ptr cinfo, J_INT_PARAM param)
+        Get the value of the given integer extension parameter.
+
+
+Boolean Extension Parameters Supported by mozjpeg
+-------------------------------------------------
+
+* JBOOLEAN_OPTIMIZE_SCANS (default: TRUE)
+  Specifies whether scan parameters should be optimized.  Parameter
+  optimization is done as in jpgcrush. jpeg_simple_progression() should be called
+  after setting JBOOLEAN_OPTIMIZE_SCANS.
+  When disabling JBOOLEAN_OPTIMIZE_SCANS, cinfo.scan_info should additionally be
+  set to NULL to disable use of the progressive coding mode, if so desired.
+
+* JBOOLEAN_TRELLIS_QUANT (default: TRUE)
+  Specifies whether to apply trellis quantization.  For each 8x8 block, trellis
+  quantization determines the best tradeoff between rate and distortion.
+
+* JBOOLEAN_TRELLIS_QUANT_DC (default: TRUE)
+  Specifies whether to apply trellis quantization to DC coefficients.
+
+* JBOOLEAN_TRELLIS_EOB_OPT (default: FALSE)
+  Specifies whether to optimize runs of zero blocks in trellis quantization.
+  This is applicable only when JBOOLEAN_USE_SCANS_IN_TRELLIS is enabled.
+
+* JBOOLEAN_USE_LAMBDA_WEIGHT_TBL currently has no effect.
+
+* JBOOLEAN_USE_SCANS_IN_TRELLIS (default: FALSE)
+  Specifies whether multiple scans should be considered during trellis
+  quantization.
+
+* JBOOLEAN_TRELLIS_Q_OPT (default: FALSE)
+  Specifies whether to optimize the quantization table after trellis
+  quantization.  If enabled, then a revised quantization table is derived so
+  as to minimize the reconstruction error of the quantized coefficients.
+
+* JBOOLEAN_OVERSHOOT_DERINGING (default: TRUE)
+  Specifies whether overshooting is applied to samples with extreme values
+  (for example, 0 and 255 for 8-bit samples).  Overshooting may reduce ringing
+  artifacts from compression, in particular in areas where black text appears
+  on a white background.
+
+
+Floating Point Extension Parameters Supported by mozjpeg
+--------------------------------------------------------
+
+* JFLOAT_LAMBDA_LOG_SCALE1 (default: 14.75)
+  JFLOAT_LAMBDA_LOG_SCALE2 (default: 16.5)
+  These parameters specify the lambda value used in trellis quantization.  The
+  lambda value (Lagrange multiplier) in the
+    R + lambda * D
+  equation is derived from
+    lambda = 2^s1 / ((2^s2 + n) * q^2),
+  where s1 and s2 are the values of JFLOAT_LAMBDA_LOG_SCALE1 and
+  JFLOAT_LAMBDA_LOG_SCALE2, n is the average of the squared unquantized AC
+  coefficients within the current 8x8 block, and q is the quantization table
+  entry associated with the current coefficient frequency.  If
+  JFLOAT_LAMBDA_LOG_SCALE2 is 0, then an alternate form is used that does not
+  rely on n:
+    lambda = 2^(s1-12) / q^2.
+
+* JFLOAT_TRELLIS_DELTA_DC_WEIGHT (default: 0.0)
+  This parameter controls how distortion is calculated in DC trellis quantization
+  (enabled with JBOOLEAN_TRELLIS_QUANT_DC). It defines weighting between distortion
+  of the DC coefficient and distortion of the vertical gradient of DC coefficients.
+  The value of the parameter corresponds to the weight applied to the distortion
+  of the vertical gradient.
+
+
+Integer Extension Parameters Supported by mozjpeg
+-------------------------------------------------
+
+* JINT_COMPRESS_PROFILE (default: JCP_MAX_COMPRESSION)
+  Select a compression profile, which is a set of default parameters that will
+  achieve a desired compression goal.  This parameter controls the behavior of
+  the jpeg_set_defaults() function.  Thus, setting JINT_COMPRESS_PROFILE does
+  not cause any other parameters to be modified until jpeg_set_defaults() is
+  called.  The following compression profiles are supported:
+
+  - JCP_MAX_COMPRESSION (default)
+    Increase the compression ratio as much as possible, at the expense of
+    increased encoding time.  This enables progressive entropy coding and all
+    mozjpeg extensions.
+
+  - JCP_FASTEST
+    Use the libjpeg[-turbo] defaults (baseline entropy coding, no mozjpeg
+    extensions enabled.)
+
+* JINT_TRELLIS_FREQ_SPLIT (default: 8)
+  Specifies the position within the zigzag scan at which the split between
+  scans is positioned in the context of trellis quantization.
+  JBOOLEAN_USE_SCANS_IN_TRELLIS must be enabled for this parameter to have any
+  effect.
+
+* JINT_TRELLIS_NUM_LOOPS (default: 1)
+  Specifies the number of trellis quantization passes.  Huffman tables are
+  updated between passes.
+
+* JINT_BASE_QUANT_TBL_IDX (default: 3)
+  Specifies which quantization table set to use.  The following options are
+  available:
+  0 = Tables from JPEG Annex K
+  1 = Flat table
+  2 = Table tuned for MSSIM on Kodak image set
+  3 = Table from http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=20333&p=98008#p98008
+  4 = Table tuned for PSNR-HVS-M on Kodak image set
+  5 = Table from:  Relevance of Human Vision to JPEG-DCT Compression
+      (1992) Klein, Silverstein and Carney
+  6 = Table from:  DCTune Perceptual Optimization of Compressed Dental X-Rays
+      (1997) Watson, Taylor, Borthwick
+  7 = Table from:  A Visual Detection Model for DCT Coefficient Quantization
+      (12/9/93) Ahumada, Watson, Peterson
+  8 = Table from:  An Improved Detection Model for DCT Coefficient Quantization
+      (1993) Peterson, Ahumada and Watson
+
+* JINT_DC_SCAN_OPT_MODE (default: 0)
+  Specifies the DC scan optimization mode.  The following options are
+  available:
+  0 = One scan for all components
+  1 = One scan per component
+  2 = Optimize between one scan for all components and one scan for the first
+      component plus one scan for the remaining components

data/ext/image_pack/vendor/mozjpeg/README-turbo.txt

@@ -0,0 +1,346 @@
+Background
+==========
+
+libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
+AVX2, NEON, AltiVec) to accelerate baseline JPEG compression and decompression
+on x86, x86-64, ARM, and PowerPC systems, as well as progressive JPEG
+compression on x86 and x86-64 systems.  On such systems, libjpeg-turbo is
+generally 2-6x as fast as libjpeg, all else being equal.  On other types of
+systems, libjpeg-turbo can still outperform libjpeg by a significant amount, by
+virtue of its highly-optimized Huffman coding routines.  In many cases, the
+performance of libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.
+
+libjpeg-turbo implements both the traditional libjpeg API as well as the less
+powerful but more straightforward TurboJPEG API.  libjpeg-turbo also features
+colorspace extensions that allow it to compress from/decompress to 32-bit and
+big-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Java
+interface.
+
+libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated
+derivative of libjpeg v6b developed by Miyasaka Masaru.  The TigerVNC and
+VirtualGL projects made numerous enhancements to the codec in 2009, and in
+early 2010, libjpeg-turbo spun off into an independent project, with the goal
+of making high-speed JPEG compression/decompression technology available to a
+broader range of users and developers.
+
+
+License
+=======
+
+libjpeg-turbo is covered by three compatible BSD-style open source licenses.
+Refer to [LICENSE.md](LICENSE.md) for a roll-up of license terms.
+
+
+Building libjpeg-turbo
+======================
+
+Refer to [BUILDING.md](BUILDING.md) for complete instructions.
+
+
+Using libjpeg-turbo
+===================
+
+libjpeg-turbo includes two APIs that can be used to compress and decompress
+JPEG images:
+
+- **TurboJPEG API**<br>
+  This API provides an easy-to-use interface for compressing and decompressing
+  JPEG images in memory.  It also provides some functionality that would not be
+  straightforward to achieve using the underlying libjpeg API, such as
+  generating planar YUV images and performing multiple simultaneous lossless
+  transforms on an image.  The Java interface for libjpeg-turbo is written on
+  top of the TurboJPEG API.  The TurboJPEG API is recommended for first-time
+  users of libjpeg-turbo.  Refer to [tjexample.c](tjexample.c) and
+  [TJExample.java](java/TJExample.java) for examples of its usage and to
+  <http://libjpeg-turbo.org/Documentation/Documentation> for API documentation.
+
+- **libjpeg API**<br>
+  This is the de facto industry-standard API for compressing and decompressing
+  JPEG images.  It is more difficult to use than the TurboJPEG API but also
+  more powerful.  The libjpeg API implementation in libjpeg-turbo is both
+  API/ABI-compatible and mathematically compatible with libjpeg v6b.  It can
+  also optionally be configured to be API/ABI-compatible with libjpeg v7 and v8
+  (see below.)  Refer to [cjpeg.c](cjpeg.c) and [djpeg.c](djpeg.c) for examples
+  of its usage and to [libjpeg.txt](libjpeg.txt) for API documentation.
+
+There is no significant performance advantage to either API when both are used
+to perform similar operations.
+
+Colorspace Extensions
+---------------------
+
+libjpeg-turbo includes extensions that allow JPEG images to be compressed
+directly from (and decompressed directly to) buffers that use BGR, BGRX,
+RGBX, XBGR, and XRGB pixel ordering.  This is implemented with ten new
+colorspace constants:
+
+    JCS_EXT_RGB   /* red/green/blue */
+    JCS_EXT_RGBX  /* red/green/blue/x */
+    JCS_EXT_BGR   /* blue/green/red */
+    JCS_EXT_BGRX  /* blue/green/red/x */
+    JCS_EXT_XBGR  /* x/blue/green/red */
+    JCS_EXT_XRGB  /* x/red/green/blue */
+    JCS_EXT_RGBA  /* red/green/blue/alpha */
+    JCS_EXT_BGRA  /* blue/green/red/alpha */
+    JCS_EXT_ABGR  /* alpha/blue/green/red */
+    JCS_EXT_ARGB  /* alpha/red/green/blue */
+
+Setting `cinfo.in_color_space` (compression) or `cinfo.out_color_space`
+(decompression) to one of these values will cause libjpeg-turbo to read the
+red, green, and blue values from (or write them to) the appropriate position in
+the pixel when compressing from/decompressing to an RGB buffer.
+
+Your application can check for the existence of these extensions at compile
+time with:
+
+    #ifdef JCS_EXTENSIONS
+
+At run time, attempting to use these extensions with a libjpeg implementation
+that does not support them will result in a "Bogus input colorspace" error.
+Applications can trap this error in order to test whether run-time support is
+available for the colorspace extensions.
+
+When using the RGBX, BGRX, XBGR, and XRGB colorspaces during decompression, the
+X byte is undefined, and in order to ensure the best performance, libjpeg-turbo
+can set that byte to whatever value it wishes.  If an application expects the X
+byte to be used as an alpha channel, then it should specify `JCS_EXT_RGBA`,
+`JCS_EXT_BGRA`, `JCS_EXT_ABGR`, or `JCS_EXT_ARGB`.  When these colorspace
+constants are used, the X byte is guaranteed to be 0xFF, which is interpreted
+as opaque.
+
+Your application can check for the existence of the alpha channel colorspace
+extensions at compile time with:
+
+    #ifdef JCS_ALPHA_EXTENSIONS
+
+[jcstest.c](jcstest.c), located in the libjpeg-turbo source tree, demonstrates
+how to check for the existence of the colorspace extensions at compile time and
+run time.
+
+libjpeg v7 and v8 API/ABI Emulation
+-----------------------------------
+
+With libjpeg v7 and v8, new features were added that necessitated extending the
+compression and decompression structures.  Unfortunately, due to the exposed
+nature of those structures, extending them also necessitated breaking backward
+ABI compatibility with previous libjpeg releases.  Thus, programs that were
+built to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is
+based on the libjpeg v6b code base.  Although libjpeg v7 and v8 are not
+as widely used as v6b, enough programs (including a few Linux distros) made
+the switch that there was a demand to emulate the libjpeg v7 and v8 ABIs
+in libjpeg-turbo.  It should be noted, however, that this feature was added
+primarily so that applications that had already been compiled to use libjpeg
+v7+ could take advantage of accelerated baseline JPEG encoding/decoding
+without recompiling.  libjpeg-turbo does not claim to support all of the
+libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
+cases (see below.)
+
+By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, or
+an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build a
+version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that
+programs that are built against libjpeg v7 or v8 can be run with libjpeg-turbo.
+The following section describes which libjpeg v7+ features are supported and
+which aren't.
+
+### Support for libjpeg v7 and v8 Features
+
+#### Fully supported
+
+- **libjpeg: IDCT scaling extensions in decompressor**<br>
+  libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
+  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
+  and 1/2 are SIMD-accelerated.)
+
+- **libjpeg: Arithmetic coding**
+
+- **libjpeg: In-memory source and destination managers**<br>
+  See notes below.
+
+- **cjpeg: Separate quality settings for luminance and chrominance**<br>
+  Note that the libpjeg v7+ API was extended to accommodate this feature only
+  for convenience purposes.  It has always been possible to implement this
+  feature with libjpeg v6b (see rdswitch.c for an example.)
+
+- **cjpeg: 32-bit BMP support**
+
+- **cjpeg: `-rgb` option**
+
+- **jpegtran: Lossless cropping**
+
+- **jpegtran: `-perfect` option**
+
+- **jpegtran: Forcing width/height when performing lossless crop**
+
+- **rdjpgcom: `-raw` option**
+
+- **rdjpgcom: Locale awareness**
+
+
+#### Not supported
+
+NOTE:  As of this writing, extensive research has been conducted into the
+usefulness of DCT scaling as a means of data reduction and SmartScale as a
+means of quality improvement.  The reader is invited to peruse the research at
+<http://www.libjpeg-turbo.org/About/SmartScale> and draw his/her own conclusions,
+but it is the general belief of our project that these features have not
+demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
+
+- **libjpeg: DCT scaling in compressor**<br>
+  `cinfo.scale_num` and `cinfo.scale_denom` are silently ignored.
+  There is no technical reason why DCT scaling could not be supported when
+  emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
+  below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
+  8/9 would be available, which is of limited usefulness.
+
+- **libjpeg: SmartScale**<br>
+  `cinfo.block_size` is silently ignored.
+  SmartScale is an extension to the JPEG format that allows for DCT block
+  sizes other than 8x8.  Providing support for this new format would be
+  feasible (particularly without full acceleration.)  However, until/unless
+  the format becomes either an official industry standard or, at minimum, an
+  accepted solution in the community, we are hesitant to implement it, as
+  there is no sense of whether or how it might change in the future.  It is
+  our belief that SmartScale has not demonstrated sufficient usefulness as a
+  lossless format nor as a means of quality enhancement, and thus our primary
+  interest in providing this feature would be as a means of supporting
+  additional DCT scaling factors.
+
+- **libjpeg: Fancy downsampling in compressor**<br>
+  `cinfo.do_fancy_downsampling` is silently ignored.
+  This requires the DCT scaling feature, which is not supported.
+
+- **jpegtran: Scaling**<br>
+  This requires both the DCT scaling and SmartScale features, which are not
+  supported.
+
+- **Lossless RGB JPEG files**<br>
+  This requires the SmartScale feature, which is not supported.
+
+### What About libjpeg v9?
+
+libjpeg v9 introduced yet another field to the JPEG compression structure
+(`color_transform`), thus making the ABI backward incompatible with that of
+libjpeg v8.  This new field was introduced solely for the purpose of supporting
+lossless SmartScale encoding.  Furthermore, there was actually no reason to
+extend the API in this manner, as the color transform could have just as easily
+been activated by way of a new JPEG colorspace constant, thus preserving
+backward ABI compatibility.
+
+Our research (see link above) has shown that lossless SmartScale does not
+generally accomplish anything that can't already be accomplished better with
+existing, standard lossless formats.  Therefore, at this time it is our belief
+that there is not sufficient technical justification for software projects to
+upgrade from libjpeg v8 to libjpeg v9, and thus there is not sufficient
+technical justification for us to emulate the libjpeg v9 ABI.
+
+In-Memory Source/Destination Managers
+-------------------------------------
+
+By default, libjpeg-turbo 1.3 and later includes the `jpeg_mem_src()` and
+`jpeg_mem_dest()` functions, even when not emulating the libjpeg v8 API/ABI.
+Previously, it was necessary to build libjpeg-turbo from source with libjpeg v8
+API/ABI emulation in order to use the in-memory source/destination managers,
+but several projects requested that those functions be included when emulating
+the libjpeg v6b API/ABI as well.  This allows the use of those functions by
+programs that need them, without breaking ABI compatibility for programs that
+don't, and it allows those functions to be provided in the "official"
+libjpeg-turbo binaries.
+
+Those who are concerned about maintaining strict conformance with the libjpeg
+v6b or v7 API can pass an argument of `--without-mem-srcdst` to `configure` or
+an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to building
+libjpeg-turbo.  This will restore the pre-1.3 behavior, in which
+`jpeg_mem_src()` and `jpeg_mem_dest()` are only included when emulating the
+libjpeg v8 API/ABI.
+
+On Un*x systems, including the in-memory source/destination managers changes
+the dynamic library version from 62.1.0 to 62.2.0 if using libjpeg v6b API/ABI
+emulation and from 7.1.0 to 7.2.0 if using libjpeg v7 API/ABI emulation.
+
+Note that, on most Un*x systems, the dynamic linker will not look for a
+function in a library until that function is actually used.  Thus, if a program
+is built against libjpeg-turbo 1.3+ and uses `jpeg_mem_src()` or
+`jpeg_mem_dest()`, that program will not fail if run against an older version
+of libjpeg-turbo or against libjpeg v7- until the program actually tries to
+call `jpeg_mem_src()` or `jpeg_mem_dest()`.  Such is not the case on Windows.
+If a program is built against the libjpeg-turbo 1.3+ DLL and uses
+`jpeg_mem_src()` or `jpeg_mem_dest()`, then it must use the libjpeg-turbo 1.3+
+DLL at run time.
+
+Both cjpeg and djpeg have been extended to allow testing the in-memory
+source/destination manager functions.  See their respective man pages for more
+details.
+
+
+Mathematical Compatibility
+==========================
+
+For the most part, libjpeg-turbo should produce identical output to libjpeg
+v6b.  The one exception to this is when using the floating point DCT/IDCT, in
+which case the outputs of libjpeg v6b and libjpeg-turbo can differ for the
+following reasons:
+
+- The SSE/SSE2 floating point DCT implementation in libjpeg-turbo is ever so
+  slightly more accurate than the implementation in libjpeg v6b, but not by
+  any amount perceptible to human vision (generally in the range of 0.01 to
+  0.08 dB gain in PNSR.)
+
+- When not using the SIMD extensions, libjpeg-turbo uses the more accurate
+  (and slightly faster) floating point IDCT algorithm introduced in libjpeg
+  v8a as opposed to the algorithm used in libjpeg v6b.  It should be noted,
+  however, that this algorithm basically brings the accuracy of the floating
+  point IDCT in line with the accuracy of the slow integer IDCT.  The floating
+  point DCT/IDCT algorithms are mainly a legacy feature, and they do not
+  produce significantly more accuracy than the slow integer algorithms (to put
+  numbers on this, the typical difference in PNSR between the two algorithms
+  is less than 0.10 dB, whereas changing the quality level by 1 in the upper
+  range of the quality scale is typically more like a 1.0 dB difference.)
+
+- If the floating point algorithms in libjpeg-turbo are not implemented using
+  SIMD instructions on a particular platform, then the accuracy of the
+  floating point DCT/IDCT can depend on the compiler settings.
+
+While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood it is
+still using the same algorithms as libjpeg v6b, so there are several specific
+cases in which libjpeg-turbo cannot be expected to produce the same output as
+libjpeg v8:
+
+- When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8
+  implements those scaling algorithms differently than libjpeg v6b does, and
+  libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.
+
+- When using chrominance subsampling, because libjpeg v8 implements this
+  with its DCT/IDCT scaling algorithms rather than with a separate
+  downsampling/upsampling algorithm.  In our testing, the subsampled/upsampled
+  output of libjpeg v8 is less accurate than that of libjpeg v6b for this
+  reason.
+
+- When decompressing using a scaling factor > 1 and merged (AKA "non-fancy" or
+  "non-smooth") chrominance upsampling, because libjpeg v8 does not support
+  merged upsampling with scaling factors > 1.
+
+
+Performance Pitfalls
+====================
+
+Restart Markers
+---------------
+
+The optimized Huffman decoder in libjpeg-turbo does not handle restart markers
+in a way that makes the rest of the libjpeg infrastructure happy, so it is
+necessary to use the slow Huffman decoder when decompressing a JPEG image that
+has restart markers.  This can cause the decompression performance to drop by
+as much as 20%, but the performance will still be much greater than that of
+libjpeg.  Many consumer packages, such as PhotoShop, use restart markers when
+generating JPEG images, so images generated by those programs will experience
+this issue.
+
+Fast Integer Forward DCT at High Quality Levels
+-----------------------------------------------
+
+The algorithm used by the SIMD-accelerated quantization function cannot produce
+correct results whenever the fast integer forward DCT is used along with a JPEG
+quality of 98-100.  Thus, libjpeg-turbo must use the non-SIMD quantization
+function in those cases.  This causes performance to drop by as much as 40%.
+It is therefore strongly advised that you use the slow integer forward DCT
+whenever encoding images with a JPEG quality of 98 or higher.