*******************************************************************************
**     Background
*******************************************************************************

libjpeg-turbo is a high-speed version of libjpeg for x86 and x86-64 processors
which uses SIMD instructions (MMX, SSE2, etc.) to accelerate baseline JPEG
compression and decompression.  libjpeg-turbo is generally 2-4x as fast
as the unmodified version of libjpeg, all else being equal.

libjpeg-turbo was originally based on libjpeg/SIMD by Miyasaka Masaru, but
the TigerVNC and VirtualGL projects made numerous enhancements to the codec,
including improved support for Mac OS X, 64-bit support, support for 32-bit
and big endian pixel formats, accelerated Huffman encoding/decoding, and
various bug fixes.  The goal was to produce a fully open source codec that
could replace the partially closed source TurboJPEG/IPP codec used by VirtualGL
and TurboVNC.  libjpeg-turbo generally performs in the range of 80-120% of
TurboJPEG/IPP.  It is faster in some areas but slower in others.

It was decided to split libjpeg-turbo into a separate SDK so that other
projects could take advantage of this technology.  The libjpeg-turbo shared
libraries can be used as drop-in replacements for libjpeg on most systems.


*******************************************************************************
**     License
*******************************************************************************

Some of the optimizations to the Huffman encoder/decoder were borrowed from
VirtualGL, and thus the libjpeg-turbo distribution, as a whole, falls under the
wxWindows Library Licence, Version 3.1.  A copy of this license can be found in
this directory under LICENSE.txt.  The rest of the source code, apart from
these modifications, falls under a less restrictive license (see README.)


*******************************************************************************
**     Using libjpeg-turbo
*******************************************************************************

=============================
Replacing libjpeg at Run Time
=============================

If a Unix application is dynamically linked with libjpeg, then you can replace
libjpeg with libjpeg-turbo at run time by manipulating the LD_LIBRARY_PATH.
For instance:

  [Using libjpeg]
  > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
  real  0m0.392s
  user  0m0.074s
  sys   0m0.020s

  [Using libjpeg-turbo]
  > export LD_LIBRARY_PATH=/opt/libjpeg-turbo/{lib}:$LD_LIBRARY_PATH
  > time cjpeg <vgl_5674_0098.ppm >vgl_5674_0098.jpg
  real  0m0.109s
  user  0m0.029s
  sys   0m0.010s

NOTE: {lib} can be lib, lib32, lib64, or lib/amd64, depending on the O/S and
architecture.

System administrators can also replace the libjpeg sym links in /usr/{lib} with
links to the libjpeg dynamic library located in /opt/libjpeg-turbo/{lib}.  This
will effectively accelerate every dynamically linked libjpeg application on the
system.

The Windows version of libjpeg-turbo installs jpeg62.dll into
%systemroot%\system32.  However, if jpeg62.dll also exists in an application's
install directory, then Windows will load the application's version of it
first.  Thus, if an application ships with jpeg62.dll, then back up the
application's version of jpeg62.dll and copy %systemroot%\system32\jpeg62.dll
into the application's install directory to accelerate it.

Mac applications typically embed their own copies of libjpeg.62.dylib inside
the (hidden) application bundle, so it is not possible to globally replace
libjpeg on OS X systems.  If an application uses a shared library version of
libjpeg, then it may be possible to replace the application's version of it.
This would generally involve copying libjpeg.62.dylib into the appropriate
place in the application bundle and using install_name_tool to repoint the
dylib to the new directory.  This requires an advanced knowledge of OS X and
would not survive an upgrade or a re-install of the application.  Thus, it is
not recommended for most users.

=======================
Replacing TurboJPEG/IPP
=======================

libjpeg-turbo is a drop-in replacement for the TurboJPEG/IPP SDK used by
VirtualGL 2.1.x (and prior) and TurboVNC.  libjpeg-turbo contains a wrapper
library (TurboJPEG/OSS) that emulates the TurboJPEG API using libjpeg-turbo
instead of the closed source Intel Performance Primitives.  You can replace the
TurboJPEG/IPP package on Linux systems with the libjpeg-turbo package in order
to make existing releases of VirtualGL 2.1.x and TurboVNC use the new codec at
run time.  Note that the 64-bit libjpeg-turbo packages contain only 64-bit
binaries, whereas the TurboJPEG/IPP 64-bit packages contain both 64-bit and
32-bit binaries.  Thus, to replace a TurboJPEG/IPP 64-bit package, install
both the 64-bit and 32-bit versions of libjpeg-turbo.

You can also build the VirtualGL 2.1.x and TurboVNC source code with
the libjpeg-turbo SDK instead of TurboJPEG/IPP.  It should work identically.
libjpeg-turbo also includes static library versions of TurboJPEG/OSS, which
are used to build VirtualGL 2.2 and later.

========================================
Using libjpeg-turbo in Your Own Programs
========================================

For the most part, libjpeg-turbo should work identically to libjpeg, so in
most cases, an application can be built against libjpeg and then run against
libjpeg-turbo.  On Unix systems, you can build against libjpeg-turbo instead
of libjpeg by setting

  CPATH=/opt/libjpeg-turbo/include
  and
  LIBRARY_PATH=/opt/libjpeg-turbo/{lib}

({lib} = lib, lib32, lib64, or lib/amd64, as appropriate.)

This is useful, for instance, if you want to build an application that
leverages the libjpeg-turbo colorspace extensions (see below.)  On Linux and
Solaris systems, you would still need to manipulate the LD_LIBRARY_PATH or sym
links appropriately to use libjpeg-turbo at run time.  On such systems, you can
pass -R /opt/libjpeg-turbo/{lib} to the linker to force the use of
libjpeg-turbo at run time rather than libjpeg (also useful if you want to
leverage the colorspace extensions), or you can link against the libjpeg-turbo
static library.

To force a Linux or Solaris application to link against the static version of
libjpeg-turbo, you can use the following linker options:

  -Wl,-Bstatic -ljpeg -Wl,-Bdynamic

or you can simply add /opt/libjpeg-turbo/{lib}/libjpeg.a to the linker command
line (the latter is the only way to link against the static version of
libjpeg-turbo on OS X.)

To build Visual C++ applications using libjpeg-turbo, add
c:\libjpeg-turbo\include to your system or user INCLUDE environment variable
and c:\libjpeg-turbo\lib to your system or user LIB environment variable, and
then link against either jpeg.lib (to use jpeg62.dll) or jpeg-static.lib (to
use the static version of libjpeg-turbo.)

If building an application using Cygwin, then set

  CPATH=/cygdrive/c/libjpeg-turbo/include
  and
  LIBRARY_PATH=/cygdrive/c/libjpeg-turbo/lib

If using MinGW, then set

  CPATH=/c/libjpeg-turbo/include
  and
  LIBRARY_PATH=/c/libjpeg-turbo/lib

and link using -ljpeg in both cases.  NOTE: The static libraries shipped with
the Windows version of libjpeg-turbo cannot be used with MinGW and Cygwin.  If
you wish to link statically with libjpeg-turbo using MinGW or Cygwin, then you
will need to build libjpeg-turbo from source using GCC.

=====================
Colorspace Extensions
=====================

libjpeg-turbo includes extensions which allow JPEG images to be compressed
directly from (and decompressed directly to) buffers which use BGR, BGRA,
RGBA, ABGR, and ARGB pixel ordering.  This is implemented with six 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 */

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 YUV conversion is performed.

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 version of libjpeg
that doesn't support them will result in a "Bogus input colorspace" error.