summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--trunk/Makefile.am4
-rw-r--r--trunk/README257
-rw-r--r--trunk/cjpeg.166
-rw-r--r--trunk/coderules.txt (renamed from trunk/coderules.doc)2
-rw-r--r--trunk/djpeg.14
-rw-r--r--trunk/djpeg.c2
-rw-r--r--trunk/example.c12
-rw-r--r--trunk/filelist.txt (renamed from trunk/filelist.doc)32
-rw-r--r--trunk/install.txt (renamed from trunk/install.doc)129
-rw-r--r--trunk/jconfig.txt (renamed from trunk/jconfig.doc)13
-rw-r--r--trunk/jpeglib.h2
-rw-r--r--trunk/jpegtran.157
-rw-r--r--trunk/libjpeg.txt (renamed from trunk/libjpeg.doc)83
-rw-r--r--trunk/release/libjpeg-turbo.nsi4
-rw-r--r--trunk/release/libjpeg-turbo.spec2
-rwxr-xr-xtrunk/release/makecygwinpkg4
-rw-r--r--trunk/release/makedpkg4
-rw-r--r--trunk/release/makemacpkg4
-rw-r--r--trunk/release/makesunpkg6
-rw-r--r--trunk/structure.txt (renamed from trunk/structure.doc)25
-rw-r--r--trunk/usage.txt (renamed from trunk/usage.doc)96
-rw-r--r--trunk/win/jconfig.h2
-rw-r--r--trunk/wizard.txt (renamed from trunk/wizard.doc)0
23 files changed, 420 insertions, 390 deletions
diff --git a/trunk/Makefile.am b/trunk/Makefile.am
index a32bd99..d1cb698 100644
--- a/trunk/Makefile.am
+++ b/trunk/Makefile.am
@@ -81,8 +81,8 @@ wrjpgcom_LDADD = libjpeg.la
dist_man1_MANS = cjpeg.1 djpeg.1 jpegtran.1 rdjpgcom.1 wrjpgcom.1
-DOCS= README install.doc usage.doc wizard.doc example.c libjpeg.doc \
- structure.doc coderules.doc filelist.doc jconfig.doc change.log \
+DOCS= README install.txt usage.txt wizard.txt example.c libjpeg.txt \
+ structure.txt coderules.txt filelist.txt jconfig.txt change.log \
README-turbo.txt rdrle.c wrrle.c LICENSE.txt LGPL.txt BUILDING.txt \
ChangeLog.txt
diff --git a/trunk/README b/trunk/README
index 22e89b0..921095d 100644
--- a/trunk/README
+++ b/trunk/README
@@ -1,29 +1,20 @@
-libjpeg-turbo note: This is the legacy document from the original libjpeg v6b
-release, which is included for reference. The Internet addresses given below
-are likely non-functional. For more information about the libjpeg project,
-please see http://www.ijg.org. For more information about libjpeg-turbo,
-please see http://libjpeg-turbo.virtualgl.org.
+libjpeg-turbo note: This file is mostly taken from the libjpeg v8b README
+file, and it is included only for reference. Some parts of it may not apply to
+libjpeg-turbo. Please see README-turbo.txt for information specific to the
+turbo version.
The Independent JPEG Group's JPEG software
==========================================
-README for release 6b of 27-Mar-1998
-====================================
+This distribution contains a release of the Independent JPEG Group's free JPEG
+software. You are welcome to redistribute this software and to use it for any
+purpose, subject to the conditions under LEGAL ISSUES, below.
-This distribution contains the sixth public release of the Independent JPEG
-Group's free JPEG software. You are welcome to redistribute this software and
-to use it for any purpose, subject to the conditions under LEGAL ISSUES, below.
-
-Serious users of this software (particularly those incorporating it into
-larger programs) should contact IJG at jpeg-info@uunet.uu.net to be added to
-our electronic mailing list. Mailing list members are notified of updates
-and have a chance to participate in technical discussions, etc.
-
-This software is the work of Tom Lane, Philip Gladstone, Jim Boucher,
-Lee Crocker, Julian Minguillon, Luis Ortiz, George Phillips, Davide Rossi,
-Guido Vollbeding, Ge' Weijers, and other members of the Independent JPEG
-Group.
+This software is the work of Tom Lane, Guido Vollbeding, Philip Gladstone,
+Bill Allombert, Jim Boucher, Lee Crocker, Bob Friesenhahn, Ben Jackson,
+Julian Minguillon, Luis Ortiz, George Phillips, Davide Rossi, Ge' Weijers,
+and other members of the Independent JPEG Group.
IJG is not affiliated with the official ISO JPEG standards committee.
@@ -37,27 +28,26 @@ OVERVIEW General description of JPEG and the IJG software.
LEGAL ISSUES Copyright, lack of warranty, terms of distribution.
REFERENCES Where to learn more about JPEG.
ARCHIVE LOCATIONS Where to find newer versions of this software.
-RELATED SOFTWARE Other stuff you should get.
FILE FORMAT WARS Software *not* to get.
TO DO Plans for future IJG releases.
Other documentation files in the distribution are:
User documentation:
- install.doc How to configure and install the IJG software.
- usage.doc Usage instructions for cjpeg, djpeg, jpegtran,
+ install.txt How to configure and install the IJG software.
+ usage.txt Usage instructions for cjpeg, djpeg, jpegtran,
rdjpgcom, and wrjpgcom.
- *.1 Unix-style man pages for programs (same info as usage.doc).
- wizard.doc Advanced usage instructions for JPEG wizards only.
+ *.1 Unix-style man pages for programs (same info as usage.txt).
+ wizard.txt Advanced usage instructions for JPEG wizards only.
change.log Version-to-version change highlights.
Programmer and internal documentation:
- libjpeg.doc How to use the JPEG library in your own programs.
+ libjpeg.txt How to use the JPEG library in your own programs.
example.c Sample code for calling the JPEG library.
- structure.doc Overview of the JPEG library's internal structure.
- filelist.doc Road map of IJG files.
- coderules.doc Coding style rules --- please read if you contribute code.
+ structure.txt Overview of the JPEG library's internal structure.
+ filelist.txt Road map of IJG files.
+ coderules.txt Coding style rules --- please read if you contribute code.
-Please read at least the files install.doc and usage.doc. Useful information
+Please read at least the files install.txt and usage.txt. Some information
can also be found in the JPEG FAQ (Frequently Asked Questions) article. See
ARCHIVE LOCATIONS below to find out where to obtain the FAQ article.
@@ -69,17 +59,21 @@ the order listed) before diving into the code.
OVERVIEW
========
-This package contains C software to implement JPEG image compression and
-decompression. JPEG (pronounced "jay-peg") is a standardized compression
-method for full-color and gray-scale images. JPEG is intended for compressing
-"real-world" scenes; line drawings, cartoons and other non-realistic images
-are not its strong suit. JPEG is lossy, meaning that the output image is not
-exactly identical to the input image. Hence you must not use JPEG if you
-have to have identical output bits. However, on typical photographic images,
-very good compression levels can be obtained with no visible change, and
-remarkably high compression levels are possible if you can tolerate a
-low-quality image. For more details, see the references, or just experiment
-with various compression settings.
+This package contains C software to implement JPEG image encoding, decoding,
+and transcoding. JPEG (pronounced "jay-peg") is a standardized compression
+method for full-color and gray-scale images. JPEG's strong suit is compressing
+photographic images or other types of images which have smooth color and
+brightness transitions between neighboring pixels. Images with sharp lines or
+other abrupt features may not compress well with JPEG, and a higher JPEG
+quality may have to be used to avoid visible compression artifacts with such
+images.
+
+JPEG is lossy, meaning that the output pixels are not necessarily identical to
+the input pixels. However, on photographic content and other "smooth" images,
+very good compression ratios can be obtained with no visible compression
+artifacts, and extremely high compression ratios are possible if you are
+willing to sacrifice image quality (by reducing the "quality" setting in the
+compressor.)
This software implements JPEG baseline, extended-sequential, and progressive
compression processes. Provision is made for supporting all variants of these
@@ -98,10 +92,11 @@ considerable functionality beyond the bare JPEG coding/decoding capability;
for example, the color quantization modules are not strictly part of JPEG
decoding, but they are essential for output to colormapped file formats or
colormapped displays. These extra functions can be compiled out of the
-library if not required for a particular application. We have also included
-"jpegtran", a utility for lossless transcoding between different JPEG
-processes, and "rdjpgcom" and "wrjpgcom", two simple applications for
-inserting and extracting textual comments in JFIF files.
+library if not required for a particular application.
+
+We have also included "jpegtran", a utility for lossless transcoding between
+different JPEG processes, and "rdjpgcom" and "wrjpgcom", two simple
+applications for inserting and extracting textual comments in JFIF files.
The emphasis in designing this software has been on achieving portability and
flexibility, while also making it fast enough to be useful. In particular,
@@ -134,7 +129,7 @@ with respect to this software, its quality, accuracy, merchantability, or
fitness for a particular purpose. This software is provided "AS IS", and you,
its user, assume the entire risk as to its quality and accuracy.
-This software is copyright (C) 1991-1998, Thomas G. Lane.
+This software is copyright (C) 1991-2010, Thomas G. Lane, Guido Vollbeding.
All Rights Reserved except as specified below.
Permission is hereby granted to use, copy, modify, and distribute this
@@ -177,8 +172,8 @@ the foregoing paragraphs do.
The Unix configuration script "configure" was produced with GNU Autoconf.
It is copyright by the Free Software Foundation but is freely distributable.
The same holds for its supporting scripts (config.guess, config.sub,
-ltconfig, ltmain.sh). Another support script, install-sh, is copyright
-by M.I.T. but is also freely distributable.
+ltmain.sh). Another support script, install-sh, is copyright by X Consortium
+but is also freely distributable.
It appears that the arithmetic coding option of the JPEG spec is covered by
patents owned by IBM, AT&T, and Mitsubishi. Hence arithmetic coding cannot
@@ -205,7 +200,7 @@ We are required to state that
REFERENCES
==========
-We highly recommend reading one or more of these references before trying to
+We recommend reading one or more of these references before trying to
understand the innards of the JPEG software.
The best short technical introduction to the JPEG compression algorithm is
@@ -214,7 +209,7 @@ The best short technical introduction to the JPEG compression algorithm is
(Adjacent articles in that issue discuss MPEG motion picture compression,
applications of JPEG, and related topics.) If you don't have the CACM issue
handy, a PostScript file containing a revised version of Wallace's article is
-available at ftp://ftp.uu.net/graphics/jpeg/wallace.ps.gz. The file (actually
+available at http://www.ijg.org/files/wallace.ps.gz. The file (actually
a preprint for an article that appeared in IEEE Trans. Consumer Electronics)
omits the sample images that appeared in CACM, but it includes corrections
and some added material. Note: the Wallace article is copyright ACM and IEEE,
@@ -229,82 +224,57 @@ code but don't know much about data compression in general. The book's JPEG
sample code is far from industrial-strength, but when you are ready to look
at a full implementation, you've got one here...
-The best full description of JPEG is the textbook "JPEG Still Image Data
-Compression Standard" by William B. Pennebaker and Joan L. Mitchell, published
-by Van Nostrand Reinhold, 1993, ISBN 0-442-01272-1. Price US$59.95, 638 pp.
-The book includes the complete text of the ISO JPEG standards (DIS 10918-1
-and draft DIS 10918-2). This is by far the most complete exposition of JPEG
-in existence, and we highly recommend it.
-
-The JPEG standard itself is not available electronically; you must order a
-paper copy through ISO or ITU. (Unless you feel a need to own a certified
-official copy, we recommend buying the Pennebaker and Mitchell book instead;
-it's much cheaper and includes a great deal of useful explanatory material.)
-In the USA, copies of the standard may be ordered from ANSI Sales at (212)
-642-4900, or from Global Engineering Documents at (800) 854-7179. (ANSI
-doesn't take credit card orders, but Global does.) It's not cheap: as of
-1992, ANSI was charging $95 for Part 1 and $47 for Part 2, plus 7%
-shipping/handling. The standard is divided into two parts, Part 1 being the
-actual specification, while Part 2 covers compliance testing methods. Part 1
-is titled "Digital Compression and Coding of Continuous-tone Still Images,
+The best currently available description of JPEG is the textbook "JPEG Still
+Image Data Compression Standard" by William B. Pennebaker and Joan L.
+Mitchell, published by Van Nostrand Reinhold, 1993, ISBN 0-442-01272-1.
+Price US$59.95, 638 pp. The book includes the complete text of the ISO JPEG
+standards (DIS 10918-1 and draft DIS 10918-2).
+Although this is by far the most detailed and comprehensive exposition of
+JPEG publicly available, we point out that it is still missing an explanation
+of the most essential properties and algorithms of the underlying DCT
+technology.
+
+The original JPEG standard is divided into two parts, Part 1 being the actual
+specification, while Part 2 covers compliance testing methods. Part 1 is
+titled "Digital Compression and Coding of Continuous-tone Still Images,
Part 1: Requirements and guidelines" and has document numbers ISO/IEC IS
10918-1, ITU-T T.81. Part 2 is titled "Digital Compression and Coding of
Continuous-tone Still Images, Part 2: Compliance testing" and has document
numbers ISO/IEC IS 10918-2, ITU-T T.83.
-Some extensions to the original JPEG standard are defined in JPEG Part 3,
-a newer ISO standard numbered ISO/IEC IS 10918-3 and ITU-T T.84. IJG
-currently does not support any Part 3 extensions.
-
The JPEG standard does not specify all details of an interchangeable file
format. For the omitted details we follow the "JFIF" conventions, revision
-1.02. A copy of the JFIF spec is available from:
- Literature Department
- C-Cube Microsystems, Inc.
- 1778 McCarthy Blvd.
- Milpitas, CA 95035
- phone (408) 944-6300, fax (408) 944-6314
-A PostScript version of this document is available by FTP at
-ftp://ftp.uu.net/graphics/jpeg/jfif.ps.gz. There is also a plain text
-version at ftp://ftp.uu.net/graphics/jpeg/jfif.txt.gz, but it is missing
-the figures.
+1.02. JFIF 1.02 has been adopted as an Ecma International Technical Report
+and thus received a formal publication status. It is available as a free
+download in PDF format from
+http://www.ecma-international.org/publications/techreports/E-TR-098.htm.
+A PostScript version of the JFIF document is available at
+http://www.ijg.org/files/jfif.ps.gz. There is also a plain text version at
+http://www.ijg.org/files/jfif.txt.gz, but it is missing the figures.
The TIFF 6.0 file format specification can be obtained by FTP from
ftp://ftp.sgi.com/graphics/tiff/TIFF6.ps.gz. The JPEG incorporation scheme
found in the TIFF 6.0 spec of 3-June-92 has a number of serious problems.
IJG does not recommend use of the TIFF 6.0 design (TIFF Compression tag 6).
Instead, we recommend the JPEG design proposed by TIFF Technical Note #2
-(Compression tag 7). Copies of this Note can be obtained from ftp.sgi.com or
-from ftp://ftp.uu.net/graphics/jpeg/. It is expected that the next revision
+(Compression tag 7). Copies of this Note can be obtained from
+http://www.ijg.org/files/. It is expected that the next revision
of the TIFF spec will replace the 6.0 JPEG design with the Note's design.
Although IJG's own code does not support TIFF/JPEG, the free libtiff library
-uses our library to implement TIFF/JPEG per the Note. libtiff is available
-from ftp://ftp.sgi.com/graphics/tiff/.
+uses our library to implement TIFF/JPEG per the Note.
ARCHIVE LOCATIONS
=================
-The "official" archive site for this software is ftp.uu.net (Internet
-address 192.48.96.9). The most recent released version can always be found
-there in directory graphics/jpeg. This particular version will be archived
-as ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz. If you don't have
-direct Internet access, UUNET's archives are also available via UUCP; contact
-help@uunet.uu.net for information on retrieving files that way.
-
-Numerous Internet sites maintain copies of the UUNET files. However, only
-ftp.uu.net is guaranteed to have the latest official version.
-
-You can also obtain this software in DOS-compatible "zip" archive format from
-the SimTel archives (ftp://ftp.simtel.net/pub/simtelnet/msdos/graphics/), or
-on CompuServe in the Graphics Support forum (GO CIS:GRAPHSUP), library 12
-"JPEG Tools". Again, these versions may sometimes lag behind the ftp.uu.net
-release.
-
-The JPEG FAQ (Frequently Asked Questions) article is a useful source of
-general information about JPEG. It is updated constantly and therefore is
-not included in this distribution. The FAQ is posted every two weeks to
-Usenet newsgroups comp.graphics.misc, news.answers, and other groups.
+The "official" archive site for this software is www.ijg.org.
+The most recent released version can always be found there in
+directory "files". This particular version will be archived as
+http://www.ijg.org/files/jpegsrc.v8b.tar.gz, and in Windows-compatible
+"zip" archive format as http://www.ijg.org/files/jpegsr8b.zip.
+
+The JPEG FAQ (Frequently Asked Questions) article is a source of some
+general information about JPEG.
It is available on the World Wide Web at http://www.faqs.org/faqs/jpeg-faq/
and other news.answers archive sites, including the official news.answers
archive at rtfm.mit.edu: ftp://rtfm.mit.edu/pub/usenet/news.answers/jpeg-faq/.
@@ -314,79 +284,20 @@ with body
send usenet/news.answers/jpeg-faq/part2
-RELATED SOFTWARE
-================
-
-Numerous viewing and image manipulation programs now support JPEG. (Quite a
-few of them use this library to do so.) The JPEG FAQ described above lists
-some of the more popular free and shareware viewers, and tells where to
-obtain them on Internet.
-
-If you are on a Unix machine, we highly recommend Jef Poskanzer's free
-PBMPLUS software, which provides many useful operations on PPM-format image
-files. In particular, it can convert PPM images to and from a wide range of
-other formats, thus making cjpeg/djpeg considerably more useful. The latest
-version is distributed by the NetPBM group, and is available from numerous
-sites, notably ftp://wuarchive.wustl.edu/graphics/graphics/packages/NetPBM/.
-Unfortunately PBMPLUS/NETPBM is not nearly as portable as the IJG software is;
-you are likely to have difficulty making it work on any non-Unix machine.
-
-A different free JPEG implementation, written by the PVRG group at Stanford,
-is available from ftp://havefun.stanford.edu/pub/jpeg/. This program
-is designed for research and experimentation rather than production use;
-it is slower, harder to use, and less portable than the IJG code, but it
-is easier to read and modify. Also, the PVRG code supports lossless JPEG,
-which we do not. (On the other hand, it doesn't do progressive JPEG.)
-
-
FILE FORMAT WARS
================
-Some JPEG programs produce files that are not compatible with our library.
-The root of the problem is that the ISO JPEG committee failed to specify a
-concrete file format. Some vendors "filled in the blanks" on their own,
-creating proprietary formats that no one else could read. (For example, none
-of the early commercial JPEG implementations for the Macintosh were able to
-exchange compressed files.)
-
-The file format we have adopted is called JFIF (see REFERENCES). This format
-has been agreed to by a number of major commercial JPEG vendors, and it has
-become the de facto standard. JFIF is a minimal or "low end" representation.
-We recommend the use of TIFF/JPEG (TIFF revision 6.0 as modified by TIFF
-Technical Note #2) for "high end" applications that need to record a lot of
-additional data about an image. TIFF/JPEG is fairly new and not yet widely
-supported, unfortunately.
-
-The upcoming JPEG Part 3 standard defines a file format called SPIFF.
-SPIFF is interoperable with JFIF, in the sense that most JFIF decoders should
-be able to read the most common variant of SPIFF. SPIFF has some technical
-advantages over JFIF, but its major claim to fame is simply that it is an
-official standard rather than an informal one. At this point it is unclear
-whether SPIFF will supersede JFIF or whether JFIF will remain the de-facto
-standard. IJG intends to support SPIFF once the standard is frozen, but we
-have not decided whether it should become our default output format or not.
-(In any case, our decoder will remain capable of reading JFIF indefinitely.)
-
-Various proprietary file formats incorporating JPEG compression also exist.
-We have little or no sympathy for the existence of these formats. Indeed,
+The ISO JPEG standards committee actually promotes different formats like
+"JPEG 2000" or "JPEG XR" which are incompatible with original DCT-based
+JPEG. IJG therefore does not support these formats (see REFERENCES). Indeed,
one of the original reasons for developing this free software was to help
-force convergence on common, open format standards for JPEG files. Don't
-use a proprietary file format!
+force convergence on common, interoperable format standards for JPEG files.
+Don't use an incompatible file format!
+(In any case, our decoder will remain capable of reading existing JPEG
+image files indefinitely.)
TO DO
=====
-The major thrust for v7 will probably be improvement of visual quality.
-The current method for scaling the quantization tables is known not to be
-very good at low Q values. We also intend to investigate block boundary
-smoothing, "poor man's variable quantization", and other means of improving
-quality-vs-file-size performance without sacrificing compatibility.
-
-In future versions, we are considering supporting some of the upcoming JPEG
-Part 3 extensions --- principally, variable quantization and the SPIFF file
-format.
-
-As always, speeding things up is of great interest.
-
-Please send bug reports, offers of help, etc. to jpeg-info@uunet.uu.net.
+Please send bug reports, offers of help, etc. to jpeg-info@uc.ag.
diff --git a/trunk/cjpeg.1 b/trunk/cjpeg.1
index 3aee807..63a4e39 100644
--- a/trunk/cjpeg.1
+++ b/trunk/cjpeg.1
@@ -1,4 +1,4 @@
-.TH CJPEG 1 "30 December 2009"
+.TH CJPEG 1 "11 October 2010"
.SH NAME
cjpeg \- compress an image file to a JPEG file
.SH SYNOPSIS
@@ -108,33 +108,35 @@ other JPEG programs may be unable to decode the resulting file. Use
.B \-baseline
if you need to ensure compatibility at low quality values.)
.PP
-The
-.B \-quality
-option has been extended in IJG version 7 for support of separate quality
-settings for luminance and chrominance (or in general, for every provided
-quantization table slot). This feature is useful for high-quality
-applications which cannot accept the damage of color data by coarse
-subsampling settings. You can now easily reduce the color data amount more
-smoothly with finer control without separate subsampling. The resulting file
-is fully compliant with standard JPEG decoders.
-Note that the
-.B \-quality
-ratings refer to the quantization table slots, and that the last value is
-replicated if there are more q-table slots than parameters. The default
-q-table slots are 0 for luminance and 1 for chrominance with default tables as
-given in the JPEG standard. This is compatible with the old behaviour in case
-that only one parameter is given, which is then used for both luminance and
-chrominance (slots 0 and 1). More or custom quantization tables can be set
-with
-.B \-qtables
-and assigned to components with
-.B \-qslots
-parameter (see the "wizard" switches below).
-.B Caution:
-You must explicitly add
-.BI \-sample " 1x1"
-for efficient separate color
-quality selection, since the default value used by library is 2x2!
+The \fB-quality\fR option has been extended in this version of \fBcjpeg\fR to
+support separate quality settings for luminance and chrominance (or, in
+general, separate settings for every quantization table slot.) The principle
+is the same as chrominance subsampling: since the human eye is more sensitive
+to spatial changes in brightness than spatial changes in color, the chrominance
+components can be quantized more than the luminance components without
+incurring any visible image quality loss. However, unlike subsampling, this
+feature reduces data in the frequency domain instead of the spatial domain,
+which allows for more fine-grained control. This option is useful in
+quality-sensitive applications, for which the artifacts generated by
+subsampling may be unacceptable.
+.PP
+The \fB-quality\fR option accepts a comma-separated list of parameters, which
+respectively refer to the quality levels which should be assigned to the
+quantization table slots. If there are more q-table slots than parameters,
+then the last parameter is replicated. Thus, if only one quality parameter is
+given, this is used for both luminance and chrominance (slots 0 and 1,
+respectively), preserving the legacy behavior of cjpeg v6b and prior.
+More (or customized) quantization tables can be set with the \fB-qtables\fR
+option and assigned to components with the \fB-qslots\fR option (see the
+"wizard" switches below.)
+.PP
+JPEG files generated with separate luminance and chrominance quality are fully
+compliant with standard JPEG decoders.
+.PP
+.BR CAUTION:
+For this setting to be useful, be sure to pass an argument of \fB-sample 1x1\fR
+to \fBcjpeg\fR to disable chrominance subsampling. Otherwise, the default
+subsampling level (2x2, AKA "4:2:0") will be used.
.PP
The
.B \-progressive
@@ -236,7 +238,7 @@ Use the scan script given in the specified text file.
.PP
The "wizard" switches are intended for experimentation with JPEG. If you
don't know what you are doing, \fBdon't use them\fR. These switches are
-documented further in the file wizard.doc.
+documented further in the file wizard.txt.
.SH EXAMPLES
.LP
This example compresses the PPM file foo.ppm with a quality factor of
@@ -303,8 +305,10 @@ Independent JPEG Group
.SH BUGS
Arithmetic coding is not supported for legal reasons.
.PP
-GIF input files are no longer supported, to avoid the Unisys LZW patent.
-(Conversion of GIF files to JPEG is usually a bad idea anyway.)
+Support for GIF input files was removed in cjpeg v6b due to concerns over
+the Unisys LZW patent. Although this patent expired in 2006, cjpeg still
+lacks GIF support, for these historical reasons. (Conversion of GIF files to
+JPEG is usually a bad idea anyway.)
.PP
Not all variants of BMP and Targa file formats are supported.
.PP
diff --git a/trunk/coderules.doc b/trunk/coderules.txt
index 0ab5d9b..357929f 100644
--- a/trunk/coderules.doc
+++ b/trunk/coderules.txt
@@ -103,7 +103,7 @@ should be in the common data structures.
4. Don't use static variables except for read-only constant tables. Variables
that should be private to a module can be placed into private structures (see
-the system architecture document, structure.doc).
+the system architecture document, structure.txt).
5. Source file names should begin with "j" for files that are part of the
library proper; source files that are not part of the library, such as cjpeg.c
diff --git a/trunk/djpeg.1 b/trunk/djpeg.1
index 11beb6a..8d98c66 100644
--- a/trunk/djpeg.1
+++ b/trunk/djpeg.1
@@ -1,4 +1,4 @@
-.TH DJPEG 1 "22 August 1997"
+.TH DJPEG 1 "11 October 2010"
.SH NAME
djpeg \- decompress a JPEG file to an image file
.SH SYNOPSIS
@@ -249,5 +249,3 @@ To avoid the Unisys LZW patent,
.B djpeg
produces uncompressed GIF files. These are larger than they should be, but
are readable by standard GIF decoders.
-.PP
-Still not as fast as we'd like.
diff --git a/trunk/djpeg.c b/trunk/djpeg.c
index 3f261f1..466973f 100644
--- a/trunk/djpeg.c
+++ b/trunk/djpeg.c
@@ -460,7 +460,7 @@ main (int argc, char **argv)
* APP12 is used by some digital camera makers for textual info,
* so we provide the ability to display it as text.
* If you like, additional APPn marker types can be selected for display,
- * but don't try to override APP0 or APP14 this way (see libjpeg.doc).
+ * but don't try to override APP0 or APP14 this way (see libjpeg.txt).
*/
jpeg_set_marker_processor(&cinfo, JPEG_COM, print_text_marker);
jpeg_set_marker_processor(&cinfo, JPEG_APP0+12, print_text_marker);
diff --git a/trunk/example.c b/trunk/example.c
index 7fc354f..1d6f6cc 100644
--- a/trunk/example.c
+++ b/trunk/example.c
@@ -3,7 +3,7 @@
*
* This file illustrates how to use the IJG code as a subroutine library
* to read or write JPEG image files. You should look at this code in
- * conjunction with the documentation file libjpeg.doc.
+ * conjunction with the documentation file libjpeg.txt.
*
* This code will not do anything useful as-is, but it may be helpful as a
* skeleton for constructing routines that call the JPEG library.
@@ -196,7 +196,7 @@ write_JPEG_file (char * filename, int quality)
* files for anything that doesn't fit within the maximum-memory setting.
* (Note that temp files are NOT needed if you use the default parameters.)
* On some systems you may need to set up a signal handler to ensure that
- * temporary files are deleted if the program is interrupted. See libjpeg.doc.
+ * temporary files are deleted if the program is interrupted. See libjpeg.txt.
*
* Scanlines MUST be supplied in top-to-bottom order if you want your JPEG
* files to be compatible with everyone else's. If you cannot readily read
@@ -335,7 +335,7 @@ read_JPEG_file (char * filename)
/* We can ignore the return value from jpeg_read_header since
* (a) suspension is not possible with the stdio data source, and
* (b) we passed TRUE to reject a tables-only JPEG file as an error.
- * See libjpeg.doc for more info.
+ * See libjpeg.txt for more info.
*/
/* Step 4: set parameters for decompression */
@@ -413,14 +413,14 @@ read_JPEG_file (char * filename)
* In the above code, we ignored the return value of jpeg_read_scanlines,
* which is the number of scanlines actually read. We could get away with
* this because we asked for only one line at a time and we weren't using
- * a suspending data source. See libjpeg.doc for more info.
+ * a suspending data source. See libjpeg.txt for more info.
*
* We cheated a bit by calling alloc_sarray() after jpeg_start_decompress();
* we should have done it beforehand to ensure that the space would be
* counted against the JPEG max_memory setting. In some systems the above
* code would risk an out-of-memory error. However, in general we don't
* know the output image dimensions before jpeg_start_decompress(), unless we
- * call jpeg_calc_output_dimensions(). See libjpeg.doc for more about this.
+ * call jpeg_calc_output_dimensions(). See libjpeg.txt for more about this.
*
* Scanlines are returned in the same order as they appear in the JPEG file,
* which is standardly top-to-bottom. If you must emit data bottom-to-top,
@@ -429,5 +429,5 @@ read_JPEG_file (char * filename)
*
* As with compression, some operating modes may require temporary files.
* On some systems you may need to set up a signal handler to ensure that
- * temporary files are deleted if the program is interrupted. See libjpeg.doc.
+ * temporary files are deleted if the program is interrupted. See libjpeg.txt.
*/
diff --git a/trunk/filelist.doc b/trunk/filelist.txt
index e14982c..a26ffcd 100644
--- a/trunk/filelist.doc
+++ b/trunk/filelist.txt
@@ -1,6 +1,6 @@
IJG JPEG LIBRARY: FILE LIST
-Copyright (C) 1994-1998, Thomas G. Lane.
+Copyright (C) 1994-2010, Thomas G. Lane, Guido Vollbeding, D. R. Commander.
This file is part of the Independent JPEG Group's software.
For conditions of distribution and use, see the accompanying README file.
@@ -75,7 +75,7 @@ jfdctflt.c Forward DCT using floating-point arithmetic.
jchuff.c Huffman entropy coding for sequential JPEG.
jcphuff.c Huffman entropy coding for progressive JPEG.
jcmarker.c JPEG marker writing.
-jdatadst.c Data destination manager for stdio output.
+jdatadst.c Data destination managers for memory and stdio output.
Decompression side of the library:
@@ -98,7 +98,7 @@ jdmerge.c Merged upsampling/color conversion (faster, lower quality).
jquant1.c One-pass color quantization using a fixed-spacing colormap.
jquant2.c Two-pass color quantization using a custom-generated colormap.
Also handles one-pass quantization to an externally given map.
-jdatasrc.c Data source manager for stdio input.
+jdatasrc.c Data source managers for memory and stdio input.
Support files for both compression and decompression:
@@ -118,7 +118,7 @@ jmemdos.c Custom implementation for MS-DOS (16-bit environment only):
jmemmac.c Custom implementation for Apple Macintosh.
Exactly one of the system-dependent modules should be configured into an
-installed JPEG library (see install.doc for hints about which one to use).
+installed JPEG library (see install.txt for hints about which one to use).
On unusual systems you may find it worthwhile to make a special
system-dependent memory manager.
@@ -184,27 +184,27 @@ ADDITIONAL FILES
Documentation (see README for a guide to the documentation files):
README Master documentation file.
-*.doc Other documentation files.
+*.txt Other documentation files.
*.1 Documentation in Unix man page format.
change.log Version-to-version change highlights.
example.c Sample code for calling JPEG library.
-Configuration/installation files and programs (see install.doc for more info):
+Configuration/installation files and programs (see install.txt for more info):
configure Unix shell script to perform automatic configuration.
-ltconfig Support scripts for configure (from GNU libtool).
-ltmain.sh
+configure.ac Source file for use with Autoconf to generate configure.
+ltmain.sh Support scripts for configure (from GNU libtool).
config.guess
config.sub
+depcomp
+missing
install-sh Install shell script for those Unix systems lacking one.
-ckconfig.c Program to generate jconfig.h on non-Unix systems.
-jconfig.doc Template for making jconfig.h by hand.
-makefile.* Sample makefiles for particular systems.
-jconfig.* Sample jconfig.h for particular systems.
-ansi2knr.c De-ANSIfier for pre-ANSI C compilers (courtesy of
- L. Peter Deutsch and Aladdin Enterprises).
-
-Test files (see install.doc for test procedure):
+Makefile.in Makefile input for configure.
+Makefile.am Source file for use with Automake to generate Makefile.in.
+jconfig.txt Template for making jconfig.h by hand.
+aclocal.m4 M4 macro definitions for use with Autoconf.
+
+Test files (see install.txt for test procedure):
test*.* Source and comparison files for confidence test.
These are binary image files, NOT text files.
diff --git a/trunk/install.doc b/trunk/install.txt
index 3702b98..2ee86ad 100644
--- a/trunk/install.doc
+++ b/trunk/install.txt
@@ -1,6 +1,6 @@
INSTALLATION INSTRUCTIONS for the Independent JPEG Group's JPEG software
-Copyright (C) 1991-1998, Thomas G. Lane.
+Copyright (C) 1991-2010, Thomas G. Lane, Guido Vollbeding.
This file is part of the Independent JPEG Group's software.
For conditions of distribution and use, see the accompanying README file.
@@ -94,18 +94,13 @@ Configure was created with GNU Autoconf and it follows the usual conventions
for GNU configure scripts. It makes a few assumptions that you may want to
override. You can do this by providing optional switches to configure:
-* If you want to build libjpeg as a shared library, say
- ./configure --enable-shared
-To get both shared and static libraries, say
- ./configure --enable-shared --enable-static
-Note that these switches invoke GNU libtool to take care of system-dependent
-shared library building methods. If things don't work this way, please try
-running configure without either switch; that should build a static library
-without using libtool. If that works, your problem is probably with libtool
-not with the IJG code. libtool is fairly new and doesn't support all flavors
-of Unix yet. (You might be able to find a newer version of libtool than the
-one included with libjpeg; see ftp.gnu.org. Report libtool problems to
-bug-libtool@gnu.org.)
+* Configure will build both static and shared libraries, if possible.
+If you want to build libjpeg only as a static library, say
+ ./configure --disable-shared
+If you want to build libjpeg only as a shared library, say
+ ./configure --disable-static
+Configure uses GNU libtool to take care of system-dependent shared library
+building methods.
* Configure will use gcc (GNU C compiler) if it's available, otherwise cc.
To force a particular compiler to be selected, use the CC option, for example
@@ -115,10 +110,10 @@ For example, on HP-UX you probably want to say
./configure CC='cc -Aa'
to get HP's compiler to run in ANSI mode.
-* The default CFLAGS setting is "-O" for non-gcc compilers, "-O2" for gcc.
+* The default CFLAGS setting is "-g" for non-gcc compilers, "-g -O2" for gcc.
You can override this by saying, for example,
- ./configure CFLAGS='-g'
-if you want to compile with debugging support.
+ ./configure CFLAGS='-O2'
+if you want to compile without debugging support.
* Configure will set up the makefile so that "make install" will install files
into /usr/local/bin, /usr/local/man, etc. You can specify an installation
@@ -153,7 +148,8 @@ makefile.dj jconfig.dj MS-DOS, DJGPP (Delorie's port of GNU C)
makefile.mc6 jconfig.mc6 MS-DOS, Microsoft C (16-bit only)
makefile.wat jconfig.wat MS-DOS, OS/2, or Windows NT, Watcom C
makefile.vc jconfig.vc Windows NT/95, MS Visual C++
-make*.ds jconfig.vc Windows NT/95, MS Developer Studio
+make*.vc6 jconfig.vc Windows NT/95, MS Visual C++ 6
+make*.v10 jconfig.vc Windows NT/95, MS Visual C++ 2010 (v10)
makefile.mms jconfig.vms Digital VMS, with MMS software
makefile.vms jconfig.vms Digital VMS, without MMS software
@@ -166,8 +162,8 @@ Configuring the software by hand
--------------------------------
First, generate a jconfig.h file. If you are moderately familiar with C,
-the comments in jconfig.doc should be enough information to do this; just
-copy jconfig.doc to jconfig.h and edit it appropriately. Otherwise, you may
+the comments in jconfig.txt should be enough information to do this; just
+copy jconfig.txt to jconfig.h and edit it appropriately. Otherwise, you may
prefer to use the ckconfig.c program. You will need to compile and execute
ckconfig.c by hand --- we hope you know at least enough to do that.
ckconfig.c may not compile the first try (in fact, the whole idea is for it
@@ -447,8 +443,8 @@ on our to-do list.)
The PPM reader (rdppm.c) can read 12-bit data from either text-format or
binary-format PPM and PGM files. Binary-format PPM/PGM files which have a
-maxval greater than 255 are assumed to use 2 bytes per sample, LSB first
-(little-endian order). As of early 1995, 2-byte binary format is not
+maxval greater than 255 are assumed to use 2 bytes per sample, MSB first
+(big-endian order). As of early 1995, 2-byte binary format is not
officially supported by the PBMPLUS library, but it is expected that a
future release of PBMPLUS will support it. Note that the PPM reader will
read files of any maxval regardless of the BITS_IN_JSAMPLE setting; incoming
@@ -521,7 +517,7 @@ that float DCT results may vary slightly across machines.) To do that, add
"#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h. Even if you don't change
the default, you should redefine JDCT_FASTEST, which is the method selected
by djpeg's -fast switch. Don't forget to update the documentation files
-(usage.doc and/or cjpeg.1, djpeg.1) to agree with what you've done.
+(usage.txt and/or cjpeg.1, djpeg.1) to agree with what you've done.
If access to "short" arrays is slow on your machine, it may be a win to
define type JCOEF as int rather than short. This will cost a good deal of
@@ -538,17 +534,17 @@ In general, it's worth trying the maximum optimization level of your compiler,
and experimenting with any optional optimizations such as loop unrolling.
(Unfortunately, far too many compilers have optimizer bugs ... be prepared to
back off if the code fails self-test.) If you do any experimentation along
-these lines, please report the optimal settings to jpeg-info@uunet.uu.net so
-we can mention them in future releases. Be sure to specify your machine and
-compiler version.
+these lines, please report the optimal settings to jpeg-info@uc.ag so we
+can mention them in future releases. Be sure to specify your machine
+and compiler version.
HINTS FOR SPECIFIC SYSTEMS
==========================
We welcome reports on changes needed for systems not mentioned here. Submit
-'em to jpeg-info@uunet.uu.net. Also, if configure or ckconfig.c is wrong
-about how to configure the JPEG software for your system, please let us know.
+'em to jpeg-info@uc.ag. Also, if configure or ckconfig.c is wrong about how
+to configure the JPEG software for your system, please let us know.
Acorn RISC OS:
@@ -568,7 +564,7 @@ Also add a new line '.c.o:; $(cc) $< $(cflags) -c -o $@'. Remove the
lines '$(RM) libjpeg.o' and '$(AR2) libjpeg.o' and the 'jconfig.h'
dependency section.
-Copy jconfig.doc to jconfig.h. Edit jconfig.h to define TWO_FILE_COMMANDLINE
+Copy jconfig.txt to jconfig.h. Edit jconfig.h to define TWO_FILE_COMMANDLINE
and CHAR_IS_UNSIGNED.
Run the makefile using !AMU not !Make. If you want to use the 'clean' and
@@ -587,7 +583,7 @@ manager, with temporary files being created on the device named by
Atari ST/STE/TT:
-
+
Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.st
to cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively. The
project files should work as-is with Pure C. For Turbo C, change library
@@ -610,7 +606,8 @@ or jpegtran.ttp. You'll have to perform the self-test by hand.
We haven't bothered to include project files for rdjpgcom and wrjpgcom.
Those source files should just be compiled by themselves; they don't
-depend on the JPEG library.
+depend on the JPEG library. You can use the default.prj project file
+of the Pure C distribution to make the programs.
There is a bug in some older versions of the Turbo C library which causes the
space used by temporary files created with "tmpfile()" not to be freed after
@@ -872,6 +869,7 @@ Since jmorecfg.h tries to define FAR as empty, you may get a compiler
warning if you include both jpeglib.h and windef.h (which windows.h
includes). To suppress the warning, you can put "#ifndef FAR"/"#endif"
around the line "#define FAR" in jmorecfg.h.
+(Something like this is already in jmorecfg.h, by the way.)
When using the library in a Windows application, you will almost certainly
want to modify or replace the error handler module jerror.c, since our
@@ -890,7 +888,7 @@ jconfig.h to enable it.)
The proper solution for problem 2 is to return control to your calling
application after a library error. This can be done with the setjmp/longjmp
-technique discussed in libjpeg.doc and illustrated in example.c. (NOTE:
+technique discussed in libjpeg.txt and illustrated in example.c. (NOTE:
some older Windows C compilers provide versions of setjmp/longjmp that
don't actually work under Windows. You may need to use the Windows system
functions Catch and Throw instead.)
@@ -1000,32 +998,67 @@ model. makefile.vc is intended for command-line use. (If you are using
the Developer Studio environment, you may prefer the DevStudio project
files; see below.)
-Some users feel that it's easier to call the library from C++ code if you
-force VC++ to treat the library as C++ code, which you can do by renaming
-all the *.c files to *.cpp (and adjusting the makefile to match). This
-avoids the need to put extern "C" { ... } around #include "jpeglib.h" in
-your C++ application.
+IJG JPEG 7 adds extern "C" to jpeglib.h. This avoids the need to put
+extern "C" { ... } around #include "jpeglib.h" in your C++ application.
+You can also force VC++ to treat the library as C++ code by renaming
+all the *.c files to *.cpp (and adjusting the makefile to match).
+In this case you also need to define the symbol DONT_USE_EXTERN_C in
+the configuration to prevent jpeglib.h from using extern "C".
-Microsoft Windows, Microsoft Developer Studio:
+Microsoft Windows, Microsoft Visual C++ 6 Developer Studio:
-We include makefiles that should work as project files in DevStudio 4.2 or
+We include makefiles that should work as project files in DevStudio 6.0 or
later. There is a library makefile that builds the IJG library as a static
-Win32 library, and an application makefile that builds the sample applications
+Win32 library, and application makefiles that build the sample applications
as Win32 console applications. (Even if you only want the library, we
recommend building the applications so that you can run the self-test.)
To use:
-1. Copy jconfig.vc to jconfig.h, makelib.ds to jpeg.mak, and
- makeapps.ds to apps.mak. (Note that the renaming is critical!)
-2. Click on the .mak files to construct project workspaces.
- (If you are using DevStudio more recent than 4.2, you'll probably
- get a message saying that the makefiles are being updated.)
-3. Build the library project, then the applications project.
-4. Move the application .exe files from `app`\Release to an
+1. Open the command prompt, change to the main directory and execute the
+ command line
+ NMAKE /f makefile.vc setup-vc6
+ This will move jconfig.vc to jconfig.h and makefiles to project files.
+ (Note that the renaming is critical!)
+2. Open the workspace file jpeg.dsw, build the library project.
+ (If you are using DevStudio more recent than 6.0, you'll probably
+ get a message saying that the project files are being updated.)
+3. Open the workspace file apps.dsw, build the application projects.
+4. To perform the self-test, execute the command line
+ NMAKE /f makefile.vc test-build
+5. Move the application .exe files from `app`\Release to an
+ appropriate location on your path.
+
+
+Microsoft Windows, Microsoft Visual C++ 2010 Developer Studio (v10):
+
+We include makefiles that should work as project files in Visual Studio
+2010 or later. There is a library makefile that builds the IJG library
+as a static Win32 library, and application makefiles that build the sample
+applications as Win32 console applications. (Even if you only want the
+library, we recommend building the applications so that you can run the
+self-test.)
+
+To use:
+1. Open the command prompt, change to the main directory and execute the
+ command line
+ NMAKE /f makefile.vc setup-v10
+ This will move jconfig.vc to jconfig.h and makefiles to project files.
+ (Note that the renaming is critical!)
+2. Open the solution file jpeg.sln, build the library project.
+ (If you are using Visual Studio more recent than 2010 (v10), you'll
+ probably get a message saying that the project files are being updated.)
+3. Open the solution file apps.sln, build the application projects.
+4. To perform the self-test, execute the command line
+ NMAKE /f makefile.vc test-build
+5. Move the application .exe files from `app`\Release to an
appropriate location on your path.
-5. To perform the self-test, execute the command line
- NMAKE /f makefile.vc test
+
+Note:
+There seems to be an optimization bug in the compiler which causes the
+self-test to fail with the color quantization option.
+We have disabled optimization for the file jquant2.c in the library
+project file which causes the self-test to pass properly.
OS/2, Borland C++:
diff --git a/trunk/jconfig.doc b/trunk/jconfig.txt
index c18d1c0..b96d312 100644
--- a/trunk/jconfig.doc
+++ b/trunk/jconfig.txt
@@ -1,5 +1,5 @@
/*
- * jconfig.doc
+ * jconfig.txt
*
* Copyright (C) 1991-1994, Thomas G. Lane.
* This file is part of the Independent JPEG Group's software.
@@ -24,7 +24,7 @@
*/
/* Does your compiler support function prototypes?
- * (If not, you also need to use ansi2knr, see install.doc)
+ * (If not, you also need to use ansi2knr, see install.txt)
*/
#define HAVE_PROTOTYPES
@@ -91,6 +91,15 @@
*/
#undef INCOMPLETE_TYPES_BROKEN
+/* Define "boolean" as unsigned char, not int, on Windows systems.
+ */
+#ifdef _WIN32
+#ifndef __RPCNDR_H__ /* don't conflict if rpcndr.h already read */
+typedef unsigned char boolean;
+#endif
+#define HAVE_BOOLEAN /* prevent jmorecfg.h from redefining it */
+#endif
+
/*
* The following options affect code selection within the JPEG library,
diff --git a/trunk/jpeglib.h b/trunk/jpeglib.h
index b4e1fd2..cb3acaf 100644
--- a/trunk/jpeglib.h
+++ b/trunk/jpeglib.h
@@ -1041,7 +1041,7 @@ EXTERN(JDIMENSION) jpeg_write_raw_data JPP((j_compress_ptr cinfo,
JSAMPIMAGE data,
JDIMENSION num_lines));
-/* Write a special marker. See libjpeg.doc concerning safe usage. */
+/* Write a special marker. See libjpeg.txt concerning safe usage. */
EXTERN(void) jpeg_write_marker
JPP((j_compress_ptr cinfo, int marker,
const JOCTET * dataptr, unsigned int datalen));
diff --git a/trunk/jpegtran.1 b/trunk/jpegtran.1
index 355e4da..66d2f9f 100644
--- a/trunk/jpegtran.1
+++ b/trunk/jpegtran.1
@@ -1,4 +1,4 @@
-.TH JPEGTRAN 1 "28 December 2009"
+.TH JPEGTRAN 1 "11 October 2010"
.SH NAME
jpegtran \- lossless transformation of JPEG files
.SH SYNOPSIS
@@ -91,12 +91,12 @@ Transpose image (across UL-to-LR axis).
.TP
.B \-transverse
Transverse transpose (across UR-to-LL axis).
-.IP
+.PP
The transpose transformation has no restrictions regarding image dimensions.
The other transformations operate rather oddly if the image dimensions are not
a multiple of the iMCU size (usually 8 or 16 pixels), because they can only
transform complete blocks of DCT coefficient data in the desired way.
-.IP
+.PP
.BR jpegtran 's
default behavior when transforming an odd-size image is designed
to preserve exact reversibility and mathematical consistency of the
@@ -108,7 +108,7 @@ able to flip all columns. The other transforms can be built up as sequences
of transpose and flip operations; for consistency, their actions on edge
pixels are defined to be the same as the end result of the corresponding
transpose-and-flip sequence.
-.IP
+.PP
For practical use, you may prefer to discard any untransformable edge pixels
rather than having a strange-looking strip along the right and/or bottom edges
of a transformed image. To do this, add the
@@ -130,15 +130,15 @@ trims only the bottom edge, but
followed by
.B \-rot 180 -trim
trims both edges.
-.IP
-If you are only interested in perfect transformation, add the
-.B \-perfect
-switch:
.TP
.B \-perfect
-Fails with an error if the transformation is not perfect.
+If you are only interested in perfect transformations, add the
+.B \-perfect
+switch. This causes
+.B jpegtran
+to fail with an error if the transformation is not perfect.
.IP
-For example you may want to do
+For example, you may want to do
.IP
.B (jpegtran \-rot 90 -perfect
.I foo.jpg
@@ -146,21 +146,16 @@ For example you may want to do
.I foo.jpg
.B | pnmflip \-r90 | cjpeg)
.IP
-to do a perfect rotation if available or an approximated one if not.
-.PP
-We also offer a lossless-crop option, which discards data outside a given
-image region but losslessly preserves what is inside. Like the rotate and
-flip transforms, lossless crop is restricted by the current JPEG format: the
-upper left corner of the selected region must fall on an iMCU boundary. If
-this does not hold for the given crop parameters, we silently move the upper
-left corner up and/or left to make it so, simultaneously increasing the region
-dimensions to keep the lower right crop corner unchanged. (Thus, the output
-image covers at least the requested region, but may cover more.)
-
-The image can be losslessly cropped by giving the switch:
+to do a perfect rotation, if available, or an approximated one if not.
.TP
.B \-crop WxH+X+Y
-Crop to a rectangular subarea of width W, height H starting at point X,Y.
+Crop the image to a rectangular region of width W and height H, starting at
+point X,Y. The lossless crop feature discards data outside of a given image
+region but losslessly preserves what is inside. Like the rotate and flip
+transforms, lossless crop is restricted by the current JPEG format; the upper
+left corner of the selected region must fall on an iMCU boundary. If it
+doesn't, then it is silently moved up and/or left to the nearest iMCU boundary
+(the lower right corner is unchanged.)
.PP
Other not-strictly-lossless transformation switches are:
.TP
@@ -185,20 +180,16 @@ Copy no extra markers from source file. This setting suppresses all
comments and other excess baggage present in the source file.
.TP
.B \-copy comments
-Copy only comment markers. This setting copies comments from the source file,
-but discards any other inessential (for image display) data.
+Copy only comment markers. This setting copies comments from the source file
+but discards any other data which is inessential for image display.
.TP
.B \-copy all
Copy all extra markers. This setting preserves miscellaneous markers
found in the source file, such as JFIF thumbnails, Exif data, and Photoshop
-settings. In some files these extra markers can be sizable.
-.IP
-The default behavior is
-.BR "\-copy comments" .
-(Note: in IJG releases v6 and v6a,
-.B jpegtran
-always did the equivalent of
-.BR "\-copy none" .)
+settings. In some files, these extra markers can be sizable.
+.PP
+The default behavior is \fB-copy comments\fR. (Note: in IJG releases v6 and
+v6a, \fBjpegtran\fR always did the equivalent of \fB-copy none\fR.)
.PP
Additional switches recognized by jpegtran are:
.TP
diff --git a/trunk/libjpeg.doc b/trunk/libjpeg.txt
index 689b206..f8ec519 100644
--- a/trunk/libjpeg.doc
+++ b/trunk/libjpeg.txt
@@ -1,6 +1,6 @@
USING THE IJG JPEG LIBRARY
-Copyright (C) 1994-1998, Thomas G. Lane.
+Copyright (C) 1994-2010, Thomas G. Lane, Guido Vollbeding, D. R. Commander.
This file is part of the Independent JPEG Group's software.
For conditions of distribution and use, see the accompanying README file.
@@ -750,7 +750,7 @@ is to prepare a library file ("libjpeg.a", or a corresponding name on non-Unix
machines) and reference it at your link step. If you use only half of the
library (only compression or only decompression), only that much code will be
included from the library, unless your linker is hopelessly brain-damaged.
-The supplied makefiles build libjpeg.a automatically (see install.doc).
+The supplied makefiles build libjpeg.a automatically (see install.txt).
While you can build the JPEG library as a shared library if the whim strikes
you, we don't really recommend it. The trouble with shared libraries is that
@@ -850,6 +850,10 @@ int jpeg_quality_scaling (int quality)
can't be expressed as a simple scalar multiplier, in which case the
premise of this routine collapses. Caveat user.
+jpeg_default_qtables (j_compress_ptr cinfo, boolean force_baseline)
+ [libjpeg v7/v8 only] Set default quantization tables with linear
+ q_scale_factor[] values (see below).
+
jpeg_add_quant_table (j_compress_ptr cinfo, int which_tbl,
const unsigned int *basic_table,
int scale_factor, boolean force_baseline)
@@ -972,6 +976,32 @@ JQUANT_TBL * quant_tbl_ptrs[NUM_QUANT_TBLS]
routines will set up table slot 0 for luminance quality and table
slot 1 for chrominance.
+int q_scale_factor[NUM_QUANT_TBLS]
+ [libjpeg v7+ only] Linear quantization scaling factors (0-100, default
+ 100) for use with jpeg_default_qtables().
+ See rdswitch.c and cjpeg.c for an example of usage.
+ Note that the q_scale_factor[] values use "linear" scales, so JPEG
+ quality levels chosen by the user must be converted to these scales
+ using jpeg_quality_scaling(). Here is an example which corresponds to
+ cjpeg -quality 90,70:
+
+ jpeg_set_defaults(cinfo);
+
+ /* Set luminance quality 90. */
+ cinfo->q_scale_factor[0] = jpeg_quality_scaling(90);
+ /* Set chrominance quality 70. */
+ cinfo->q_scale_factor[1] = jpeg_quality_scaling(70);
+
+ jpeg_default_qtables(cinfo, force_baseline);
+
+ CAUTION: Setting separate quality levels for chrominance and luminance
+ is mainly only useful if chrominance subsampling is disabled. 2x2
+ chrominance subsampling (AKA "4:2:0") is the default, but you can
+ explicitly disable subsampling as follows:
+
+ cinfo->comp_info[0].v_samp_factor = 1;
+ cinfo->comp_info[0].h_samp_factor = 1;
+
JHUFF_TBL * dc_huff_tbl_ptrs[NUM_HUFF_TBLS]
JHUFF_TBL * ac_huff_tbl_ptrs[NUM_HUFF_TBLS]
Pointers to Huffman coding tables, one per table slot, or NULL if
@@ -982,6 +1012,17 @@ JHUFF_TBL * ac_huff_tbl_ptrs[NUM_HUFF_TBLS]
by setting optimize_coding, as discussed above; there's seldom
any need to mess with providing your own Huffman tables.
+
+[libjpeg v7+ only] The actual dimensions of the JPEG image that will be written
+to the file are given by the following fields. These are computed from the
+input image dimensions and the compression parameters by jpeg_start_compress().
+You can also call jpeg_calc_jpeg_dimensions() to obtain the values that will
+result from the current parameter settings.
+
+JDIMENSION jpeg_width Actual dimensions of output image.
+JDIMENSION jpeg_height
+
+
There are some additional cinfo fields which are not documented here
because you currently can't change them; for example, you can't set
arith_code TRUE because arithmetic coding is unsupported.
@@ -1374,21 +1415,22 @@ Compressed data handling (source and destination managers)
The JPEG compression library sends its compressed data to a "destination
manager" module. The default destination manager just writes the data to a
-stdio stream, but you can provide your own manager to do something else.
-Similarly, the decompression library calls a "source manager" to obtain the
-compressed data; you can provide your own source manager if you want the data
-to come from somewhere other than a stdio stream.
+memory buffer or to a stdio stream, but you can provide your own manager to
+do something else. Similarly, the decompression library calls a "source
+manager" to obtain the compressed data; you can provide your own source
+manager if you want the data to come from somewhere other than a memory
+buffer or a stdio stream.
In both cases, compressed data is processed a bufferload at a time: the
destination or source manager provides a work buffer, and the library invokes
the manager only when the buffer is filled or emptied. (You could define a
one-character buffer to force the manager to be invoked for each byte, but
that would be rather inefficient.) The buffer's size and location are
-controlled by the manager, not by the library. For example, if you desired to
-decompress a JPEG datastream that was all in memory, you could just make the
-buffer pointer and length point to the original data in memory. Then the
-buffer-reload procedure would be invoked only if the decompressor ran off the
-end of the datastream, which would indicate an erroneous datastream.
+controlled by the manager, not by the library. For example, the memory
+source manager just makes the buffer pointer and length point to the original
+data in memory. In this case the buffer-reload procedure will be invoked
+only if the decompressor ran off the end of the datastream, which would
+indicate an erroneous datastream.
The work buffer is defined as an array of datatype JOCTET, which is generally
"char" or "unsigned char". On a machine where char is not exactly 8 bits
@@ -1440,7 +1482,8 @@ You will also need code to create a jpeg_destination_mgr struct, fill in its
method pointers, and insert a pointer to the struct into the "dest" field of
the JPEG compression object. This can be done in-line in your setup code if
you like, but it's probably cleaner to provide a separate routine similar to
-the jpeg_stdio_dest() routine of the supplied destination manager.
+the jpeg_stdio_dest() or jpeg_mem_dest() routines of the supplied destination
+managers.
Decompression source managers follow a parallel design, but with some
additional frammishes. The source manager struct contains a pointer and count
@@ -1516,10 +1559,10 @@ You will also need code to create a jpeg_source_mgr struct, fill in its method
pointers, and insert a pointer to the struct into the "src" field of the JPEG
decompression object. This can be done in-line in your setup code if you
like, but it's probably cleaner to provide a separate routine similar to the
-jpeg_stdio_src() routine of the supplied source manager.
+jpeg_stdio_src() or jpeg_mem_src() routines of the supplied source managers.
-For more information, consult the stdio source and destination managers
-in jdatasrc.c and jdatadst.c.
+For more information, consult the memory and stdio source and destination
+managers in jdatasrc.c and jdatadst.c.
I/O suspension
@@ -2608,7 +2651,7 @@ entire image into a set of virtual coefficient-block arrays, one array per
component. The return value is a pointer to an array of virtual-array
descriptors. Each virtual array can be accessed directly using the JPEG
memory manager's access_virt_barray method (see Memory management, below,
-and also read structure.doc's discussion of virtual array handling). Or,
+and also read structure.txt's discussion of virtual array handling). Or,
for simple transcoding to a different JPEG file format, the array list can
just be handed directly to jpeg_write_coefficients().
@@ -2752,7 +2795,7 @@ Memory management
-----------------
This section covers some key facts about the JPEG library's built-in memory
-manager. For more info, please read structure.doc's section about the memory
+manager. For more info, please read structure.txt's section about the memory
manager, and consult the source code if necessary.
All memory and temporary file allocation within the library is done via the
@@ -2867,7 +2910,7 @@ BITS_IN_JSAMPLE as 12 rather than 8. Note that this causes JSAMPLE to be
larger than a char, so it affects the surrounding application's image data.
The sample applications cjpeg and djpeg can support 12-bit mode only for PPM
and GIF file formats; you must disable the other file formats to compile a
-12-bit cjpeg or djpeg. (install.doc has more information about that.)
+12-bit cjpeg or djpeg. (install.txt has more information about that.)
At present, a 12-bit library can handle *only* 12-bit images, not both
precisions. (If you need to include both 8- and 12-bit libraries in a single
application, you could probably do it by defining NEED_SHORT_EXTERNAL_NAMES
@@ -2920,7 +2963,7 @@ about them.)
The code works fine on ANSI C, C++, and pre-ANSI C compilers, using any of
the popular system include file setups, and some not-so-popular ones too.
-See install.doc for configuration procedures.
+See install.txt for configuration procedures.
The code is not dependent on the exact sizes of the C data types. As
distributed, we make the assumptions that
@@ -2959,7 +3002,7 @@ The code generally assumes that C names must be unique in the first 15
characters. However, global function names can be made unique in the
first 6 characters by defining NEED_SHORT_EXTERNAL_NAMES.
-More info about porting the code may be gleaned by reading jconfig.doc,
+More info about porting the code may be gleaned by reading jconfig.txt,
jmorecfg.h, and jinclude.h.
diff --git a/trunk/release/libjpeg-turbo.nsi b/trunk/release/libjpeg-turbo.nsi
index e944466..c4137b3 100644
--- a/trunk/release/libjpeg-turbo.nsi
+++ b/trunk/release/libjpeg-turbo.nsi
@@ -66,7 +66,7 @@ Section "libjpeg-turbo SDK for ${PLATFORM} (required)"
SetOutPath $INSTDIR
File "${WSRCDIR}\README"
File "${WSRCDIR}\README-turbo.txt"
- File "${WSRCDIR}\libjpeg.doc"
+ File "${WSRCDIR}\libjpeg.txt"
File "${WSRCDIR}\LGPL.txt"
File "${WSRCDIR}\LICENSE.txt"
@@ -114,7 +114,7 @@ Section "Uninstall"
Delete $INSTDIR\uninstall_${VERSION}.exe
Delete $INSTDIR\README
Delete $INSTDIR\README-turbo.txt
- Delete $INSTDIR\libjpeg.doc
+ Delete $INSTDIR\libjpeg.txt
Delete $INSTDIR\LGPL.txt
Delete $INSTDIR\LICENSE.txt
diff --git a/trunk/release/libjpeg-turbo.spec b/trunk/release/libjpeg-turbo.spec
index b58ced0..0ff7211 100644
--- a/trunk/release/libjpeg-turbo.spec
+++ b/trunk/release/libjpeg-turbo.spec
@@ -69,7 +69,7 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
-%doc %{_srcdir}/README-turbo.txt %{_srcdir}/README %{_srcdir}/libjpeg.doc %{_srcdir}/usage.doc %{_srcdir}/LICENSE.txt %{_srcdir}/LGPL.txt
+%doc %{_srcdir}/README-turbo.txt %{_srcdir}/README %{_srcdir}/libjpeg.txt %{_srcdir}/usage.txt %{_srcdir}/LICENSE.txt %{_srcdir}/LGPL.txt
%dir /opt/%{name}
%dir /opt/%{name}/bin
/opt/%{name}/bin/cjpeg
diff --git a/trunk/release/makecygwinpkg b/trunk/release/makecygwinpkg
index 981cd9e..3ed1a40 100755
--- a/trunk/release/makecygwinpkg
+++ b/trunk/release/makecygwinpkg
@@ -36,8 +36,8 @@ DOCDIR=$TMPDIR/pkg/usr/share/doc/$PACKAGE_NAME-$VERSION
mkdir -p $DOCDIR
install -m 644 $SRCDIR/README-turbo.txt $DOCDIR
install -m 644 $SRCDIR/README $DOCDIR
-install -m 644 $SRCDIR/libjpeg.doc $DOCDIR
-install -m 644 $SRCDIR/usage.doc $DOCDIR
+install -m 644 $SRCDIR/libjpeg.txt $DOCDIR
+install -m 644 $SRCDIR/usage.txt $DOCDIR
install -m 644 $SRCDIR/LICENSE.txt $DOCDIR
install -m 644 $SRCDIR/LGPL.txt $DOCDIR
ln -fs lib $TMPDIR/pkg/opt/$PACKAGE_NAME/lib32
diff --git a/trunk/release/makedpkg b/trunk/release/makedpkg
index ec4e195..f565464 100644
--- a/trunk/release/makedpkg
+++ b/trunk/release/makedpkg
@@ -73,8 +73,8 @@ makedeb()
install -m 644 $SRCDIR/LGPL.txt $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
install -m 644 $SRCDIR/README-turbo.txt $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
install -m 644 $SRCDIR/README $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
- install -m 644 $SRCDIR/libjpeg.doc $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
- install -m 644 $SRCDIR/usage.doc $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
+ install -m 644 $SRCDIR/libjpeg.txt $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
+ install -m 644 $SRCDIR/usage.txt $TMPDIR/usr/share/doc/$DIRNAME-$VERSION
fi
sudo chown -Rh root:root $TMPDIR/*
diff --git a/trunk/release/makemacpkg b/trunk/release/makemacpkg
index 6307e88..b1fb90e 100644
--- a/trunk/release/makemacpkg
+++ b/trunk/release/makemacpkg
@@ -136,8 +136,8 @@ install -m 644 $SRCDIR/LICENSE.txt $PKGROOT/Library/Documentation/$PACKAGE_NAME/
install -m 644 $SRCDIR/LGPL.txt $PKGROOT/Library/Documentation/$PACKAGE_NAME/LGPL.txt
install -m 644 $SRCDIR/README-turbo.txt $PKGROOT/Library/Documentation/$PACKAGE_NAME/README-turbo.txt
install -m 644 $SRCDIR/README $PKGROOT/Library/Documentation/$PACKAGE_NAME/README
-install -m 644 $SRCDIR/libjpeg.doc $PKGROOT/Library/Documentation/$PACKAGE_NAME/libjpeg.doc
-install -m 644 $SRCDIR/usage.doc $PKGROOT/Library/Documentation/$PACKAGE_NAME/usage.doc
+install -m 644 $SRCDIR/libjpeg.txt $PKGROOT/Library/Documentation/$PACKAGE_NAME/libjpeg.txt
+install -m 644 $SRCDIR/usage.txt $PKGROOT/Library/Documentation/$PACKAGE_NAME/usage.txt
sudo chown -R root:admin $PKGROOT
sudo chown -R root:0 $PKGROOT/usr
diff --git a/trunk/release/makesunpkg b/trunk/release/makesunpkg
index 2bc40d4..d921d96 100644
--- a/trunk/release/makesunpkg
+++ b/trunk/release/makesunpkg
@@ -64,7 +64,7 @@ fi
make install DESTDIR=$TMPDIR libdir=/opt/$PACKAGE_NAME/$__LIB mandir=/opt/$PACKAGE_NAME/man AM_MAKEFLAGS="libdir=/opt/$PACKAGE_NAME/$__LIB mandir=/opt/$PACKAGE_NAME/man"
rm -f $TMPDIR/opt/$PACKAGE_NAME/$__LIB/*.la
mkdir -p $TMPDIR/opt/$PACKAGE_NAME/doc
-cp $SRCDIR/LICENSE.txt $SRCDIR/LGPL.txt $SRCDIR/README-turbo.txt $SRCDIR/README $SRCDIR/libjpeg.doc $SRCDIR/usage.doc $TMPDIR/opt/$PACKAGE_NAME/doc
+cp $SRCDIR/LICENSE.txt $SRCDIR/LGPL.txt $SRCDIR/README-turbo.txt $SRCDIR/README $SRCDIR/libjpeg.txt $SRCDIR/usage.txt $TMPDIR/opt/$PACKAGE_NAME/doc
chmod 644 $TMPDIR/opt/$PACKAGE_NAME/doc/*
cat >$TMPDIR/proto <<EOF
@@ -118,11 +118,11 @@ f none $PACKAGE_NAME/include/jpeglib.h 0644 root bin
f none $PACKAGE_NAME/include/turbojpeg.h 0644 root bin
d none $PACKAGE_NAME/doc 0755 root bin
f none $PACKAGE_NAME/doc/LGPL.txt 0644 root bin
-f none $PACKAGE_NAME/doc/libjpeg.doc 0644 root bin
+f none $PACKAGE_NAME/doc/libjpeg.txt 0644 root bin
f none $PACKAGE_NAME/doc/LICENSE.txt 0644 root bin
f none $PACKAGE_NAME/doc/README 0644 root bin
f none $PACKAGE_NAME/doc/README-turbo.txt 0644 root bin
-f none $PACKAGE_NAME/doc/usage.doc 0644 root bin
+f none $PACKAGE_NAME/doc/usage.txt 0644 root bin
EOF
pkgmk -o -r $TMPDIR/opt -d $TMPDIR -a i386 -f $TMPDIR/proto
diff --git a/trunk/structure.doc b/trunk/structure.txt
index 51c9def..09e1cd2 100644
--- a/trunk/structure.doc
+++ b/trunk/structure.txt
@@ -1,6 +1,6 @@
IJG JPEG LIBRARY: SYSTEM ARCHITECTURE
-Copyright (C) 1991-1995, Thomas G. Lane.
+Copyright (C) 1991-2009, Thomas G. Lane, Guido Vollbeding.
This file is part of the Independent JPEG Group's software.
For conditions of distribution and use, see the accompanying README file.
@@ -12,9 +12,9 @@ convention, see the include files and comments in the source code.
We assume that the reader is already somewhat familiar with the JPEG standard.
The README file includes references for learning about JPEG. The file
-libjpeg.doc describes the library from the viewpoint of an application
+libjpeg.txt describes the library from the viewpoint of an application
programmer using the library; it's best to read that file before this one.
-Also, the file coderules.doc describes the coding style conventions we use.
+Also, the file coderules.txt describes the coding style conventions we use.
In this document, JPEG-specific terminology follows the JPEG standard:
A "component" means a color channel, e.g., Red or Luminance.
@@ -541,7 +541,7 @@ section needs more data.) In this way the application can avoid making
extra display passes when data is arriving faster than the display pass
can run. Furthermore, it is possible to abort an output pass without
losing anything, since the coefficient buffer is read-only as far as the
-output section is concerned. See libjpeg.doc for more detail.
+output section is concerned. See libjpeg.txt for more detail.
A full-image coefficient array is only created if the JPEG file has multiple
scans (or if the application specifies buffered-image mode anyway). When
@@ -685,7 +685,7 @@ then resume compression or decompression at a later time.
This scenario is supported for simple cases. (For anything more complex, we
recommend that the application "bite the bullet" and develop real multitasking
-capability.) The libjpeg.doc file goes into more detail about the usage and
+capability.) The libjpeg.txt file goes into more detail about the usage and
limitations of this capability; here we address the implications for library
structure.
@@ -733,13 +733,14 @@ to bypass COM and APPn markers, so these can be larger than the buffer size
without causing problems; otherwise a 64K buffer would be needed in the worst
case.)
-The JPEG marker writer currently does *not* cope with suspension. I feel that
-this is not necessary; it is much easier simply to require the application to
-ensure there is enough buffer space before starting. (An empty 2K buffer is
-more than sufficient for the header markers; and ensuring there are a dozen or
-two bytes available before calling jpeg_finish_compress() will suffice for the
-trailer.) This would not work for writing multi-scan JPEG files, but
-we simply do not intend to support that capability with suspension.
+The JPEG marker writer currently does *not* cope with suspension.
+We feel that this is not necessary; it is much easier simply to require
+the application to ensure there is enough buffer space before starting. (An
+empty 2K buffer is more than sufficient for the header markers; and ensuring
+there are a dozen or two bytes available before calling jpeg_finish_compress()
+will suffice for the trailer.) This would not work for writing multi-scan
+JPEG files, but we simply do not intend to support that capability with
+suspension.
*** Memory manager services ***
diff --git a/trunk/usage.doc b/trunk/usage.txt
index 8c4970a..0519b94 100644
--- a/trunk/usage.doc
+++ b/trunk/usage.txt
@@ -12,19 +12,9 @@ pages in files cjpeg.1, djpeg.1, jpegtran.1, rdjpgcom.1, wrjpgcom.1.
INTRODUCTION
-These programs implement JPEG image compression and decompression. JPEG
-(pronounced "jay-peg") is a standardized compression method for full-color
-and gray-scale images. JPEG is designed to handle "real-world" scenes,
-for example scanned photographs. Cartoons, line drawings, and other
-non-realistic images are not JPEG's strong suit; on that sort of material
-you may get poor image quality and/or little compression.
-
-JPEG is lossy, meaning that the output image is not necessarily identical to
-the input image. Hence you should not use JPEG if you have to have identical
-output bits. However, on typical real-world images, very good compression
-levels can be obtained with no visible change, and amazingly high compression
-is possible if you can tolerate a low-quality image. You can trade off image
-quality against file size by adjusting the compressor's "quality" setting.
+These programs implement JPEG image encoding, decoding, and transcoding.
+JPEG (pronounced "jay-peg") is a standardized compression method for
+full-color and gray-scale images.
GENERAL USAGE
@@ -48,7 +38,7 @@ or
i.e., both the input and output files are named on the command line. This
style is a little more foolproof, and it loses no functionality if you don't
have pipes. (You can get this style on Unix too, if you prefer, by defining
-TWO_FILE_COMMANDLINE when you compile the programs; see install.doc.)
+TWO_FILE_COMMANDLINE when you compile the programs; see install.txt.)
You can also say:
cjpeg [switches] -outfile jpegfile imagefile
@@ -76,7 +66,7 @@ CJPEG DETAILS
The basic command line switches for cjpeg are:
- -quality N Scale quantization tables to adjust image quality.
+ -quality N[,...] Scale quantization tables to adjust image quality.
Quality is 0 (worst) to 100 (best); default is 75.
(See below for more info.)
@@ -128,15 +118,42 @@ cjpeg emits a warning message when you give such a quality value, because some
other JPEG programs may be unable to decode the resulting file. Use -baseline
if you need to ensure compatibility at low quality values.)
+The -quality option has been extended in this version of cjpeg to support
+separate quality settings for luminance and chrominance (or, in general,
+separate settings for every quantization table slot.) The principle is the
+same as chrominance subsampling: since the human eye is more sensitive to
+spatial changes in brightness than spatial changes in color, the chrominance
+components can be quantized more than the luminance components without
+incurring any visible image quality loss. However, unlike subsampling, this
+feature reduces data in the frequency domain instead of the spatial domain,
+which allows for more fine-grained control. This option is useful in
+quality-sensitive applications, for which the artifacts generated by
+subsampling may be unacceptable.
+
+The -quality option accepts a comma-separated list of parameters, which
+respectively refer to the quality levels which should be assigned to the
+quantization table slots. If there are more q-table slots than parameters,
+then the last parameter is replicated. Thus, if only one quality parameter is
+given, this is used for both luminance and chrominance (slots 0 and 1,
+respectively), preserving the legacy behavior of cjpeg v6b and prior. More (or
+customized) quantization tables can be set with the -qtables option and
+assigned to components with the -qslots option (see the "wizard" switches
+below.)
+
+JPEG files generated with separate luminance and chrominance quality are
+fully compliant with standard JPEG decoders.
+
+CAUTION: For this setting to be useful, be sure to pass an argument of
+-sample 1x1 to cjpeg to disable chrominance subsampling. Otherwise, the
+default subsampling level (2x2, AKA "4:2:0") will be used.
+
The -progressive switch creates a "progressive JPEG" file. In this type of
JPEG file, the data is stored in multiple scans of increasing quality. If the
file is being transmitted over a slow communications link, the decoder can use
the first scan to display a low-quality image very quickly, and can then
improve the display with each subsequent scan. The final image is exactly
equivalent to a standard JPEG file of the same quality setting, and the total
-file size is about the same --- often a little smaller. CAUTION: progressive
-JPEG is not yet widely implemented, so many decoders will be unable to view a
-progressive JPEG file at all.
+file size is about the same --- often a little smaller.
Switches for advanced users:
@@ -203,7 +220,7 @@ Switches for wizards:
The "wizard" switches are intended for experimentation with JPEG. If you
don't know what you are doing, DON'T USE THEM. These switches are documented
-further in the file wizard.doc.
+further in the file wizard.txt.
DJPEG DETAILS
@@ -332,9 +349,10 @@ quality settings to make very small JPEG files; the percentage improvement
is often a lot more than it is on larger files. (At present, -optimize
mode is always selected when generating progressive JPEG files.)
-GIF input files are no longer supported, to avoid the Unisys LZW patent.
-Use a Unisys-licensed program if you need to read a GIF file. (Conversion
-of GIF files to JPEG is usually a bad idea anyway.)
+Support for GIF input files was removed in cjpeg v6b due to concerns over
+the Unisys LZW patent. Although this patent expired in 2006, cjpeg still
+lacks GIF support, for these historical reasons. (Conversion of GIF files to
+JPEG is usually a bad idea anyway.)
HINTS FOR DJPEG
@@ -466,7 +484,26 @@ equivalences between the transformations no longer hold. For example,
"-rot 270 -trim" trims only the bottom edge, but "-rot 90 -trim" followed by
"-rot 180 -trim" trims both edges.
-Another not-strictly-lossless transformation switch is:
+If you are only interested in perfect transformations, add the -perfect switch:
+ -perfect Fail with an error if the transformation is not
+ perfect.
+For example, you may want to do
+ jpegtran -rot 90 -perfect foo.jpg || djpeg foo.jpg | pnmflip -r90 | cjpeg
+to do a perfect rotation, if available, or an approximated one if not.
+
+This version of jpegtran also offers a lossless crop option, which discards
+data outside of a given image region but losslessly preserves what is inside.
+Like the rotate and flip transforms, lossless crop is restricted by the current
+JPEG format; the upper left corner of the selected region must fall on an iMCU
+boundary. If it doesn't, then it is silently moved up and/or left to the
+nearest iMCU boundary (the lower right corner is unchanged.)
+
+The image can be losslessly cropped by giving the switch:
+ -crop WxH+X+Y Crop to a rectangular region of width W and height H,
+ starting at point X,Y.
+
+Other not-strictly-lossless transformation switches are:
+
-grayscale Force grayscale output.
This option discards the chrominance channels if the input image is YCbCr
(ie, a standard color JPEG), resulting in a grayscale JPEG file. The
@@ -483,12 +520,12 @@ markers, such as comment blocks:
suppresses all comments and other excess baggage
present in the source file.
-copy comments Copy only comment markers. This setting copies
- comments from the source file, but discards
- any other inessential data.
+ comments from the source file but discards
+ any other data which is inessential for image display.
-copy all Copy all extra markers. This setting preserves
miscellaneous markers found in the source file, such
- as JFIF thumbnails and Photoshop settings. In some
- files these extra markers can be sizable.
+ as JFIF thumbnails, Exif data, and Photoshop settings.
+ In some files, these extra markers can be sizable.
The default behavior is -copy comments. (Note: in IJG releases v6 and v6a,
jpegtran always did the equivalent of -copy none.)
@@ -515,7 +552,10 @@ blocks to a JPEG file.
rdjpgcom searches a JPEG file and prints the contents of any COM blocks on
standard output. The command line syntax is
- rdjpgcom [-verbose] [inputfilename]
+ rdjpgcom [-raw] [-verbose] [inputfilename]
+The switch "-raw" (or just "-r") causes rdjpgcom to output non-printable
+characters in JPEG comments. These characters are normally escaped for
+security reasons.
The switch "-verbose" (or just "-v") causes rdjpgcom to also display the JPEG
image dimensions. If you omit the input file name from the command line,
the JPEG file is read from standard input. (This may not work on some
diff --git a/trunk/win/jconfig.h b/trunk/win/jconfig.h
index 9cf6f10..ec1fa44 100644
--- a/trunk/win/jconfig.h
+++ b/trunk/win/jconfig.h
@@ -1,5 +1,5 @@
/* jconfig.vc --- jconfig.h for Microsoft Visual C++ on Windows 95 or NT. */
-/* see jconfig.doc for explanations */
+/* see jconfig.txt for explanations */
#define HAVE_PROTOTYPES
#define HAVE_UNSIGNED_CHAR
diff --git a/trunk/wizard.doc b/trunk/wizard.txt
index 54170b2..54170b2 100644
--- a/trunk/wizard.doc
+++ b/trunk/wizard.txt