blob: 801af94fe28482a932cd00f6ecb69b0aded7cacc [file] [log] [blame]
DRC101f09a2010-02-12 22:52:37 +00001*******************************************************************************
2** Background
3*******************************************************************************
4
5libjpeg-turbo is a high-speed version of libjpeg for x86 and x86-64 processors
6which uses SIMD instructions (MMX, SSE2, etc.) to accelerate baseline JPEG
DRCce1546e2010-02-13 23:06:03 +00007compression and decompression. libjpeg-turbo is generally 2-4x as fast
DRC101f09a2010-02-12 22:52:37 +00008as the unmodified version of libjpeg, all else being equal.
9
10libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but
11the TigerVNC and VirtualGL projects made numerous enhancements to the codec,
12including improved support for Mac OS X, 64-bit support, support for 32-bit
13and big endian pixel formats, accelerated Huffman encoding/decoding, and
14various bug fixes. The goal was to produce a fully open source codec that
15could replace the partially closed source TurboJPEG/IPP codec used by VirtualGL
DRCce1546e2010-02-13 23:06:03 +000016and TurboVNC. libjpeg-turbo generally performs in the range of 80-120% of
DRC101f09a2010-02-12 22:52:37 +000017TurboJPEG/IPP. It is faster in some areas but slower in others.
18
19It was decided to split libjpeg-turbo into a separate SDK so that other
DRC68fef832010-02-16 05:29:10 +000020projects could take advantage of this technology. The libjpeg-turbo shared
21libraries can be used as drop-in replacements for libjpeg on most systems.
DRC101f09a2010-02-12 22:52:37 +000022
23
24*******************************************************************************
DRCce1546e2010-02-13 23:06:03 +000025** License
26*******************************************************************************
27
28Some of the optimizations to the Huffman encoder/decoder were borrowed from
DRC68fef832010-02-16 05:29:10 +000029VirtualGL, and thus the libjpeg-turbo distribution, as a whole, falls under the
30wxWindows Library Licence, Version 3.1. A copy of this license can be found in
DRC1e6b5b42010-03-20 20:00:51 +000031this directory under LICENSE.txt. The wxWindows Library License is based on
32the LGPL but includes provisions which allow the Library to be statically
33linked into proprietary libraries and applications without requiring the
34resulting binaries to be distributed under the terms of the LGPL.
35
36The rest of the source code, apart from these modifications, falls under a less
37restrictive, BSD-style license (see README.)
DRCce1546e2010-02-13 23:06:03 +000038
39
40*******************************************************************************
DRC68fef832010-02-16 05:29:10 +000041** Using libjpeg-turbo
DRC101f09a2010-02-12 22:52:37 +000042*******************************************************************************
43
DRC68fef832010-02-16 05:29:10 +000044=============================
45Replacing libjpeg at Run Time
46=============================
DRC101f09a2010-02-12 22:52:37 +000047
DRC68fef832010-02-16 05:29:10 +000048If a Unix application is dynamically linked with libjpeg, then you can replace
49libjpeg with libjpeg-turbo at run time by manipulating the LD_LIBRARY_PATH.
50For instance:
DRC101f09a2010-02-12 22:52:37 +000051
DRC68fef832010-02-16 05:29:10 +000052 [Using libjpeg]
53 > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
54 real 0m0.392s
55 user 0m0.074s
56 sys 0m0.020s
DRC101f09a2010-02-12 22:52:37 +000057
DRC68fef832010-02-16 05:29:10 +000058 [Using libjpeg-turbo]
59 > export LD_LIBRARY_PATH=/opt/libjpeg-turbo/{lib}:$LD_LIBRARY_PATH
60 > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
61 real 0m0.109s
62 user 0m0.029s
63 sys 0m0.010s
DRC101f09a2010-02-12 22:52:37 +000064
DRC68fef832010-02-16 05:29:10 +000065NOTE: {lib} can be lib, lib32, lib64, or lib/amd64, depending on the O/S and
66architecture.
DRC101f09a2010-02-12 22:52:37 +000067
DRC68fef832010-02-16 05:29:10 +000068System administrators can also replace the libjpeg sym links in /usr/{lib} with
69links to the libjpeg dynamic library located in /opt/libjpeg-turbo/{lib}. This
70will effectively accelerate every dynamically linked libjpeg application on the
71system.
DRC101f09a2010-02-12 22:52:37 +000072
DRC0248dd92010-02-25 06:21:12 +000073The Windows distribution of the libjpeg-turbo SDK installs jpeg62.dll into
DRC7e0b4992010-02-25 05:52:44 +000074c:\libjpeg-turbo\bin, and the PATH environment variable can be modified such
75that this directory is searched before any others that might contain
76jpeg62.dll. However, if jpeg62.dll also exists in an application's install
77directory, then Windows will load the application's version of it first. Thus,
78if an application ships with jpeg62.dll, then back up the application's version
79of jpeg62.dll and copy c:\libjpeg-turbo\bin\jpeg62.dll into the application's
80install directory to accelerate it.
81
DRC0248dd92010-02-25 06:21:12 +000082The version of jpeg62.dll distributed in the libjpeg-turbo SDK requires the
83Visual C++ 2008 C run time DLL (msvcr90.dll). This library ships with more
84recent versions of Windows, but users of older versions can obtain it from the
85Visual C++ 2008 Redistributable Package, which is available as a free download
86from Microsoft's web site.
87
88NOTE: Features of libjpeg which require passing a C run time structure, such
89as a file handle, from an application to libjpeg will probably not work with
90the distributed version of jpeg62.dll unless the application is also built to
91use the Visual C++ 2008 C run time DLL. In particular, this affects
92jpeg_stdio_dest() and jpeg_stdio_src().
DRC101f09a2010-02-12 22:52:37 +000093
DRC68fef832010-02-16 05:29:10 +000094Mac applications typically embed their own copies of libjpeg.62.dylib inside
95the (hidden) application bundle, so it is not possible to globally replace
96libjpeg on OS X systems. If an application uses a shared library version of
97libjpeg, then it may be possible to replace the application's version of it.
98This would generally involve copying libjpeg.62.dylib into the appropriate
99place in the application bundle and using install_name_tool to repoint the
100dylib to the new directory. This requires an advanced knowledge of OS X and
101would not survive an upgrade or a re-install of the application. Thus, it is
102not recommended for most users.
DRC101f09a2010-02-12 22:52:37 +0000103
DRC68fef832010-02-16 05:29:10 +0000104=======================
105Replacing TurboJPEG/IPP
106=======================
DRC101f09a2010-02-12 22:52:37 +0000107
DRC68fef832010-02-16 05:29:10 +0000108libjpeg-turbo is a drop-in replacement for the TurboJPEG/IPP SDK used by
109VirtualGL 2.1.x (and prior) and TurboVNC. libjpeg-turbo contains a wrapper
110library (TurboJPEG/OSS) that emulates the TurboJPEG API using libjpeg-turbo
111instead of the closed source Intel Performance Primitives. You can replace the
112TurboJPEG/IPP package on Linux systems with the libjpeg-turbo package in order
113to make existing releases of VirtualGL 2.1.x and TurboVNC use the new codec at
114run time. Note that the 64-bit libjpeg-turbo packages contain only 64-bit
115binaries, whereas the TurboJPEG/IPP 64-bit packages contain both 64-bit and
11632-bit binaries. Thus, to replace a TurboJPEG/IPP 64-bit package, install
117both the 64-bit and 32-bit versions of libjpeg-turbo.
DRC101f09a2010-02-12 22:52:37 +0000118
DRC68fef832010-02-16 05:29:10 +0000119You can also build the VirtualGL 2.1.x and TurboVNC source code with
120the libjpeg-turbo SDK instead of TurboJPEG/IPP. It should work identically.
121libjpeg-turbo also includes static library versions of TurboJPEG/OSS, which
122are used to build VirtualGL 2.2 and later.
DRC101f09a2010-02-12 22:52:37 +0000123
DRC68fef832010-02-16 05:29:10 +0000124========================================
125Using libjpeg-turbo in Your Own Programs
126========================================
DRC101f09a2010-02-12 22:52:37 +0000127
DRC68fef832010-02-16 05:29:10 +0000128For the most part, libjpeg-turbo should work identically to libjpeg, so in
129most cases, an application can be built against libjpeg and then run against
130libjpeg-turbo. On Unix systems, you can build against libjpeg-turbo instead
131of libjpeg by setting
DRC101f09a2010-02-12 22:52:37 +0000132
DRC68fef832010-02-16 05:29:10 +0000133 CPATH=/opt/libjpeg-turbo/include
134 and
135 LIBRARY_PATH=/opt/libjpeg-turbo/{lib}
DRC101f09a2010-02-12 22:52:37 +0000136
DRC68fef832010-02-16 05:29:10 +0000137({lib} = lib, lib32, lib64, or lib/amd64, as appropriate.)
DRC101f09a2010-02-12 22:52:37 +0000138
DRC0a1f68e2010-02-24 07:24:26 +0000139If using Cygwin, then set
DRC101f09a2010-02-12 22:52:37 +0000140
DRC0a1f68e2010-02-24 07:24:26 +0000141 CPATH=/cygdrive/c/libjpeg-turbo-gcc/include
142 and
143 LIBRARY_PATH=/cygdrive/c/libjpeg-turbo-gcc/lib
144
145If using MinGW, then set
146
147 CPATH=/c/libjpeg-turbo-gcc/include
148 and
149 LIBRARY_PATH=/c/libjpeg-turbo-gcc/lib
150
151Building against libjpeg-turbo is useful, for instance, if you want to build an
152application that leverages the libjpeg-turbo colorspace extensions (see below.)
153On Linux and Solaris systems, you would still need to manipulate the
154LD_LIBRARY_PATH or sym links appropriately to use libjpeg-turbo at run time.
155On such systems, you can pass -R /opt/libjpeg-turbo/{lib} to the linker to
156force the use of libjpeg-turbo at run time rather than libjpeg (also useful if
157you want to leverage the colorspace extensions), or you can link against the
158libjpeg-turbo static library.
159
160To force a Linux, Solaris, or MinGW application to link against the static
161version of libjpeg-turbo, you can use the following linker options:
DRC101f09a2010-02-12 22:52:37 +0000162
DRC68fef832010-02-16 05:29:10 +0000163 -Wl,-Bstatic -ljpeg -Wl,-Bdynamic
DRC101f09a2010-02-12 22:52:37 +0000164
DRC0a1f68e2010-02-24 07:24:26 +0000165On OS X, simply add /opt/libjpeg-turbo/{lib}/libjpeg.a to the linker command
166line (this also works on Linux and Solaris.)
DRC101f09a2010-02-12 22:52:37 +0000167
DRC68fef832010-02-16 05:29:10 +0000168To build Visual C++ applications using libjpeg-turbo, add
169c:\libjpeg-turbo\include to your system or user INCLUDE environment variable
170and c:\libjpeg-turbo\lib to your system or user LIB environment variable, and
171then link against either jpeg.lib (to use jpeg62.dll) or jpeg-static.lib (to
172use the static version of libjpeg-turbo.)
DRC101f09a2010-02-12 22:52:37 +0000173
DRC68fef832010-02-16 05:29:10 +0000174=====================
175Colorspace Extensions
176=====================
DRC101f09a2010-02-12 22:52:37 +0000177
DRC68fef832010-02-16 05:29:10 +0000178libjpeg-turbo includes extensions which allow JPEG images to be compressed
179directly from (and decompressed directly to) buffers which use BGR, BGRA,
180RGBA, ABGR, and ARGB pixel ordering. This is implemented with six new
181colorspace constants:
DRC101f09a2010-02-12 22:52:37 +0000182
DRC68fef832010-02-16 05:29:10 +0000183 JCS_EXT_RGB /* red/green/blue */
184 JCS_EXT_RGBX /* red/green/blue/x */
185 JCS_EXT_BGR /* blue/green/red */
186 JCS_EXT_BGRX /* blue/green/red/x */
187 JCS_EXT_XBGR /* x/blue/green/red */
188 JCS_EXT_XRGB /* x/red/green/blue */
DRC101f09a2010-02-12 22:52:37 +0000189
DRC68fef832010-02-16 05:29:10 +0000190Setting cinfo.in_color_space (compression) or cinfo.out_color_space
191(decompression) to one of these values will cause libjpeg-turbo to read the
192red, green, and blue values from (or write them to) the appropriate position in
193the pixel when YUV conversion is performed.
DRC101f09a2010-02-12 22:52:37 +0000194
DRC68fef832010-02-16 05:29:10 +0000195Your application can check for the existence of these extensions at compile
196time with:
DRC101f09a2010-02-12 22:52:37 +0000197
DRC68fef832010-02-16 05:29:10 +0000198 #ifdef JCS_EXTENSIONS
DRC101f09a2010-02-12 22:52:37 +0000199
DRC68fef832010-02-16 05:29:10 +0000200At run time, attempting to use these extensions with a version of libjpeg
201that doesn't support them will result in a "Bogus input colorspace" error.