Home | History | Annotate | only in /external/libjpeg-turbo
Up to higher level directory
NameDateSize
.gitattributes22-Oct-2020103
.travis.yml22-Oct-20207.1K
Android.bp22-Oct-20207.5K
appveyor.yml22-Oct-20201.8K
Brewfile22-Oct-202074
BUILDING.md22-Oct-202028.4K
cderror.h22-Oct-20205.4K
cdjpeg.c22-Oct-20203.9K
cdjpeg.h22-Oct-20205.6K
change.log22-Oct-202012.1K
ChangeLog.md22-Oct-202069K
ci/22-Oct-2020
cjpeg.122-Oct-202013.3K
cjpeg.c22-Oct-202022.9K
CMakeLists.txt22-Oct-202055.4K
cmakescripts/22-Oct-2020
cmyk.h22-Oct-20201.6K
coderules.txt22-Oct-20203.4K
djpeg.122-Oct-20209.7K
djpeg.c22-Oct-202027.1K
doc/22-Oct-2020
doxygen-extra.css22-Oct-202026
doxygen.config22-Oct-2020401
example.txt22-Oct-202017.7K
jaricom.c22-Oct-20205K
java/22-Oct-2020
jcapimin.c22-Oct-20209.5K
jcapistd.c22-Oct-20205.8K
jcarith.c22-Oct-202029K
jccoefct.c22-Oct-202016.9K
jccolext.c22-Oct-20204.5K
jccolor.c22-Oct-202023.2K
jcdctmgr.c22-Oct-202022K
jchuff.c22-Oct-202033.6K
jchuff.h22-Oct-20201.5K
jcicc.c22-Oct-20204K
jcinit.c22-Oct-20202.4K
jcmainct.c22-Oct-20205.1K
jcmarker.c22-Oct-202017.1K
jcmaster.c22-Oct-202021.4K
jcomapi.c22-Oct-20203.2K
jconfig.h22-Oct-20202.1K
jconfig.h.in22-Oct-20202.2K
jconfig.txt22-Oct-20204.8K
jconfigint.h22-Oct-20201.5K
jconfigint.h.in22-Oct-2020796
jcparam.c22-Oct-202017.8K
jcphuff.c22-Oct-202032.5K
jcprepct.c22-Oct-202012.7K
jcsample.c22-Oct-202019.7K
jcstest.c22-Oct-20203.8K
jctrans.c22-Oct-202014.6K
jdapimin.c22-Oct-202012.9K
jdapistd.c22-Oct-202023.1K
jdarith.c22-Oct-202024.6K
jdatadst-tj.c22-Oct-20206.6K
jdatadst.c22-Oct-20209.5K
jdatasrc-tj.c22-Oct-20206.7K
jdatasrc.c22-Oct-202010K
jdcoefct.c22-Oct-202024.8K
jdcoefct.h22-Oct-20202.6K
jdcol565.c22-Oct-202012K
jdcolext.c22-Oct-20204.4K
jdcolor.c22-Oct-202028.1K
jdct.h22-Oct-20209.5K
jddctmgr.c22-Oct-202011.1K
jdhuff.c22-Oct-202025.5K
jdhuff.h22-Oct-20209.3K
jdicc.c22-Oct-20205.6K
jdinput.c22-Oct-202014.2K
jdmainct.c22-Oct-202019.3K
jdmainct.h22-Oct-20202.4K
jdmarker.c22-Oct-202041.7K
jdmaster.c22-Oct-202027.3K
jdmaster.h22-Oct-2020788
jdmerge.c22-Oct-202020.6K
jdmrg565.c22-Oct-202011.1K
jdmrgext.c22-Oct-20205.8K
jdphuff.c22-Oct-202021.8K
jdpostct.c22-Oct-202010.7K
jdsample.c22-Oct-202017.6K
jdsample.h22-Oct-20201.7K
jdtrans.c22-Oct-20205.3K
jerror.c22-Oct-20207.7K
jerror.h22-Oct-202014.8K
jfdctflt.c22-Oct-20205.5K
jfdctfst.c22-Oct-20207.6K
jfdctint.c22-Oct-202011.2K
jidctflt.c22-Oct-20208.5K
jidctfst.c22-Oct-202013.2K
jidctint.c22-Oct-2020103.7K
jidctred.c22-Oct-202014.2K
jinclude.h22-Oct-20202.9K
jmemmgr.c22-Oct-202043.7K
jmemnobs.c22-Oct-20202.8K
jmemsys.h22-Oct-20207.6K
jmorecfg.h22-Oct-202014.8K
jpeg_nbits_table.h22-Oct-2020264.1K
jpegcomp.h22-Oct-20201.1K
jpegint.h22-Oct-202015.2K
jpeglib.h22-Oct-202049.1K
jpegtran.122-Oct-20209.6K
jpegtran.c22-Oct-202019.9K
jquant1.c22-Oct-202031.7K
jquant2.c22-Oct-202047.8K
jsimd.h22-Oct-20205.4K
jsimd_none.c22-Oct-20207.6K
jsimddct.h22-Oct-20203K
jstdhuff.c22-Oct-20205.2K
jutils.c22-Oct-20203.7K
jversion.h22-Oct-20201.6K
libjpeg.map.in22-Oct-2020164
libjpeg.txt22-Oct-2020165.9K
LICENSE.md22-Oct-20205.1K
md5/22-Oct-2020
METADATA22-Oct-2020265
MODULE_LICENSE_BSD22-Oct-20200
NOTICE22-Oct-20205.1K
OWNERS22-Oct-202019
rdbmp.c22-Oct-202022.4K
rdcolmap.c22-Oct-20206.9K
rdgif.c22-Oct-20201.3K
rdjpgcom.122-Oct-20201.7K
rdjpgcom.c22-Oct-202014.7K
rdppm.c22-Oct-202024K
rdrle.c22-Oct-202011.4K
rdswitch.c22-Oct-202012.7K
rdtarga.c22-Oct-202015.1K
README.android22-Oct-2020850
README.ijg22-Oct-202013.4K
README.md22-Oct-202016.2K
release/22-Oct-2020
sharedlib/22-Oct-2020
simd/22-Oct-2020
structure.txt22-Oct-202048.6K
testimages/22-Oct-2020
tjbench.c22-Oct-202037.6K
tjbenchtest.in22-Oct-202011.7K
tjbenchtest.java.in22-Oct-202010.1K
tjexample.c22-Oct-202014.8K
tjexampletest.in22-Oct-20208K
tjexampletest.java.in22-Oct-20208.2K
tjunittest.c22-Oct-202028.4K
tjutil.c22-Oct-20202.2K
tjutil.h22-Oct-20201.9K
transupp.c22-Oct-202061.2K
transupp.h22-Oct-20209.8K
turbojpeg-jni.c22-Oct-202045.7K
turbojpeg-mapfile22-Oct-2020989
turbojpeg-mapfile.jni22-Oct-20203.1K
turbojpeg.c22-Oct-202071.2K
turbojpeg.h22-Oct-202072.2K
usage.txt22-Oct-202034.2K
win/22-Oct-2020
wizard.txt22-Oct-202010.2K
wrbmp.c22-Oct-202017.8K
wrgif.c22-Oct-202013.1K
wrjpgcom.122-Oct-20202.6K
wrjpgcom.c22-Oct-202017.5K
wrppm.c22-Oct-202010.8K
wrrle.c22-Oct-20209.2K
wrtarga.c22-Oct-20207.5K

README.android

      1 Any Android specific modifications to upstream libjpeg-turbo (the version
      2 specified in METADATA) should be listed here:
      3 
      4 (1) jconfig.h and jconfigint.h
      5 
      6 These are included upstream as jconfig.h.in and jconfigint.h.in.
      7 We have the option autogenerate these platform/version specific files (using
      8 the libjpeg-turbo build system) or to manually create them.
      9 
     10 Autogenerating these files on linux gets us most of the way, but we've needed
     11 to add some multi-platform flexibility to the INLINE and SIZEOF_SIZE_T macros.
     12 
     13 (2) simd/arm64/jsimd_neon.S
     14 
     15 To support execute-only memory layouts, constants in handwritten assembly have
     16 been moved into a dedicated rodata section.
     17 
     18 There's a pull request upstream for this as well. If that's accepted, this
     19 can be removed as an Android-specific modification.
     20 https://github.com/libjpeg-turbo/libjpeg-turbo/pull/318
     21

README.ijg

      1 libjpeg-turbo note:  This file has been modified by The libjpeg-turbo Project
      2 to include only information relevant to libjpeg-turbo, to wordsmith certain
      3 sections, and to remove impolitic language that existed in the libjpeg v8
      4 README.  It is included only for reference.  Please see README.md for
      5 information specific to libjpeg-turbo.
      6 
      7 
      8 The Independent JPEG Group's JPEG software
      9 ==========================================
     10 
     11 This distribution contains a release of the Independent JPEG Group's free JPEG
     12 software.  You are welcome to redistribute this software and to use it for any
     13 purpose, subject to the conditions under LEGAL ISSUES, below.
     14 
     15 This software is the work of Tom Lane, Guido Vollbeding, Philip Gladstone,
     16 Bill Allombert, Jim Boucher, Lee Crocker, Bob Friesenhahn, Ben Jackson,
     17 Julian Minguillon, Luis Ortiz, George Phillips, Davide Rossi, Ge' Weijers,
     18 and other members of the Independent JPEG Group.
     19 
     20 IJG is not affiliated with the ISO/IEC JTC1/SC29/WG1 standards committee
     21 (also known as JPEG, together with ITU-T SG16).
     22 
     23 
     24 DOCUMENTATION ROADMAP
     25 =====================
     26 
     27 This file contains the following sections:
     28 
     29 OVERVIEW            General description of JPEG and the IJG software.
     30 LEGAL ISSUES        Copyright, lack of warranty, terms of distribution.
     31 REFERENCES          Where to learn more about JPEG.
     32 ARCHIVE LOCATIONS   Where to find newer versions of this software.
     33 FILE FORMAT WARS    Software *not* to get.
     34 TO DO               Plans for future IJG releases.
     35 
     36 Other documentation files in the distribution are:
     37 
     38 User documentation:
     39   usage.txt         Usage instructions for cjpeg, djpeg, jpegtran,
     40                     rdjpgcom, and wrjpgcom.
     41   *.1               Unix-style man pages for programs (same info as usage.txt).
     42   wizard.txt        Advanced usage instructions for JPEG wizards only.
     43   change.log        Version-to-version change highlights.
     44 Programmer and internal documentation:
     45   libjpeg.txt       How to use the JPEG library in your own programs.
     46   example.txt       Sample code for calling the JPEG library.
     47   structure.txt     Overview of the JPEG library's internal structure.
     48   coderules.txt     Coding style rules --- please read if you contribute code.
     49 
     50 Please read at least usage.txt.  Some information can also be found in the JPEG
     51 FAQ (Frequently Asked Questions) article.  See ARCHIVE LOCATIONS below to find
     52 out where to obtain the FAQ article.
     53 
     54 If you want to understand how the JPEG code works, we suggest reading one or
     55 more of the REFERENCES, then looking at the documentation files (in roughly
     56 the order listed) before diving into the code.
     57 
     58 
     59 OVERVIEW
     60 ========
     61 
     62 This package contains C software to implement JPEG image encoding, decoding,
     63 and transcoding.  JPEG (pronounced "jay-peg") is a standardized compression
     64 method for full-color and grayscale images.  JPEG's strong suit is compressing
     65 photographic images or other types of images that have smooth color and
     66 brightness transitions between neighboring pixels.  Images with sharp lines or
     67 other abrupt features may not compress well with JPEG, and a higher JPEG
     68 quality may have to be used to avoid visible compression artifacts with such
     69 images.
     70 
     71 JPEG is lossy, meaning that the output pixels are not necessarily identical to
     72 the input pixels.  However, on photographic content and other "smooth" images,
     73 very good compression ratios can be obtained with no visible compression
     74 artifacts, and extremely high compression ratios are possible if you are
     75 willing to sacrifice image quality (by reducing the "quality" setting in the
     76 compressor.)
     77 
     78 This software implements JPEG baseline, extended-sequential, and progressive
     79 compression processes.  Provision is made for supporting all variants of these
     80 processes, although some uncommon parameter settings aren't implemented yet.
     81 We have made no provision for supporting the hierarchical or lossless
     82 processes defined in the standard.
     83 
     84 We provide a set of library routines for reading and writing JPEG image files,
     85 plus two sample applications "cjpeg" and "djpeg", which use the library to
     86 perform conversion between JPEG and some other popular image file formats.
     87 The library is intended to be reused in other applications.
     88 
     89 In order to support file conversion and viewing software, we have included
     90 considerable functionality beyond the bare JPEG coding/decoding capability;
     91 for example, the color quantization modules are not strictly part of JPEG
     92 decoding, but they are essential for output to colormapped file formats or
     93 colormapped displays.  These extra functions can be compiled out of the
     94 library if not required for a particular application.
     95 
     96 We have also included "jpegtran", a utility for lossless transcoding between
     97 different JPEG processes, and "rdjpgcom" and "wrjpgcom", two simple
     98 applications for inserting and extracting textual comments in JFIF files.
     99 
    100 The emphasis in designing this software has been on achieving portability and
    101 flexibility, while also making it fast enough to be useful.  In particular,
    102 the software is not intended to be read as a tutorial on JPEG.  (See the
    103 REFERENCES section for introductory material.)  Rather, it is intended to
    104 be reliable, portable, industrial-strength code.  We do not claim to have
    105 achieved that goal in every aspect of the software, but we strive for it.
    106 
    107 We welcome the use of this software as a component of commercial products.
    108 No royalty is required, but we do ask for an acknowledgement in product
    109 documentation, as described under LEGAL ISSUES.
    110 
    111 
    112 LEGAL ISSUES
    113 ============
    114 
    115 In plain English:
    116 
    117 1. We don't promise that this software works.  (But if you find any bugs,
    118    please let us know!)
    119 2. You can use this software for whatever you want.  You don't have to pay us.
    120 3. You may not pretend that you wrote this software.  If you use it in a
    121    program, you must acknowledge somewhere in your documentation that
    122    you've used the IJG code.
    123 
    124 In legalese:
    125 
    126 The authors make NO WARRANTY or representation, either express or implied,
    127 with respect to this software, its quality, accuracy, merchantability, or
    128 fitness for a particular purpose.  This software is provided "AS IS", and you,
    129 its user, assume the entire risk as to its quality and accuracy.
    130 
    131 This software is copyright (C) 1991-2016, Thomas G. Lane, Guido Vollbeding.
    132 All Rights Reserved except as specified below.
    133 
    134 Permission is hereby granted to use, copy, modify, and distribute this
    135 software (or portions thereof) for any purpose, without fee, subject to these
    136 conditions:
    137 (1) If any part of the source code for this software is distributed, then this
    138 README file must be included, with this copyright and no-warranty notice
    139 unaltered; and any additions, deletions, or changes to the original files
    140 must be clearly indicated in accompanying documentation.
    141 (2) If only executable code is distributed, then the accompanying
    142 documentation must state that "this software is based in part on the work of
    143 the Independent JPEG Group".
    144 (3) Permission for use of this software is granted only if the user accepts
    145 full responsibility for any undesirable consequences; the authors accept
    146 NO LIABILITY for damages of any kind.
    147 
    148 These conditions apply to any software derived from or based on the IJG code,
    149 not just to the unmodified library.  If you use our work, you ought to
    150 acknowledge us.
    151 
    152 Permission is NOT granted for the use of any IJG author's name or company name
    153 in advertising or publicity relating to this software or products derived from
    154 it.  This software may be referred to only as "the Independent JPEG Group's
    155 software".
    156 
    157 We specifically permit and encourage the use of this software as the basis of
    158 commercial products, provided that all warranty or liability claims are
    159 assumed by the product vendor.
    160 
    161 
    162 The IJG distribution formerly included code to read and write GIF files.
    163 To avoid entanglement with the Unisys LZW patent (now expired), GIF reading
    164 support has been removed altogether, and the GIF writer has been simplified
    165 to produce "uncompressed GIFs".  This technique does not use the LZW
    166 algorithm; the resulting GIF files are larger than usual, but are readable
    167 by all standard GIF decoders.
    168 
    169 We are required to state that
    170     "The Graphics Interchange Format(c) is the Copyright property of
    171     CompuServe Incorporated.  GIF(sm) is a Service Mark property of
    172     CompuServe Incorporated."
    173 
    174 
    175 REFERENCES
    176 ==========
    177 
    178 We recommend reading one or more of these references before trying to
    179 understand the innards of the JPEG software.
    180 
    181 The best short technical introduction to the JPEG compression algorithm is
    182         Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
    183         Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
    184 (Adjacent articles in that issue discuss MPEG motion picture compression,
    185 applications of JPEG, and related topics.)  If you don't have the CACM issue
    186 handy, a PDF file containing a revised version of Wallace's article is
    187 available at http://www.ijg.org/files/Wallace.JPEG.pdf.  The file (actually
    188 a preprint for an article that appeared in IEEE Trans. Consumer Electronics)
    189 omits the sample images that appeared in CACM, but it includes corrections
    190 and some added material.  Note: the Wallace article is copyright ACM and IEEE,
    191 and it may not be used for commercial purposes.
    192 
    193 A somewhat less technical, more leisurely introduction to JPEG can be found in
    194 "The Data Compression Book" by Mark Nelson and Jean-loup Gailly, published by
    195 M&T Books (New York), 2nd ed. 1996, ISBN 1-55851-434-1.  This book provides
    196 good explanations and example C code for a multitude of compression methods
    197 including JPEG.  It is an excellent source if you are comfortable reading C
    198 code but don't know much about data compression in general.  The book's JPEG
    199 sample code is far from industrial-strength, but when you are ready to look
    200 at a full implementation, you've got one here...
    201 
    202 The best currently available description of JPEG is the textbook "JPEG Still
    203 Image Data Compression Standard" by William B. Pennebaker and Joan L.
    204 Mitchell, published by Van Nostrand Reinhold, 1993, ISBN 0-442-01272-1.
    205 Price US$59.95, 638 pp.  The book includes the complete text of the ISO JPEG
    206 standards (DIS 10918-1 and draft DIS 10918-2).
    207 
    208 The original JPEG standard is divided into two parts, Part 1 being the actual
    209 specification, while Part 2 covers compliance testing methods.  Part 1 is
    210 titled "Digital Compression and Coding of Continuous-tone Still Images,
    211 Part 1: Requirements and guidelines" and has document numbers ISO/IEC IS
    212 10918-1, ITU-T T.81.  Part 2 is titled "Digital Compression and Coding of
    213 Continuous-tone Still Images, Part 2: Compliance testing" and has document
    214 numbers ISO/IEC IS 10918-2, ITU-T T.83.
    215 
    216 The JPEG standard does not specify all details of an interchangeable file
    217 format.  For the omitted details, we follow the "JFIF" conventions, revision
    218 1.02.  JFIF version 1 has been adopted as ISO/IEC 10918-5 (05/2013) and
    219 Recommendation ITU-T T.871 (05/2011): Information technology - Digital
    220 compression and coding of continuous-tone still images: JPEG File Interchange
    221 Format (JFIF).  It is available as a free download in PDF file format from
    222 https://www.iso.org/standard/54989.html and http://www.itu.int/rec/T-REC-T.871.
    223 A PDF file of the older JFIF 1.02 specification is available at
    224 http://www.w3.org/Graphics/JPEG/jfif3.pdf.
    225 
    226 The TIFF 6.0 file format specification can be obtained by FTP from
    227 ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.gz.  The JPEG incorporation scheme
    228 found in the TIFF 6.0 spec of 3-June-92 has a number of serious problems.
    229 IJG does not recommend use of the TIFF 6.0 design (TIFF Compression tag 6).
    230 Instead, we recommend the JPEG design proposed by TIFF Technical Note #2
    231 (Compression tag 7).  Copies of this Note can be obtained from
    232 http://www.ijg.org/files/.  It is expected that the next revision
    233 of the TIFF spec will replace the 6.0 JPEG design with the Note's design.
    234 Although IJG's own code does not support TIFF/JPEG, the free libtiff library
    235 uses our library to implement TIFF/JPEG per the Note.
    236 
    237 
    238 ARCHIVE LOCATIONS
    239 =================
    240 
    241 The "official" archive site for this software is www.ijg.org.
    242 The most recent released version can always be found there in
    243 directory "files".
    244 
    245 The JPEG FAQ (Frequently Asked Questions) article is a source of some
    246 general information about JPEG.
    247 It is available on the World Wide Web at http://www.faqs.org/faqs/jpeg-faq/
    248 and other news.answers archive sites, including the official news.answers
    249 archive at rtfm.mit.edu: ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/.
    250 If you don't have Web or FTP access, send e-mail to mail-server (a] rtfm.mit.edu
    251 with body
    252         send usenet/news.answers/jpeg-faq/part1
    253         send usenet/news.answers/jpeg-faq/part2
    254 
    255 
    256 FILE FORMAT COMPATIBILITY
    257 =========================
    258 
    259 This software implements ITU T.81 | ISO/IEC 10918 with some extensions from
    260 ITU T.871 | ISO/IEC 10918-5 (JPEG File Interchange Format-- see REFERENCES).
    261 Informally, the term "JPEG image" or "JPEG file" most often refers to JFIF or
    262 a subset thereof, but there are other formats containing the name "JPEG" that
    263 are incompatible with the DCT-based JPEG standard or with JFIF (for instance,
    264 JPEG 2000 and JPEG XR).  This software therefore does not support these
    265 formats.  Indeed, one of the original reasons for developing this free software
    266 was to help force convergence on a common, interoperable format standard for
    267 JPEG files.
    268 
    269 JFIF is a minimal or "low end" representation.  TIFF/JPEG (TIFF revision 6.0 as
    270 modified by TIFF Technical Note #2) can be used for "high end" applications
    271 that need to record a lot of additional data about an image.
    272 
    273 
    274 TO DO
    275 =====
    276 
    277 Please send bug reports, offers of help, etc. to jpeg-info (a] jpegclub.org.
    278

README.md

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