]> granicus.if.org Git - libjpeg-turbo/commitdiff
Merge wordsmithing/grammar fixes from trunk
authorDRC <dcommander@users.sourceforge.net>
Tue, 17 Jan 2012 23:09:24 +0000 (23:09 +0000)
committerDRC <dcommander@users.sourceforge.net>
Tue, 17 Jan 2012 23:09:24 +0000 (23:09 +0000)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.1.x@737 632fc199-4ca6-4c93-a231-07263d6284db

BUILDING.txt
ChangeLog.txt
README-turbo.txt
turbojpeg.h

index 846e96989fbf3fbd55290f21ff5ccd9acd067d2e..70fa40058b736182eec6a0956f6f77e91a2fec6d 100644 (file)
@@ -11,7 +11,7 @@ Build Requirements
 -- automake 1.7 or later
 -- libtool 1.4 or later
 
--- NASM
+-- NASM (if building x86 or x86-64 SIMD extensions)
    * 0.98, or 2.01 or later is required for a 32-bit build
    * NASM 2.00 or later is required for a 64-bit build
    * NASM 2.07 or later is required for a 64-bit build on OS X.  This can be
@@ -553,7 +553,7 @@ make dmg
 make udmg [BUILDDIR32={32-bit build directory}]
 
   On 64-bit OS X systems, this creates a version of the Macintosh package and
-  disk image which contains universal i386/x86-64 binaries.  You should first
+  disk image that contains universal i386/x86-64 binaries.  You should first
   configure a 32-bit out-of-tree build of libjpeg-turbo, then configure a
   64-bit out-of-tree build, then run 'make udmg' from the 64-bit build
   directory.  The build system will look for the 32-bit build under
@@ -566,7 +566,7 @@ make sunpkg
 
 make csunpkg [BUILDDIR32={32-bit build directory}]
 
-  On 64-bit Solaris systems, this creates a combined package which contains
+  On 64-bit Solaris systems, this creates a combined package that contains
   both 32-bit and 64-bit libraries.  You should first configure a 32-bit
   out-of-tree build of libjpeg-turbo, then configure a 64-bit out-of-tree
   build, then run 'make csunpkg' from the 64-bit build directory.  The build
index fe264d50da100634317d90bfcd512f9f609d0e1d..00441d2bd68e79e6fd52b56c0ff564116e072382 100644 (file)
@@ -18,7 +18,7 @@ based on whether libjpeg v7 or v8 emulation was enabled.
 fail to compile if the Windows system headers were included before jpeglib.h.
 This issue was caused by a conflict in the definition of the INT32 type.
 
-[4] Fixed 32-bit supplementary package for amd64 Debian systems which was
+[4] Fixed 32-bit supplementary package for amd64 Debian systems, which was
 broken by enhancements to the packaging system in 1.1.
 
 [5] Fixed out-of-bounds read in SSE2 SIMD code that occurred when decompressing
@@ -105,7 +105,8 @@ README-turbo.txt for more details.  This feature was sponsored by CamTrace SAS.
 
 [2] Created a new CMake-based build system for the Visual C++ and MinGW builds.
 
-[3] TurboJPEG/OSS can now compress from/decompress to grayscale bitmaps.
+[3] Grayscale bitmaps can now be compressed from/decompressed to using the
+TurboJPEG API.
 
 [4] jpgtest can now be used to test decompression performance with existing
 JPEG images.
@@ -121,11 +122,12 @@ when the library is built with libjpeg v6b emulation.
 [7] Added arithmetic encoding and decoding support (can be disabled with
 configure or CMake options)
 
-[8] Added a TJ_YUV flag to TurboJPEG/OSS which causes both the compressor and
-decompressor to output planar YUV images.
+[8] Added a TJ_YUV flag to the TurboJPEG API, which causes both the compressor
+and decompressor to output planar YUV images.
 
-[9] Added an extended version of tjDecompressHeader() to TurboJPEG/OSS which
-allows the caller to determine the type of subsampling used in a JPEG image.
+[9] Added an extended version of tjDecompressHeader() to the TurboJPEG API,
+which allows the caller to determine the type of subsampling used in a JPEG
+image.
 
 [10] Added further protections against invalid Huffman codes.
 
@@ -137,7 +139,7 @@ allows the caller to determine the type of subsampling used in a JPEG image.
 from a corrupt JPEG image.)  Previously, these would cause libjpeg-turbo to
 crash under certain circumstances.
 
-[2] Fixed typo in SIMD dispatch routines which was causing 4:2:2 upsampling to
+[2] Fixed typo in SIMD dispatch routines that was causing 4:2:2 upsampling to
 be used instead of 4:2:0 when decompressing JPEG images using SSE2 code.
 
 [3] configure script will now automatically determine whether the
@@ -158,7 +160,7 @@ static libraries can always be found in /opt/libjpeg-turbo/lib32, and the
 [3] The Unix/Linux distribution packages now include the libjpeg run-time
 programs (cjpeg, etc.) and man pages.
 
-[4] Created a 32-bit supplementary package for amd64 Debian systems which
+[4] Created a 32-bit supplementary package for amd64 Debian systems, which
 contains just the 32-bit libjpeg-turbo libraries.
 
 [5] Moved the libraries from */lib32 to */lib in the i386 Debian package.
index fec34e0cdabbfc1ef49d21dfe694ff0775623623..a385270c13bdefaaee88297d3a3cc2749596002f 100755 (executable)
@@ -2,7 +2,7 @@
 **     Background
 *******************************************************************************
 
-libjpeg-turbo is a derivative of libjpeg which uses SIMD instructions (MMX,
+libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX,
 SSE2, etc.) to accelerate baseline JPEG compression and decompression on x86
 and x86-64 systems.  On such systems, libjpeg-turbo is generally 2-4x as fast
 as the unmodified version of libjpeg, all else being equal.
@@ -28,10 +28,10 @@ libraries can be used as drop-in replacements for libjpeg on most systems.
 
 The TurboJPEG/OSS wrapper, as well as some of the optimizations to the Huffman
 encoder (jchuff.c) and decoder (jdhuff.c), were borrowed from VirtualGL, and
-thus any distribution of libjpeg-turbo which includes those files must, as a
+thus any distribution of libjpeg-turbo that includes those files must, as a
 whole, be subject to the terms of the wxWindows Library Licence, Version 3.1.
 A copy of this license can be found in this directory under LICENSE.txt.  The
-wxWindows Library License is based on the LGPL but includes provisions which
+wxWindows Library License is based on the LGPL but includes provisions that
 allow the Library to be statically linked into proprietary libraries and
 applications without requiring the resulting binaries to be distributed under
 the terms of the LGPL.
@@ -93,7 +93,7 @@ msvcr90.dll ships with more recent versions of Windows, but users of older
 Windows releases can obtain it from the Visual C++ 2008 Redistributable
 Package, which is available as a free download from Microsoft's web site.
 
-NOTE:  Features of libjpeg which require passing a C run time structure, such
+NOTE:  Features of libjpeg that require passing a C run time structure, such
 as a file handle, from an application to libjpeg will probably not work with
 the version of the libjpeg-turbo DLL distributed in the libjpeg-turbo SDK for
 Visual C++, unless the application is also built to use the Visual C++ 2008 C
@@ -179,8 +179,8 @@ libjpeg-turbo) or jpeg-static.lib (to use the static version of libjpeg-turbo.)
 Colorspace Extensions
 =====================
 
-libjpeg-turbo includes extensions which allow JPEG images to be compressed
-directly from (and decompressed directly to) buffers which use BGR, BGRX,
+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 six new
 colorspace constants:
 
@@ -194,7 +194,7 @@ colorspace constants:
 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.
+the pixel when compressing from/decompressing to an RGB buffer.
 
 Your application can check for the existence of these extensions at compile
 time with:
@@ -210,7 +210,7 @@ libjpeg v7 and v8 API/ABI support
 
 libjpeg v7 and v8 added new features to the API/ABI, and, unfortunately, the
 compression and decompression structures were extended in a backward-
-incompatible manner to accommodate these features.  Thus, programs which are
+incompatible manner to accommodate these features.  Thus, programs that are
 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 still not
 as widely used as v6b, enough programs (including a few Linux distros) have
@@ -218,7 +218,7 @@ made the switch that it was desirable to provide support for the libjpeg v7/v8
 API/ABI in libjpeg-turbo.
 
 Some of the libjpeg v7 and v8 features -- DCT scaling, to name one -- involve
-deep modifications to the code which cannot be accommodated by libjpeg-turbo
+deep modifications to the code that cannot be accommodated by libjpeg-turbo
 without either breaking compatibility with libjpeg v6b or producing an
 unsupportable mess.  In order to fully support libjpeg v8 with all of its
 features, we would have to essentially port the SIMD extensions to the libjpeg
@@ -229,8 +229,8 @@ releases will also be backward-incompatible.
 
 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 which emulates the libjpeg v7 or v8 API/ABI, so that programs
-which are built against libjpeg v7 or v8 can be run with libjpeg-turbo.  The
+of libjpeg-turbo that emulates the libjpeg v7 or v8 API/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.
 
index 24816d7ecd1c24cb0714da6492bdfa5b1168585e..1c1e97fafa9d4dabd882b43b7ea79a3a5f397ff6 100644 (file)
@@ -105,10 +105,10 @@ DLLEXPORT tjhandle DLLCALL tjInitCompress(void);
   [INPUT] height = height (in pixels) of the source image
   [INPUT] pixelsize = size (in bytes) of each pixel in the source image
      RGBX/BGRX/XRGB/XBGR: 4, RGB/BGR: 3, Grayscale: 1
-  [INPUT] dstbuf = pointer to user-allocated image buffer which will receive
+  [INPUT] dstbuf = pointer to user-allocated image buffer that will receive
      the JPEG image.  Use the TJBUFSIZE(width, height) function to determine
      the appropriate size for this buffer based on the image width and height.
-  [OUTPUT] size = pointer to unsigned long which receives the size (in bytes)
+  [OUTPUT] size = pointer to unsigned long that receives the size (in bytes)
      of the compressed image
   [INPUT] jpegsubsamp = Specifies either 4:2:0, 4:2:2, 4:4:4, or grayscale
      subsampling.  When the image is converted from the RGB to YCbCr colorspace
@@ -139,7 +139,7 @@ DLLEXPORT int DLLCALL tjCompress(tjhandle j,
 /*
   unsigned long TJBUFSIZE(int width, int height)
 
-  Convenience function which returns the maximum size of the buffer required to
+  Convenience function that returns the maximum size of the buffer required to
   hold a JPEG image with the given width and height
 
   RETURNS: -1 if arguments are out of bounds
@@ -150,7 +150,7 @@ DLLEXPORT unsigned long DLLCALL TJBUFSIZE(int width, int height);
 /*
   unsigned long TJBUFSIZEYUV(int width, int height, int subsamp)
 
-  Convenience function which returns the size of the buffer required to
+  Convenience function that returns the size of the buffer required to
   hold a YUV planar image with the given width, height, and level of
   chrominance subsampling
 
@@ -190,7 +190,7 @@ DLLEXPORT unsigned long DLLCALL TJBUFSIZEYUV(int width, int height,
   [INPUT] height = height (in pixels) of the source image
   [INPUT] pixelsize = size (in bytes) of each pixel in the source image
      RGBX/BGRX/XRGB/XBGR: 4, RGB/BGR: 3, Grayscale: 1
-  [INPUT] dstbuf = pointer to user-allocated image buffer which will receive
+  [INPUT] dstbuf = pointer to user-allocated image buffer that will receive
      the YUV image.  Use the TJBUFSIZEYUV(width, height, subsamp) function to
      determine the appropriate size for this buffer based on the image width,
      height, and level of subsampling.
@@ -260,7 +260,7 @@ DLLEXPORT int DLLCALL tjDecompressHeader(tjhandle j,
   [INPUT] srcbuf = pointer to a user-allocated buffer containing the JPEG image
      to decompress
   [INPUT] size = size of the JPEG image buffer (in bytes)
-  [INPUT] dstbuf = pointer to user-allocated image buffer which will receive
+  [INPUT] dstbuf = pointer to user-allocated image buffer that will receive
      the bitmap image.  This buffer should normally be pitch*height
      bytes in size, although this pointer may also be used to decompress into
      a specific region of a larger buffer.
@@ -302,7 +302,7 @@ DLLEXPORT int DLLCALL tjDecompress(tjhandle j,
   [INPUT] srcbuf = pointer to a user-allocated buffer containing the JPEG image
      to decompress
   [INPUT] size = size of the JPEG image buffer (in bytes)
-  [INPUT] dstbuf = pointer to user-allocated image buffer which will receive
+  [INPUT] dstbuf = pointer to user-allocated image buffer that will receive
      the YUV image.  Use the TJBUFSIZEYUV(width, height, subsamp) function to
      determine the appropriate size for this buffer based on the image width,
      height, and level of subsampling.