3
3
*******************************************************************************
5
libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX,
6
SSE2, NEON) to accelerate baseline JPEG compression and decompression on x86,
7
x86-64, and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as
8
fast as the unmodified version of libjpeg, all else being equal.
10
libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but
11
the TigerVNC and VirtualGL projects made numerous enhancements to the codec in
12
2009, including improved support for Mac OS X, 64-bit support, support for
13
32-bit and big-endian pixel formats (RGBX, XBGR, etc.), accelerated Huffman
14
encoding/decoding, and various bug fixes. The goal was to produce a fully
15
open-source codec that could replace the partially closed-source TurboJPEG/IPP
16
codec used by VirtualGL and TurboVNC. libjpeg-turbo generally achieves 80-120%
17
of the performance of TurboJPEG/IPP. It is faster in some areas but slower in
20
In early 2010, libjpeg-turbo spun off into its own independent project, with
21
the goal of making high-speed JPEG compression/decompression technology
22
available to a broader range of users and developers.
5
libjpeg-turbo is a JPEG image codec that uses SIMD instructions (MMX, SSE2,
6
NEON) to accelerate baseline JPEG compression and decompression on x86, x86-64,
7
and ARM systems. On such systems, libjpeg-turbo is generally 2-4x as fast as
8
libjpeg, all else being equal. On other types of systems, libjpeg-turbo can
9
still outperform libjpeg by a significant amount, by virtue of its
10
highly-optimized Huffman coding routines. In many cases, the performance of
11
libjpeg-turbo rivals that of proprietary high-speed JPEG codecs.
13
libjpeg-turbo implements both the traditional libjpeg API as well as the less
14
powerful but more straightforward TurboJPEG API. libjpeg-turbo also features
15
colorspace extensions that allow it to compress from/decompress to 32-bit and
16
big-endian pixel buffers (RGBX, XBGR, etc.), as well as a full-featured Java
19
libjpeg-turbo was originally based on libjpeg/SIMD, an MMX-accelerated
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
27
*******************************************************************************
72
74
libjpeg API: This is the de facto industry-standard API for compressing and
73
75
decompressing JPEG images. It is more difficult to use than the TurboJPEG
74
API but also more powerful. libjpeg-turbo is both API/ABI-compatible and
75
mathematically compatible with libjpeg v6b. It can also optionally be
76
configured to be API/ABI-compatible with libjpeg v7 and v8 (see below.)
76
API but also more powerful. The libjpeg API implementation in libjpeg-turbo
77
is both API/ABI-compatible and mathematically compatible with libjpeg v6b.
78
It can also optionally be configured to be API/ABI-compatible with libjpeg v7
81
There is no significant performance advantage to either API when both are used
82
to perform similar operations.
84
======================
85
Installation Directory
86
======================
88
This document assumes that libjpeg-turbo will be installed in the default
89
directory (/opt/libjpeg-turbo on Un*x and Mac systems and
90
c:\libjpeg-turbo[-gcc][64] on Windows systems. If your installation of
91
libjpeg-turbo resides in a different directory, then adjust the instructions
79
94
=============================
80
95
Replacing libjpeg at Run Time
81
96
=============================
83
If a Unix application is dynamically linked with libjpeg, then you can replace
101
If a Un*x application is dynamically linked with libjpeg, then you can replace
84
102
libjpeg with libjpeg-turbo at run time by manipulating LD_LIBRARY_PATH.
100
NOTE: {lib} can be lib, lib32, lib64, or lib/64, depending on the O/S and
118
({lib} = lib32 or lib64, depending on whether you wish to use the 32-bit or the
119
64-bit version of libjpeg-turbo.)
103
System administrators can also replace the libjpeg sym links in /usr/{lib} with
121
System administrators can also replace the libjpeg symlinks in /usr/lib* with
104
122
links to the libjpeg-turbo dynamic library located in /opt/libjpeg-turbo/{lib}.
105
123
This will effectively accelerate every application that uses the libjpeg
106
124
dynamic library on the system.
108
The libjpeg-turbo SDK for Visual C++ installs the libjpeg-turbo DLL
109
(jpeg62.dll, jpeg7.dll, or jpeg8.dll, depending on whether it was built with
110
libjpeg v6b, v7, or v8 emulation) into c:\libjpeg-turbo[64]\bin, and the PATH
111
environment variable can be modified such that this directory is searched
112
before any others that might contain a libjpeg DLL. However, if a libjpeg
113
DLL exists in an application's install directory, then Windows will load this
114
DLL first whenever the application is launched. Thus, if an application ships
115
with jpeg62.dll, jpeg7.dll, or jpeg8.dll, then back up the application's
116
version of this DLL and copy c:\libjpeg-turbo[64]\bin\jpeg*.dll into the
117
application's install directory to accelerate it.
119
The version of the libjpeg-turbo DLL distributed in the libjpeg-turbo SDK for
120
Visual C++ requires the Visual C++ 2008 C run-time DLL (msvcr90.dll).
129
If a Windows application is dynamically linked with libjpeg, then you can
130
replace libjpeg with libjpeg-turbo at run time by backing up the application's
131
copy of jpeg62.dll, jpeg7.dll, or jpeg8.dll (assuming the application has its
132
own local copy of this library) and copying the corresponding DLL from
133
libjpeg-turbo into the application's install directory. The official
134
libjpeg-turbo binary packages only provide jpeg62.dll. If the application uses
135
jpeg7.dll or jpeg8.dll instead, then it will be necessary to build
136
libjpeg-turbo from source (see "libjpeg v7 and v8 API/ABI Emulation" below.)
138
The following information is specific to the official libjpeg-turbo binary
139
packages for Visual C++:
141
-- jpeg62.dll requires the Visual C++ 2008 C run-time DLL (msvcr90.dll).
121
142
msvcr90.dll ships with more recent versions of Windows, but users of older
122
143
Windows releases can obtain it from the Visual C++ 2008 Redistributable
123
144
Package, which is available as a free download from Microsoft's web site.
125
NOTE: Features of libjpeg that require passing a C run-time structure, such
126
as a file handle, from an application to libjpeg will probably not work with
127
the version of the libjpeg-turbo DLL distributed in the libjpeg-turbo SDK for
128
Visual C++, unless the application is also built to use the Visual C++ 2008 C
129
run-time DLL. In particular, this affects jpeg_stdio_dest() and
146
-- Features of the libjpeg API that require passing a C run-time structure,
147
such as a file handle, from an application to the library will probably not
148
work with jpeg62.dll, unless the application is also built to use the Visual
149
C++ 2008 C run-time DLL. In particular, this affects jpeg_stdio_dest() and
130
150
jpeg_stdio_src().
132
155
Mac applications typically embed their own copies of the libjpeg dylib inside
133
156
the (hidden) application bundle, so it is not possible to globally replace
134
libjpeg on OS X systems. If an application uses a shared library version of
135
libjpeg, then it may be possible to replace the application's version of it.
136
This would generally involve copying libjpeg.*.dylib from libjpeg-turbo into
157
libjpeg on OS X systems. Replacing the application's version of the libjpeg
158
dylib would generally involve copying libjpeg.*.dylib from libjpeg-turbo into
137
159
the appropriate place in the application bundle and using install_name_tool to
138
repoint the dylib to the new directory. This requires an advanced knowledge of
139
OS X and would not survive an upgrade or a re-install of the application.
140
Thus, it is not recommended for most users.
142
=======================
143
Replacing TurboJPEG/IPP
144
=======================
146
libjpeg-turbo is a drop-in replacement for the TurboJPEG/IPP SDK used by
147
VirtualGL 2.1.x and TurboVNC 0.6 (and prior.) libjpeg-turbo contains a wrapper
148
library (TurboJPEG/OSS) that emulates the TurboJPEG API using libjpeg-turbo
149
instead of the closed-source Intel Performance Primitives. You can replace the
150
TurboJPEG/IPP package on Linux systems with the libjpeg-turbo package in order
151
to make existing releases of VirtualGL 2.1.x and TurboVNC 0.x use the new codec
152
at run time. Note that the 64-bit libjpeg-turbo packages contain only 64-bit
153
binaries, whereas the TurboJPEG/IPP 64-bit packages contained both 64-bit and
154
32-bit binaries. Thus, to replace a TurboJPEG/IPP 64-bit package, install
155
both the 64-bit and 32-bit versions of libjpeg-turbo.
157
You can also build the VirtualGL 2.1.x and TurboVNC 0.6 source code with
158
the libjpeg-turbo SDK instead of TurboJPEG/IPP. It should work identically.
159
libjpeg-turbo also includes static library versions of TurboJPEG/OSS, which
160
are used to build VirtualGL 2.2 and TurboVNC 1.0 and later.
160
repoint the libjpeg-turbo dylib to its new directory. This requires an
161
advanced knowledge of OS X and would not survive an upgrade or a re-install of
162
the application. Thus, it is not recommended for most users.
162
164
========================================
163
165
Using libjpeg-turbo in Your Own Programs
184
186
Building against libjpeg-turbo is useful, for instance, if you want to build an
185
187
application that leverages the libjpeg-turbo colorspace extensions (see below.)
186
On Linux and Solaris systems, you would still need to manipulate
187
LD_LIBRARY_PATH or create appropriate sym links to use libjpeg-turbo at run
188
time. On such systems, you can pass -R /opt/libjpeg-turbo/{lib} to the linker
189
to force the use of libjpeg-turbo at run time rather than libjpeg (also useful
190
if you want to leverage the colorspace extensions), or you can link against the
191
libjpeg-turbo static library.
188
On Un*x systems, you would still need to manipulate LD_LIBRARY_PATH or create
189
appropriate symlinks to use libjpeg-turbo at run time. On such systems, you
190
can pass -R /opt/libjpeg-turbo/{lib} to the linker to force the use of
191
libjpeg-turbo at run time rather than libjpeg (also useful if you want to
192
leverage the colorspace extensions), or you can link against the libjpeg-turbo
193
To force a Linux, Solaris, or MinGW application to link against the static
194
version of libjpeg-turbo, you can use the following linker options:
195
To force a Un*x or MinGW application to link against the static version of
196
libjpeg-turbo, you can use the following linker options:
196
198
-Wl,-Bstatic -ljpeg -Wl,-Bdynamic
198
200
On OS X, simply add /opt/libjpeg-turbo/lib/libjpeg.a to the linker command
199
line (this also works on Linux and Solaris.)
201
203
To build Visual C++ applications using libjpeg-turbo, add
202
204
c:\libjpeg-turbo[64]\include to the system or user INCLUDE environment
252
256
jcstest.c, located in the libjpeg-turbo source tree, demonstrates how to check
253
257
for the existence of the colorspace extensions at compile time and run time.
255
=================================
256
libjpeg v7 and v8 API/ABI support
257
=================================
259
===================================
260
libjpeg v7 and v8 API/ABI Emulation
261
===================================
259
263
With libjpeg v7 and v8, new features were added that necessitated extending the
260
264
compression and decompression structures. Unfortunately, due to the exposed
261
265
nature of those structures, extending them also necessitated breaking backward
262
ABI compatibility with previous libjpeg releases. Thus, programs that are
266
ABI compatibility with previous libjpeg releases. Thus, programs that were
263
267
built to use libjpeg v7 or v8 did not work with libjpeg-turbo, since it is
264
268
based on the libjpeg v6b code base. Although libjpeg v7 and v8 are still not
265
as widely used as v6b, enough programs (including a few Linux distros) have
266
made the switch that it was desirable to provide support for the libjpeg v7/v8
267
API/ABI in libjpeg-turbo. Although libjpeg-turbo can now be configured as a
268
drop-in replacement for libjpeg v7 or v8, it should be noted that not all of
269
the features in libjpeg v7 and v8 are supported (see below.)
269
as widely used as v6b, enough programs (including a few Linux distros) made
270
the switch that there was a demand to emulate the libjpeg v7 and v8 ABIs
271
in libjpeg-turbo. It should be noted, however, that this feature was added
272
primarily so that applications that had already been compiled to use libjpeg
273
v7+ could take advantage of accelerated baseline JPEG encoding/decoding
274
without recompiling. libjpeg-turbo does not claim to support all of the
275
libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
271
278
By passing an argument of --with-jpeg7 or --with-jpeg8 to configure, or an
272
279
argument of -DWITH_JPEG7=1 or -DWITH_JPEG8=1 to cmake, you can build a version
273
of libjpeg-turbo that emulates the libjpeg v7 or v8 API/ABI, so that programs
280
of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that programs
274
281
that are built against libjpeg v7 or v8 can be run with libjpeg-turbo. The
275
282
following section describes which libjpeg v7+ features are supported and which
278
libjpeg v7 and v8 Features:
279
---------------------------
285
Support for libjpeg v7 and v8 Features:
286
---------------------------------------
290
-- libjpeg: IDCT scaling extensions in decompressor
291
libjpeg-turbo supports IDCT scaling with scaling factors of 1/8, 1/4, 3/8,
292
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
293
and 1/2 are SIMD-accelerated.)
295
-- libjpeg: arithmetic coding
297
-- libjpeg: In-memory source and destination managers
283
300
-- cjpeg: Separate quality settings for luminance and chrominance
284
301
Note that the libpjeg v7+ API was extended to accommodate this feature only
285
302
for convenience purposes. It has always been possible to implement this
288
305
-- cjpeg: 32-bit BMP support
307
-- cjpeg: -rgb option
290
309
-- jpegtran: lossless cropping
292
311
-- jpegtran: -perfect option
313
-- jpegtran: forcing width/height when performing lossless crop
294
315
-- rdjpgcom: -raw option
296
317
-- rdjpgcom: locale awareness
299
Fully supported when using libjpeg v7/v8 emulation:
322
NOTE: As of this writing, extensive research has been conducted into the
323
usefulness of DCT scaling as a means of data reduction and SmartScale as a
324
means of quality improvement. The reader is invited to peruse the research at
325
http://www.libjpeg-turbo.org/About/SmartScale and draw his/her own conclusions,
326
but it is the general belief of our project that these features have not
327
demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo.
305
329
-- libjpeg: DCT scaling in compressor
306
330
cinfo.scale_num and cinfo.scale_denom are silently ignored.
307
There is no technical reason why DCT scaling cannot be supported, but
308
without the SmartScale extension (see below), it would only be able to
309
down-scale using ratios of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and 8/9,
310
which is of limited usefulness.
331
There is no technical reason why DCT scaling could not be supported when
332
emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see
333
below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and
334
8/9 would be available, which is of limited usefulness.
312
336
-- libjpeg: SmartScale
313
337
cinfo.block_size is silently ignored.
314
338
SmartScale is an extension to the JPEG format that allows for DCT block
315
sizes other than 8x8. It would be difficult to support this feature while
316
retaining backward compatibility with libjpeg v6b.
318
libjpeg-turbo still supports IDCT scaling with scaling factors of 1/2, 1/4,
319
and 1/8 (same as libjpeg v6b.)
339
sizes other than 8x8. Providing support for this new format would be
340
feasible (particularly without full acceleration.) However, until/unless
341
the format becomes either an official industry standard or, at minimum, an
342
accepted solution in the community, we are hesitant to implement it, as
343
there is no sense of whether or how it might change in the future. It is
344
our belief that SmartScale has not demonstrated sufficient usefulness as a
345
lossless format nor as a means of quality enhancement, and thus, our primary
346
interest in providing this feature would be as a means of supporting
347
additional DCT scaling factors.
321
349
-- libjpeg: Fancy downsampling in compressor
322
350
cinfo.do_fancy_downsampling is silently ignored.
331
357
-- Lossless RGB JPEG files
332
358
This requires the SmartScale feature, which is not supported.
335
*******************************************************************************
336
** Performance pitfalls
360
What About libjpeg v9?
361
----------------------
363
libjpeg v9 introduced yet another field to the JPEG compression structure
364
(color_transform), thus making the ABI backward incompatible with that of
365
libjpeg v8. This new field was introduced solely for the purpose of supporting
366
lossless SmartScale encoding. Further, there was actually no reason to extend
367
the API in this manner, as the color transform could have just as easily been
368
activated by way of a new JPEG colorspace constant, thus preserving backward
371
Our research (see link above) has shown that lossless SmartScale does not
372
generally accomplish anything that can't already be accomplished better with
373
existing, standard lossless formats. Thus, at this time, it is our belief that
374
there is not sufficient technical justification for software to upgrade from
375
libjpeg v8 to libjpeg v9, and therefore, not sufficient technical justification
376
for us to emulate the libjpeg v9 ABI.
378
=====================================
379
In-Memory Source/Destination Managers
380
=====================================
382
By default, libjpeg-turbo 1.3 and later includes the jpeg_mem_src() and
383
jpeg_mem_dest() functions, even when not emulating the libjpeg v8 API/ABI.
384
Previously, it was necessary to build libjpeg-turbo from source with libjpeg v8
385
API/ABI emulation in order to use the in-memory source/destination managers,
386
but several projects requested that those functions be included when emulating
387
the libjpeg v6b API/ABI as well. This allows the use of those functions by
388
programs that need them without breaking ABI compatibility for programs that
389
don't, and it allows those functions to be provided in the "official"
390
libjpeg-turbo binaries.
392
Those who are concerned about maintaining strict conformance with the libjpeg
393
v6b or v7 API can pass an argument of --without-mem-srcdst to configure or
394
an argument of -DWITH_MEM_SRCDST=0 to CMake prior to building libjpeg-turbo.
395
This will restore the pre-1.3 behavior, in which jpeg_mem_src() and
396
jpeg_mem_dest() are only included when emulating the libjpeg v8 API/ABI.
398
On Un*x systems, including the in-memory source/destination managers changes
399
the dynamic library version from 62.0.0 to 62.1.0 if using libjpeg v6b API/ABI
400
emulation and from 7.0.0 to 7.1.0 if using libjpeg v7 API/ABI emulation.
402
Note that, on most Un*x systems, the dynamic linker will not look for a
403
function in a library until that function is actually used. Thus, if a program
404
is built against libjpeg-turbo 1.3+ and uses jpeg_mem_src() or jpeg_mem_dest(),
405
that program will not fail if run against an older version of libjpeg-turbo or
406
against libjpeg v7- until the program actually tries to call jpeg_mem_src() or
407
jpeg_mem_dest(). Such is not the case on Windows. If a program is built
408
against the libjpeg-turbo 1.3+ DLL and uses jpeg_mem_src() or jpeg_mem_dest(),
409
then it must use the libjpeg-turbo 1.3+ DLL at run time.
411
Both cjpeg and djpeg have been extended to allow testing the in-memory
412
source/destination manager functions. See their respective man pages for more
416
*******************************************************************************
417
** Mathematical Compatibility
418
*******************************************************************************
420
For the most part, libjpeg-turbo should produce identical output to libjpeg
421
v6b. The one exception to this is when using the floating point DCT/IDCT, in
422
which case the outputs of libjpeg v6b and libjpeg-turbo are not guaranteed to
423
be identical (the accuracy of the floating point DCT/IDCT is constant when
424
using libjpeg-turbo's SIMD extensions, but otherwise, it can depend heavily on
425
the compiler and compiler settings.)
427
While libjpeg-turbo does emulate the libjpeg v8 API/ABI, under the hood, it is
428
still using the same algorithms as libjpeg v6b, so there are several specific
429
cases in which libjpeg-turbo cannot be expected to produce the same output as
432
-- When decompressing using scaling factors of 1/2 and 1/4, because libjpeg v8
433
implements those scaling algorithms a bit differently than libjpeg v6b does,
434
and libjpeg-turbo's SIMD extensions are based on the libjpeg v6b behavior.
436
-- When using chrominance subsampling, because libjpeg v8 implements this
437
with its DCT/IDCT scaling algorithms rather than with a separate
438
downsampling/upsampling algorithm.
440
-- When using the floating point IDCT, for the reasons stated above and also
441
because the floating point IDCT algorithm was modified in libjpeg v8a to
444
-- When decompressing using a scaling factor > 1 and merged (AKA "non-fancy" or
445
"non-smooth") chrominance upsampling, because libjpeg v8 does not support
446
merged upsampling with scaling factors > 1.
449
*******************************************************************************
450
** Performance Pitfalls
337
451
*******************************************************************************
added
removed
README-turbo.txt
