From 307156de3373574930f8dd5428d58a41082a7f8a Mon Sep 17 00:00:00 2001 From: DRC Date: Tue, 17 Jan 2012 23:09:24 +0000 Subject: [PATCH] Merge wordsmithing/grammar fixes from trunk 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 | 6 +++--- ChangeLog.txt | 18 ++++++++++-------- README-turbo.txt | 22 +++++++++++----------- turbojpeg.h | 14 +++++++------- 4 files changed, 31 insertions(+), 29 deletions(-) diff --git a/BUILDING.txt b/BUILDING.txt index 846e969..70fa400 100644 --- a/BUILDING.txt +++ b/BUILDING.txt @@ -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 diff --git a/ChangeLog.txt b/ChangeLog.txt index fe264d5..00441d2 100644 --- a/ChangeLog.txt +++ b/ChangeLog.txt @@ -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. diff --git a/README-turbo.txt b/README-turbo.txt index fec34e0..a385270 100755 --- a/README-turbo.txt +++ b/README-turbo.txt @@ -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. diff --git a/turbojpeg.h b/turbojpeg.h index 24816d7..1c1e97f 100644 --- a/turbojpeg.h +++ b/turbojpeg.h @@ -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. -- 2.40.0