ryan/mozjpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document new v7/v8 features; .doc = .txt

Browse Source
This commit is contained in:
DRC
2010-10-12 01:55:31 +00:00
parent 1dc925aa11
commit 7e08d60891
23 changed files with 417 additions and 387 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
Makefile.am
View File

@@ -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

253
README
View File

@@ -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 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 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 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.
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.
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 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.

66
cjpeg.1
View File

@@ -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

2
coderules.doc → coderules.txt
View File

@@ -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

4
djpeg.1
View File

@@ -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.

2
djpeg.c
View File

@@ -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);

12
example.c
View File

@@ -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.
*/

30
filelist.doc → filelist.txt
View File

@@ -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).
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.doc for test procedure):
Test files (see install.txt for test procedure):
test*.* Source and comparison files for confidence test.
These are binary image files, NOT text files.

127
install.doc → install.txt
View File

@@ -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
@@ -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.
5. To perform the self-test, execute the command line
NMAKE /f makefile.vc test
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.
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++:

13
jconfig.doc → jconfig.txt
View File

@@ -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,

2
jpeglib.h
View File

@@ -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));

57
jpegtran.1
View File

@@ -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

83
libjpeg.doc → libjpeg.txt
View File

@@ -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.

4
release/libjpeg-turbo.nsi
View File

@@ -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

2
release/libjpeg-turbo.spec
View File

@@ -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

4
release/makecygwinpkg
View File

@@ -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

4
release/makedpkg
View File

@@ -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/*

4
release/makemacpkg
View File

@@ -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

6
release/makesunpkg
View File

@@ -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

25
structure.doc → structure.txt
View File

@@ -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 ***

96
usage.doc → usage.txt
View File

@@ -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

2
win/jconfig.h
View File

@@ -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

0
wizard.doc → wizard.txt
View File