home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-03-23 | 53.7 KB | 1,078 lines |
- Newsgroups: comp.sources.misc
- From: jpeg-info@uunet.uu.net (Independent JPEG Group)
- Subject: v29i001: jpeg - JPEG image compression, Part01/18
- Message-ID: <csm-v29i001=jpeg.000528@sparky.IMD.Sterling.COM>
- X-Md4-Signature: d2cb37aa88f4056bc732781ec08a6f51
- Date: Tue, 24 Mar 1992 06:06:13 GMT
- Approved: kent@sparky.imd.sterling.com
-
- Submitted-by: jpeg-info@uunet.uu.net (Independent JPEG Group)
- Posting-number: Volume 29, Issue 1
- Archive-name: jpeg/part01
- Environment: UNIX, VMS, MS-DOS, Mac, Amiga, Cray
-
- This package contains C software to implement JPEG image compression and
- decompression. JPEG is a standardized compression method for full-color
- and gray-scale images. JPEG is intended for "real-world" scenes; cartoons
- and other non-realistic images are not its strong suit. JPEG is lossy,
- meaning that the output image is not identical to the input image.
- The user can trade off output image quality against compressed file size by
- adjusting a compression parameter.
-
- The distributed programs provide conversion between JPEG "JFIF" format and
- image files in PBMPLUS PPM/PGM, Utah RLE, Truevision Targa, and GIF file
- formats. The core compression and decompression modules can easily be
- reused in other programs, such as image viewers. The package is highly
- portable C code; we have tested it on many machines ranging from PCs to Crays.
-
- We are releasing this software for both noncommercial and commercial use.
- Companies are welcome to use it as the basis for JPEG-related products.
- We do not ask a royalty, although we do ask for an acknowledgement in
- product literature (see the README file in the distribution for details).
- We hope to make this software industrial-quality --- although, as with
- anything that's free, we offer no warranty and accept no liability.
-
- Tom Lane
- --------------
- #! /bin/sh
- # This is a shell archive. Remove anything before this line, then feed it
- # into a shell via "sh file" or similar. To overwrite existing files,
- # type "sh file -c".
- # The tool that generated this appeared in the comp.sources.unix newsgroup;
- # send mail to comp-sources-unix@uunet.uu.net if you want that tool.
- # Contents: README arch.a makefile.vms
- # Wrapped by kent@sparky on Mon Mar 23 16:02:39 1992
- PATH=/bin:/usr/bin:/usr/ucb ; export PATH
- echo If this archive is complete, you will see the following message:
- echo ' "shar: End of archive 1 (of 18)."'
- if test -f 'README' -a "${1}" != "-c" ; then
- echo shar: Will not clobber existing file \"'README'\"
- else
- echo shar: Extracting \"'README'\" \(18730 characters\)
- sed "s/^X//" >'README' <<'END_OF_FILE'
- XThe Independent JPEG Group's JPEG software
- X==========================================
- X
- XREADME for release 3 of 17-Mar-92
- X==================================
- X
- XThis distribution contains the third official release of the Independent JPEG
- XGroup's free JPEG software. You are welcome to redistribute this software and
- Xto use it for any purpose, subject to the conditions under LEGAL ISSUES, below.
- X
- XFor installation instructions, see file SETUP; for usage instructions, see
- Xfile USAGE (or the cjpeg.1 and djpeg.1 manual pages).
- X
- XThis software is still undergoing revision. Updated versions may be obtained
- Xby FTP or UUCP to UUNET and other archive sites; see ARCHIVE LOCATIONS below
- Xfor details.
- X
- XIf you intend to become a serious user of this software, please contact
- Xjpeg-info@uunet.uu.net to be added to our electronic mailing list. Then
- Xyou'll be notified of updates and have a chance to participate in discussions,
- Xetc.
- X
- XThis software is the work of Tom Lane, Philip Gladstone, Luis Ortiz,
- XLee Crocker, Ge' Weijers, and other members of the Independent JPEG Group.
- X
- X
- XDISCLAIMER
- X==========
- X
- XTHIS SOFTWARE IS NOT COMPLETE NOR FULLY DEBUGGED. It is not guaranteed to be
- Xuseful for anything, nor to be compatible with subsequent releases, nor to be
- Xan accurate implementation of the JPEG standard. (See LEGAL ISSUES for even
- Xmore disclaimers.)
- X
- XPlease report any problems with this software to jpeg-info@uunet.uu.net.
- X
- X
- XWHAT'S HERE
- X===========
- X
- XThis distribution contains C software to implement JPEG image compression and
- Xdecompression. JPEG (pronounced "jay-peg") is a standardized compression
- Xmethod for full-color and gray-scale images. JPEG is intended for
- X"real-world" scenes; cartoons and other non-realistic images are not its
- Xstrong suit. JPEG is lossy, meaning that the output image is not necessarily
- Xidentical to the input image. Hence you should not use JPEG if you have to
- Xhave identical output bits. However, on typical images of real-world scenes,
- Xvery good compression levels can be obtained with no visible change, and
- Xamazingly high compression levels can be obtained if you can tolerate a
- Xlow-quality image. For more details, see the references, or just experiment
- Xwith various compression settings.
- X
- XThe software implements JPEG baseline and extended-sequential compression
- Xprocesses. Provision is made for supporting all variants of these processes,
- Xalthough some uncommon parameter settings aren't implemented yet. For legal
- Xreasons, we are not distributing code for the arithmetic-coding process; see
- XLEGAL ISSUES. At present we have made no provision for supporting the
- Xprogressive, hierarchical, or lossless processes defined in the standard.
- X
- XThe present software is not far beyond the prototype stage. It does not
- Xsupport all possible variants of the JPEG standard, and some functions have
- Xrather slow and/or crude implementations. However, it is useful already.
- X
- XThe emphasis in designing this software has been on achieving portability and
- Xflexibility, while also making it fast enough to be useful. We have not yet
- Xundertaken serious performance measurement or tuning; we intend to do so in
- Xthe future.
- X
- X
- XThis software can be used on several levels:
- X
- X* As canned software for JPEG compression and decompression. Just edit the
- X Makefile and configuration files as needed (see file SETUP), compile and go.
- X Members of the Independent JPEG Group will improve the out-of-the-box
- X functionality and speed as time goes on.
- X
- X* As the basis for other JPEG programs. For example, you could incorporate
- X the decompressor into a general image viewing package by replacing the
- X output module with write-to-screen functions. For an implementation on
- X specific hardware, you might want to replace some of the inner loops with
- X assembly code. For a non-command-line-driven system, you might want a
- X different user interface. (Members of the group will be producing Macintosh
- X and Amiga versions with more appropriate user interfaces, for example.)
- X
- X* As a toolkit for experimentation with JPEG and JPEG-like algorithms. Most
- X of the individual decisions you might want to mess with are packaged up into
- X separate modules. For example, the details of color-space conversion and
- X subsampling techniques are each localized in one compressor and one
- X decompressor module. You'd probably also want to extend the user interface
- X to give you more detailed control over the JPEG compression parameters.
- X
- XIn particular, we welcome the use of this software as a component of commercial
- Xproducts; no royalty is required.
- X
- X
- XARCHIVE LOCATIONS
- X=================
- X
- XThe "official" archive site for this software is ftp.uu.net (Internet
- Xaddress 137.39.1.9 or 192.48.96.9). The most recent released version can
- Xalways be found there in directory graphics/jpeg. This particular version
- Xwill be archived as jpegsrc.v3.tar.Z. If you are on the Internet, you can
- Xretrieve files from UUNET by anonymous FTP. If you don't have FTP access,
- XUUNET's archives are also available via UUCP; contact postmaster@uunet.uu.net
- Xfor information on retrieving files that way.
- X
- XVarious other Internet sites maintain copies of the UUNET file, which may or
- Xmay not be up-to-date. In Europe, try nic.funet.fi (128.214.6.100; look in
- Xdirectory pub/graphics/programs/jpeg).
- X
- XYou can also obtain this software from CompuServe, in the GRAPHSUPPORT forum
- X(GO PICS), library 10; this version will be file jpsrc3.zip.
- X
- XIf you are not reasonably handy at configuring and installing portable C
- Xprograms, you may have some difficulty installing this package. You may
- Xprefer to obtain a pre-built executable version. A collection of pre-built
- Xexecutables for various machines is currently available for anonymous FTP at
- Xprocyon.cis.ksu.edu (129.130.10.80 --- this number is due to change soon);
- Xlook under /pub/JPEG. The administrators of this system ask that FTP traffic
- Xbe limited to non-prime hours. For more information on this archive, please
- Xcontact Steve Davis (strat@cis.ksu.edu). This collection is not maintained by
- Xthe Independent JPEG Group, and programs in it may not be the latest version.
- X
- X
- XSUPPORTING SOFTWARE
- X===================
- X
- XYou will probably want Jef Poskanzer's PBMPLUS image software, which provides
- Xmany useful operations on PPM-format image files. In particular, it can
- Xconvert PPM images to and from a wide range of other formats. You can FTP
- Xthis free software from export.lcs.mit.edu (contrib/pbmplus*.tar.Z) or
- Xftp.ee.lbl.gov (pbmplus*.tar.Z). Unfortunately PBMPLUS is not nearly as
- Xportable as the JPEG software is; you are likely to have difficulty making it
- Xwork on any non-Unix machine.
- X
- XIf you are using X Windows you might want to use the xv or xloadimage viewers
- Xto save yourself the trouble of converting PPM to some other format. Both of
- Xthese can be found in the contrib directory at export.lcs.mit.edu. Actually,
- Xxv version 2.00 and up incorporates our software and thus can read and write
- XJPEG files directly. (NOTE: since xv internally reduces all images to 8
- Xbits/pixel, a JPEG file written by xv will not be very high quality; you may
- Xalso prefer xloadimage for viewing if you have a 24-bit display. Caveat user.)
- X
- XFor DOS machines, Lee Crocker's free Piclab program is a useful companion to
- Xthe JPEG software. The latest version, currently 1.91, is available by FTP
- Xfrom SIMTEL20 and its various mirror sites, file <msdos.graphics>piclb191.zip.
- XCompuServe also has it, in the same library as the JPEG software.
- X
- X
- XSOFTWARE THAT'S NO HELP AT ALL
- X==============================
- X
- XHandmade Software's shareware PC program GIF2JPG produces files that are
- Xtotally incompatible with our programs. They use a proprietary format that is
- Xan amalgam of GIF and JPEG representations. However, you can force GIF2JPG
- Xto produce compatible files with its -j switch, and their decompression
- Xprogram JPG2GIF can read our files (at least ones produced with our default
- Xoption settings).
- X
- XUnfortunately, many commercial JPEG implementations are also incompatible as
- Xof this writing, especially programs released before summer 1991. The root of
- Xthe problem is that the ISO JPEG committee failed to specify a concrete file
- Xformat. Some vendors "filled in the blanks" on their own, creating
- Xproprietary formats that no one else could read. (For example, none of the
- Xearly commercial JPEG implementations for the Macintosh were able to exchange
- Xcompressed files.)
- X
- XThe file format we have adopted is called JFIF (see REFERENCES). This format
- Xhas been agreed to by a number of major commercial JPEG vendors, and we expect
- Xthat it will become the de facto standard. JFIF is a minimal representation;
- Xwork is also going forward to incorporate JPEG compression into the TIFF
- Xstandard, for use in "high end" applications that need to record a lot of
- Xadditional data about an image. We intend to support JPEG-in-TIFF in the
- Xfuture. We hope that these two formats will be sufficient and that other,
- Xincompatible JPEG file formats will not proliferate.
- X
- XIndeed, part of the reason for developing and releasing this free software is
- Xto help force rapid convergence to de facto standards for JPEG file formats.
- XSUPPORT STANDARD, NON-PROPRIETARY FORMATS: demand JFIF or JPEG-in-TIFF!
- X
- X
- XUSING JPEG AS A SUBROUTINE IN A LARGER PROGRAM
- X==============================================
- X
- XYou can readily incorporate the JPEG compression and decompression routines in
- Xa larger program. The file example.c provides a skeleton of the interface
- Xroutines you'll need for this purpose. Essentially, you replace jcmain.c (for
- Xcompression) and/or jdmain.c (for decompression) with your own code. Note
- Xthat the fewer JPEG options you allow the user to twiddle, the less code you
- Xneed; all the default options are set up automatically. (Alternately, if you
- Xknow a lot about JPEG or have a special application, you may want to twiddle
- Xthe default options even more extensively than jcmain/jdmain do.)
- X
- XMost likely, you will want the uncompressed image to come from memory (for
- Xcompression) or go to memory or the screen (for decompression). For this
- Xpurpose you must provide image reading or writing routines that match the
- Xinterface used by the image file I/O modules (jrdXXX or jwrXXX); again,
- Xexample.c shows a skeleton of what is required.
- X
- XBy default, any error detected inside the JPEG routines will cause a message
- Xto be printed on stderr, followed by exit(). You can override this behavior
- Xby supplying your own message-printing and/or error-exit routines; again,
- Xexample.c shows how.
- X
- XMechanics: we recommend you create libjpeg.a as shown in the Makefile, then
- Xlink that with your surrounding program. (If your linker is at all
- Xreasonable, only the code you actually need will get loaded.) Include the
- Xfiles jconfig.h and jpegdata.h in C files that need to call the JPEG routines.
- X
- XCAUTION: some people have tried to compile JPEG and their surrounding code
- Xwith different compilers, e.g., cc for JPEG and c++ or gcc for the rest. This
- Xis a Real Bad Move and you will deserve what happens to you if you try it.
- X(Hint: the parameter structures can get laid out differently with no warning.)
- X
- XRead our "architecture" file for more info. If it seems to you that the
- Xsoftware structure doesn't accommodate what you want to do, please contact
- Xthe authors.
- X
- XBeginning with version 3, we will endeavor to hold the interface described by
- Xexample.c constant, so that you can plug in updated versions of the JPEG code
- Xjust by recompiling. However, we can't guarantee this, especially if you
- Xchoose to twiddle any JPEG options not listed in example.c. Check the
- XCHANGELOG when installing any new version, and compare example.c against the
- Xprior version. Recompile your calling software (don't just relink), as we may
- Xadd or subtract fields in the parameter structures.
- X
- X
- XREFERENCES
- X==========
- X
- XThe best and most readily available introduction to the JPEG compression
- Xalgorithm is Wallace's article in the April '91 CACM:
- X Wallace, Gregory K. "The JPEG Still Picture Compression Standard",
- X Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
- X(Adjacent articles in that issue discuss MPEG motion picture compression,
- Xapplications of JPEG, and related topics.) We highly recommend reading that
- Xarticle before trying to understand the innards of any JPEG software.
- XIf you don't have the CACM issue handy, a PostScript file containing a revised
- Xversion of the article is available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.
- XThe file (actually a preprint for an article to appear in IEEE Trans. Consumer
- XElectronics) omits the sample images that appeared in CACM, but it includes
- Xcorrections and some added material. Note: the Wallace article is copyright
- XACM and IEEE, and it may not be used for commercial purposes.
- X
- XFor more detail about the JPEG standard you pretty much have to go to the
- Xdraft standard (which is not nearly as intelligible as Wallace's article).
- XThe standard is not now available electronically; you must order a paper copy
- Xthrough ISO. In the US, copies may be ordered from ANSI Sales at (212)
- X642-4900. The standard is divided into two parts: Part 1 is the actual
- Xspecification, and Part 2 covers compliance testing methods. The current
- X"committee draft" version of Part 1 is titled "Digital Compression and Coding
- Xof Continuous-tone Still Images, Part 1: Requirements and guidelines" and has
- Xdocument number ISO/IEC CD 10918-1. (The alternate number SC2 N2215 should
- Xalso be mentioned when ordering.) This draft is expected to be superseded by
- Xthe Draft International Standard version around the end of November 1991.
- XOrdering info will be the same as above, but replace "CD" with "DIS" in the
- Xdocument number (alternate number not yet known). The committee draft of
- XPart 2 is expected to be available around the end of December 1991. It will
- Xbe titled "Digital Compression and Coding of Continuous-tone Still Images,
- XPart 2: Compliance testing" and will have document number ISO/IEC CD 10918-2
- X(alternate number not yet known).
- X
- XThe JPEG standard does not specify all details of an interchangeable file
- Xformat. For the omitted details we follow the "JFIF" conventions, revision
- X1.01. A copy of the JFIF spec is available from:
- X Literature Department
- X C-Cube Microsystems, Inc.
- X 399A West Trimble Road
- X San Jose, CA 95131
- X (408) 944-6300
- XThe same source can supply copies of the draft JPEG-in-TIFF documents
- X(Appendixes O and P to the TIFF spec). PostScript versions of these
- Xdocuments can also be obtained by e-mail from the C-Cube mail server,
- Xnetlib@c3.pla.ca.us. Send the message "send jfif_ps from jpeg" to obtain the
- XJFIF document; "send app_o_ps from jpeg" and "send app_p_ps from jpeg" will
- Xproduce the TIFF documents. Send the message "help" if you have trouble.
- X
- XIf you want to understand this implementation, start by reading the
- X"architecture" documentation file. Please read "codingrules" if you want to
- Xcontribute any code.
- X
- X
- XLEGAL ISSUES
- X============
- X
- XThe authors make NO WARRANTY or representation, either express or implied,
- Xwith respect to this software, its quality, accuracy, merchantability, or
- Xfitness for a particular purpose. This software is provided "AS IS", and you,
- Xits user, assume the entire risk as to its quality and accuracy.
- X
- XThis software is copyright (C) 1991, 1992, Thomas G. Lane.
- XAll Rights Reserved except as specified below.
- X
- XPermission is hereby granted to use, copy, modify, and distribute this
- Xsoftware (or portions thereof) for any purpose, without fee, subject to these
- Xconditions:
- X(1) If any part of the source code for this software is distributed, then this
- XREADME file must be included, with this copyright and no-warranty notice
- Xunaltered; and any additions, deletions, or changes to the original files
- Xmust be clearly indicated in accompanying documentation.
- X(2) If only executable code is distributed, then the accompanying
- Xdocumentation must state that "this software is based in part on the work of
- Xthe Independent JPEG Group".
- X(3) Permission for use of this software is granted only if the user accepts
- Xfull responsibility for any undesirable consequences; the authors accept
- XNO LIABILITY for damages of any kind.
- X
- XPermission is NOT granted for the use of any author's name or author's company
- Xname in advertising or publicity relating to this software or products derived
- Xfrom it. This software may be referred to only as "the Independent JPEG
- XGroup's software".
- X
- XWe specifically permit and encourage the use of this software as the basis of
- Xcommercial products, provided that all warranty or liability claims are
- Xassumed by the product vendor.
- X
- X
- Xansi2knr.c is included in this distribution by permission of L. Peter Deutsch,
- Xsole proprietor of its copyright holder, Aladdin Enterprises of Menlo Park, CA.
- Xansi2knr.c is NOT covered by the above copyright and conditions, but instead
- Xby the usual distribution terms of the Free Software Foundation; principally,
- Xthat you must include source code if you redistribute it. (See the file
- Xansi2knr.c for full details.) However, since ansi2knr.c is not needed as part
- Xof any product generated from the JPEG code, this does not limit you more than
- Xthe foregoing paragraphs do.
- X
- X
- XIt appears that the arithmetic coding option of the JPEG spec is covered by
- Xpatents owned by IBM and AT&T, as well as a pending Japanese patent of
- XMitsubishi. Hence arithmetic coding cannot legally be used without obtaining
- Xone or more licenses. For this reason, support for arithmetic coding has been
- Xremoved from the free JPEG software. (Since arithmetic coding provides only a
- Xmarginal gain over the unpatented Huffman mode, it is unlikely that very many
- Xpeople will choose to use it. If you do obtain the necessary licenses,
- Xcontact jpeg-info@uunet.uu.net for a copy of our arithmetic coding modules.)
- XSo far as we are aware, there are no patent restrictions on the remaining
- Xcode.
- X
- X
- XWe are required to state that
- X "The Graphics Interchange Format(c) is the Copyright property of
- X CompuServe Incorporated. GIF(sm) is a Service Mark property of
- X CompuServe Incorporated."
- X
- X
- XTO DO
- X=====
- X
- XMany of the modules need fleshing out to provide more complete
- Ximplementations, or to provide faster paths for common cases.
- XImproving the speed will be the next big work item for the JPEG group.
- X
- XWe'd appreciate it if people would compile and check out the code on as wide a
- Xvariety of systems as possible, and report any portability problems
- Xencountered (with solutions, if possible). Checks of file compatibility with
- Xother JPEG implementations would also be of interest. Finally, we would
- Xappreciate code profiles showing where the most time is spent, especially on
- Xunusual systems.
- X
- XPlease send bug reports, offers of help, etc. to jpeg-info@uunet.uu.net.
- END_OF_FILE
- if test 18730 -ne `wc -c <'README'`; then
- echo shar: \"'README'\" unpacked with wrong size!
- fi
- # end of 'README'
- fi
- if test -f 'arch.a' -a "${1}" != "-c" ; then
- echo shar: Will not clobber existing file \"'arch.a'\"
- else
- echo shar: Extracting \"'arch.a'\" \(29060 characters\)
- sed "s/^X//" >'arch.a' <<'END_OF_FILE'
- X
- X JPEG SYSTEM ARCHITECTURE 29-FEB-92
- X
- X
- XThis file provides an overview of the "architecture" of the portable JPEG
- Xsoftware; that is, the functions of the various modules in the system and the
- Xinterfaces between modules. For more precise details about any data structure
- Xor calling convention, see the header files.
- X
- XImportant note: when I say "module" I don't mean "a C function", which is what
- Xsome people seem to think the term means. A separate C source file is closer
- Xto the mark. Also, it is frequently the case that several different modules
- Xpresent a common interface to callers; the term "object" or "method" refers to
- Xthis common interface (see "Poor man's object-oriented programming", below).
- X
- XJPEG-specific terminology follows the JPEG standard:
- X A "component" means a color channel, e.g., Red or Luminance.
- X A "sample" is a pixel component value (i.e., one number in the image data).
- X A "coefficient" is a frequency coefficient (a DCT transform output number).
- X The term "block" refers to an 8x8 group of samples or coefficients.
- X "MCU" (minimum coded unit) is the same as "MDU" of the R8 draft; i.e., an
- X interleaved set of blocks of size determined by the sampling factors,
- X or a single block in a noninterleaved scan.
- X
- X
- X*** System requirements ***
- X
- XWe must support compression and decompression of both Huffman and
- Xarithmetic-coded JPEG files. Any set of compression parameters allowed by the
- XJPEG spec should be readable for decompression. (We can be more restrictive
- Xabout what formats we can generate.) (Note: for legal reasons no arithmetic
- Xcoding implementation is currently included in the publicly available sources.
- XHowever, the architecture still supports it.)
- X
- XWe need to be able to handle both raw JPEG files (more specifically, the JFIF
- Xformat) and JPEG-in-TIFF (C-cubed's format, and perhaps Kodak's). Even if we
- Xdon't implement TIFF ourselves, other people will want to use our code for
- Xthat. This means that generation and scanning of the file header has to be
- Xseparated out.
- X
- XPerhaps we should be prepared to support the JPEG lossless mode (also referred
- Xto in the spec as spatial DPCM coding). A lot of people seem to believe they
- Xneed this... whether they really do is debatable, but the customer is always
- Xright. On the other hand, there will not be much sharable code between the
- Xlossless and lossy modes! At best, a lossless program could be derived from
- Xparts of the lossy version. For now we will only worry about the lossy mode.
- X
- XI see no real value in supporting the JPEG progressive modes (note that
- Xspectral selection and successive approximation are two different progressive
- Xmodes). These are only of interest when painting the decompressed image in
- Xreal-time, which nobody is going to do with a pure software implementation.
- X
- XThere is some value in supporting the hierarchical mode, which allows for
- Xsuccessive frames of higher resolution. This could be of use for including
- X"thumbnail" representations. However, this appears to add a lot more
- Xcomplexity than it is worth.
- X
- XA variety of uncompressed image file formats and user interfaces must be
- Xsupported. These aspects therefore have to be kept separate from the rest of
- Xthe system. A particularly important issue is whether color quantization of
- Xthe output is needed (i.e., whether a colormap is used). We should be able to
- Xsupport both adaptive quantization (which requires two or more passes over the
- Ximage) and nonadaptive (quantization to a prespecified colormap, which can be
- Xdone in one pass).
- X
- XMemory usage is an important concern, since we will port this code to 80x86
- Xand other limited-memory machines. For large intermediate structures, we
- Xshould be able to use either virtual memory or temporary files.
- X
- XIt should be possible to build programs that handle compression only,
- Xdecompression only, or both, without much duplicate or unused code in any
- Xversion. (In particular, a decompression-only version should have no extra
- Xbaggage.)
- X
- X
- X*** Compression overview ***
- X
- XThe *logical* steps needed in (non-lossless) JPEG compression are:
- X
- X1. Conversion from incoming image format to a standardized internal form
- X (either RGB or grayscale).
- X
- X2. Color space conversion (e.g., RGB to YCbCr). This is a null step for
- X grayscale (unless we support mapping color inputs to grayscale, which
- X would most easily be done here). Gamma adjustment may also be needed here.
- X
- X3. Subsampling (reduction of number of samples in some color components).
- X This step operates independently on each color component.
- X
- X4. MCU extraction (creation of a single sequence of 8x8 sample blocks).
- X This step and the following ones are performed once for each scan
- X in the output JPEG file, i.e., once if making an interleaved file and more
- X than once for a noninterleaved file.
- X Note: both this step and the previous one must deal with edge conditions
- X for pictures that aren't a multiple of the MCU dimensions. Alternately,
- X we could expand the picture to a multiple of an MCU before doing these
- X two steps. (The latter seems better and has been adopted below.)
- X
- X5. DCT transformation of each 8x8 block.
- X
- X6. Quantization scaling and zigzag reordering of the elements in each 8x8
- X block.
- X
- X7. Huffman or arithmetic encoding of the transformed block sequence.
- X
- X8. Output of the JPEG file with whatever headers/markers are wanted.
- X
- XOf course, the actual implementation will combine some of these logical steps
- Xfor efficiency. The trick is to keep these logical functions as separate as
- Xpossible without losing too much performance.
- X
- XIn addition to these logical pipeline steps, we need various modules that
- Xaren't part of the data pipeline. These are:
- X
- XA. Overall control (sequencing of other steps & management of data passing).
- X
- XB. User interface; this will determine the input and output files, and supply
- X values for some compression parameters. Note that this module is highly
- X platform-dependent.
- X
- XC. Compression parameter selection: some parameters should be chosen
- X automatically rather than requiring the user to find a good value.
- X The prototype only does this for the back-end (Huffman or arithmetic)
- X parameters, but further in the future, more might be done. A
- X straightforward approach to selection is to try several values; this
- X requires being able to repeatedly apply some portion of the pipeline and
- X inspect the results (without actually outputting them). Probably only
- X entropy encoding parameters can reasonably be done this way; optimizing
- X earlier steps would require too much data to be reprocessed (not to mention
- X the problem of interactions between parameters for different steps).
- X What other facilities do we need to support automatic parameter selection?
- X
- XD. A memory management module to deal with small-memory machines. This must
- X create the illusion of virtual memory for certain large data structures
- X (e.g., the subsampled image or the transformed coefficients).
- X The interface to this must be defined to minimize the overhead incurred,
- X especially on virtual-memory machines where the module won't do much.
- X
- XIn many cases we can arrange things so that a data stream is produced in
- Xsegments by one module and consumed by another without the need to hold it all
- Xin (virtual) memory. This is obviously not possible for any data that must be
- Xscanned more than once, so it won't work everywhere.
- X
- XThe major variable at this level of detail is whether the JPEG file is to be
- Xinterleaved or not; that affects the order of processing so fundamentally that
- Xthe central control module must know about it. Some of the other modules may
- Xneed to know it too. It would simplify life if we didn't need to support
- Xnoninterleaved images, but that is not reasonable.
- X
- XMany of these steps operate independently on each color component; the
- Xknowledge of how many components there are, and how they are interleaved,
- Xought to be confined to the central control module. (Color space conversion
- Xand MCU extraction probably have to know it too.)
- X
- X
- X*** Decompression overview ***
- X
- XDecompression is roughly the inverse process from compression, but there are
- Xsome additional steps needed to produce a good output image.
- X
- XThe *logical* steps needed in (non-lossless) JPEG decompression are:
- X
- X1. Scanning of the JPEG file, decoding of headers/markers etc.
- X
- X2. Huffman or arithmetic decoding of the coefficient sequence.
- X
- X3. Quantization descaling and zigzag reordering of the elements in each 8x8
- X block.
- X
- X4. MCU disassembly (conversion of a possibly interleaved sequence of 8x8
- X blocks back to separate components in pixel map order).
- X
- X5. (Optional) Cross-block smoothing per JPEG section K.8 or a similar
- X algorithm. (Steps 5-8 operate independently on each component.)
- X
- X6. Inverse DCT transformation of each 8x8 block.
- X
- X7. De-subsampling. At this point a pixel image of the original dimensions
- X has been recreated.
- X
- X8. Post-subsampling smoothing. This can be combined with de-subsampling,
- X by using a convolution-like calculation to generate each output pixel
- X directly from one or more input pixels.
- X
- X9. Cropping to the original pixel dimensions (throwing away duplicated
- X pixels at the edges). It is most convenient to do this now, as the
- X preceding steps are simplified by not having to worry about odd picture
- X sizes.
- X
- X10. Color space reconversion (e.g., YCbCr to RGB). This is a null step for
- X grayscale. (Note that mapping a color JPEG to grayscale output is most
- X easily done in this step.) Gamma adjustment may also be needed here.
- X
- X11. Color quantization (only if a colormapped output format is requested).
- X NOTE: it is probably preferable to perform quantization in the internal
- X (JPEG) colorspace rather than the output colorspace. Doing it that way,
- X color conversion need only be applied to the colormap entries, not to
- X every pixel; and quantization gets to operate in a non-gamma-corrected
- X space. But the internal space may not be suitable for some algorithms.
- X The system design is such that only the color quantizer module knows
- X whether color conversion happens before or after quantization.
- X
- X12. Writing of the desired image format.
- X
- XAs before, some of these will be combined into single steps. When dealing
- Xwith a noninterleaved JPEG file, steps 2-9 will be performed once for each
- Xscan; the resulting data will need to be buffered up so that steps 10-12 can
- Xprocess all the color components together.
- X
- XThe same auxiliary modules are needed as before, except for compression
- Xparameter selection. Note that rerunning a pipeline stage should never be
- Xneeded during decompression. This may allow a simpler control module. The
- Xuser interface might also be simpler since it need not supply any compression
- Xparameters.
- X
- XAs before, not all of these steps require the whole image to be stored.
- XActually, two-pass color quantization is the only step that logically requires
- Xthis; everything else could be done a few raster lines at a time (at least for
- Xinterleaved images). We might want to make color quantization be a separate
- Xprogram because of this fact.
- X
- XAgain, many of the steps should be able to work on one color component in
- Xignorance of the other components.
- X
- X
- X*** Implications of noninterleaved formats ***
- X
- XMuch of the work can be done in a single pass if an interleaved JPEG file
- Xformat is used. With a noninterleaved JPEG file, separating or recombining
- Xthe components will force use of virtual memory (on a small-memory machine,
- Xwe probably would want one temp file per color component).
- X
- XIf any of the image formats we read or write are noninterleaved, the opposite
- Xcondition might apply: processing a noninterleaved JPEG file would be more
- Xefficient. Offhand, though, I can't think of any popular image formats that
- Xwork that way; besides the win would only come if the same color space were
- Xused in JPEG and non-JPEG files. It's not worth the complexity to make the
- Xsystem design accommodate that case efficiently.
- X
- XAn argument against interleaving is that it makes the decompressor need more
- Xmemory for cross-block smoothing (since the minimum processable chunk of the
- Ximage gets bigger). With images more than 1000 pixels across, 80x86 machines
- Xare likely to have difficulty in handling this feature.
- X
- XAnother argument against interleaving is that the noninterleaved format allows
- Xa wider range of sampling factors, since the limit of ten blocks per MCU no
- Xlonger applies. We could get around this by blithely ignoring the spec's
- Xlimit of ten blocks, but that seems like a bad idea (especially since it makes
- Xthe above problem worse).
- X
- XThe upshot is that we need to support both interleaved and noninterleaved JPEG
- Xformats, since for any given machine and picture size one may be much more
- Xefficient than the other. However, the non-JPEG format we convert to or from
- Xwill be assumed to be an interleaved format (i.e., it produces or stores all
- Xthe components of a pixel together).
- X
- XI do not think it is necessary for the compressor to be able to output
- Xpartially-interleaved formats (multiple scans, some of which interleave a
- Xsubset of the components). However, the decompressor must be able to read
- Xsuch files to conform to the spec.
- X
- X
- X*** Data formats ***
- X
- XPipeline steps that work on pixel sample values will use the following data
- Xstructure:
- X
- X typedef something JSAMPLE; a pixel component value, 0..MAXJSAMPLE
- X typedef JSAMPLE *JSAMPROW; ptr to a row of samples
- X typedef JSAMPROW *JSAMPARRAY; ptr to a list of rows
- X typedef JSAMPARRAY *JSAMPIMAGE; ptr to a list of color-component arrays
- X
- XThe basic element type JSAMPLE will be one of unsigned char, (signed) char, or
- Xunsigned short. Unsigned short will be used if samples wider than 8 bits are
- Xto be supported (this is a compile-time option). Otherwise, unsigned char is
- Xused if possible. If the compiler only supports signed chars, then it is
- Xnecessary to mask off the value when reading. Thus, all reads of sample
- Xvalues should be coded as "GETJSAMPLE(value)", where the macro will be defined
- Xas "((value)&0xFF)" on signed-char machines and "(value)" elsewhere.
- X
- XWith these conventions, JSAMPLE values can be assumed to be >= 0. This should
- Xsimplify correct rounding during subsampling, etc. The JPEG draft's
- Xspecification that sample values run from -128..127 will be accommodated by
- Xsubtracting 128 just as the sample value is copied into the source array for
- Xthe DCT step (this will be an array of signed shorts or longs). Similarly,
- Xduring decompression the output of the IDCT step will be immediately shifted
- Xback to 0..255. (NB: different values are required when 12-bit samples are in
- Xuse. The code should be written in terms of MAXJSAMPLE and CENTERJSAMPLE,
- Xwhich will be #defined as 255 and 128 respectively in an 8-bit implementation,
- Xand as 4095 and 2048 in a 12-bit implementation.)
- X
- XOn compilers that don't support "unsigned short", signed short can be used for
- Xa 12-bit implementation. To support lossless coding (which allows up to
- X16-bit data precision) masking with 0xFFFF in GETJSAMPLE might be necessary.
- X(But if "int" is 16 bits then using "unsigned int" is the best solution.)
- X
- XNotice that we use a pointer per row, rather than a two-dimensional JSAMPLE
- Xarray. This choice costs only a small amount of memory and has several
- Xbenefits:
- X
- X* Code using the data structure doesn't need to know the allocated width of
- Xthe rows. This will simplify edge expansion/compression, since we can work
- Xin an array that's wider than the logical picture width.
- X
- X* The rows forming a component array may be allocated at different times
- Xwithout extra copying. This will simplify working a few scanlines at a time,
- Xespecially in smoothing steps that need access to the previous and next rows.
- X
- X* Indexing doesn't require multiplication; this is a performance win on many
- Xmachines.
- X
- XNote that each color component is stored in a separate array; we don't use the
- Xtraditional structure in which the components of a pixel are stored together.
- XThis simplifies coding of steps that work on each component independently,
- Xbecause they don't need to know how many components there are. Furthermore,
- Xwe can read or write each component to a temp file independently, which is
- Xhelpful when dealing with noninterleaved JPEG files.
- X
- XA specific sample value will be accessed by code such as
- X GETJSAMPLE(image[colorcomponent][row][col])
- Xwhere col is measured from the image left edge, but row is measured from the
- Xfirst sample row currently in memory. Either of the first two indexings can
- Xbe precomputed by copying the relevant pointer.
- X
- X
- XPipeline steps that work on frequency-coefficient values will use the
- Xfollowing data structure:
- X
- X typedef short JCOEF; a 16-bit signed integer
- X typedef JCOEF JBLOCK[64]; an 8x8 block of coefficients
- X typedef JBLOCK *JBLOCKROW; ptr to one horizontal row of 8x8 blocks
- X typedef JBLOCKROW *JBLOCKARRAY; ptr to a list of such rows
- X typedef JBLOCKARRAY *JBLOCKIMAGE; ptr to a list of color component arrays
- X
- XThe underlying type is always a 16-bit signed integer (this is "short" on all
- Xmachines of interest, but let's use the typedef name anyway). These are
- Xgrouped into 8x8 blocks (we should use #defines DCTSIZE and DCTSIZE2 rather
- Xthan "8" and "64"). The contents of a block may be either in "natural" or
- Xzigzagged order, and may be true values or divided by the quantization
- Xcoefficients, depending on where the block is in the pipeline.
- X
- XNotice that the allocation unit is now a row of 8x8 blocks, corresponding to
- Xeight rows of samples. Otherwise the structure is much the same as for
- Xsamples, and for the same reasons.
- X
- XOn machines where malloc() can't handle a request bigger than 64Kb, this data
- Xstructure limits us to rows of less than 512 JBLOCKs, which would be a picture
- Xwidth of 4000 pixels. This seems an acceptable restriction.
- X
- X
- XOn 80x86 machines, the bottom-level pointer types (JSAMPROW and JBLOCKROW)
- Xmust be declared as "far" pointers, but the upper levels can be "near"
- X(implying that the pointer lists are allocated in the DS segment).
- XTo simplify sharing code, we'll have a #define symbol FAR, which expands to
- Xthe "far" keyword when compiling on 80x86 machines and to nothing elsewhere.
- X
- X
- XThe data arrays used as input and output of the DCT transform subroutine will
- Xbe declared using a separate typedef; they could be arrays of "short", "int"
- Xor "long" independently of the above choices. This would depend on what is
- Xneeded to make the compiler generate correct and efficient multiply/add code
- Xin the DCT inner loops. No significant speed or memory penalty will be paid
- Xto have a different representation than is used in the main image storage
- Xarrays, since some additional value-by-value processing is done at the time of
- Xcreation or extraction of the DCT data anyway (e.g., add/subtract 128).
- X
- X
- X*** Poor man's object-oriented programming ***
- X
- XIt should be pretty clear by now that we have a lot of quasi-independent
- Xsteps, many of which have several possible behaviors. To avoid cluttering the
- Xcode with lots of switch statements, we'll use a simple form of object-style
- Xprogramming to separate out the different possibilities.
- X
- XFor example, Huffman and arithmetic coding will be implemented as two separate
- Xmodules that present the same external interface; at runtime, the calling code
- Xwill access the proper module indirectly through an "object".
- X
- XWe can get the limited features we need while staying within portable C. The
- Xbasic tool is a function pointer. An "object" is just a struct containing one
- Xor more function pointer fields, each of which corresponds to a method name in
- Xreal object-oriented languages. During initialization we fill in the function
- Xpointers with references to whichever module we have determined we need to use
- Xin this run. Then invocation of the module is done by indirecting through a
- Xfunction pointer; on most architectures this is no more expensive (and
- Xpossibly cheaper) than a switch, which would be the only other way of making
- Xthe required run-time choice. The really significant benefit, of course, is
- Xkeeping the source code clean and well structured.
- X
- XFor example, the interface for entropy decoding (Huffman or arithmetic
- Xdecoding) might look like this:
- X
- X struct function_ptr_struct {
- X ...
- X /* Entropy decoding methods */
- X void (*prepare_for_scan) ();
- X void (*get_next_mcu) ();
- X ...
- X };
- X
- X typedef struct function_ptr_struct * function_ptrs;
- X
- XThe struct pointer is what will actually be passed around. A call site might
- Xlook like this:
- X
- X some_function (function_ptrs fptrs)
- X {
- X ...
- X (*fptrs->get_next_mcu) (...);
- X ...
- X }
- X
- X(It might be worth inventing some specialized macros to hide the rather ugly
- Xsyntax for method definition and call.) Note that the caller doesn't know how
- Xmany different get_next_mcu procedures there are, what their real names are,
- Xnor how to choose which one to call.
- X
- XAn important benefit of this scheme is that it is easy to provide multiple
- Xversions of any method, each tuned to a particular case. While a lot of
- Xprecalculation might be done to select an optimal implementation of a method,
- Xthe cost per invocation is constant. For example, the MCU extraction step
- Xmight have a "generic" method, plus one or more "hardwired" methods for the
- Xmost popular sampling factors; the hardwired methods would be faster because
- Xthey'd use straight-line code instead of for-loops. The cost to determine
- Xwhich method to use is paid only once, at startup, and the selection criteria
- Xare hidden from the callers of the method.
- X
- XThis plan differs a little bit from usual object-oriented structures, in that
- Xonly one instance of each object class will exist during execution. The
- Xreason for having the class structure is that on different runs we may create
- Xdifferent instances (choose to execute different modules).
- X
- XTo minimize the number of object pointers that have to be passed around, it
- Xwill be easiest to have just a few big structs containing all the method
- Xpointers. We'll actually use two such structs, one for "system-dependent"
- Xmethods (memory allocation and error handling) and one for everything else.
- X
- XBecause of this choice, it's best not to think of an "object" as a specific
- Xdata structure. Rather, an "object" is just a group of related methods.
- XThere would typically be one or more C modules (source files) providing
- Xconcrete implementations of those methods. You can think of the term
- X"method" as denoting the common interface presented by some set of functions,
- Xand "object" as denoting a group of common method interfaces, or the total
- Xshared interface behavior of a group of modules.
- X
- X
- X*** Data chunk sizes ***
- X
- XTo make the cost of this object-oriented style really minimal, we should make
- Xsure that each method call does a fair amount of computation. To do that we
- Xshould pass large chunks of data around; for example, the colorspace
- Xconversion method should process much more than one pixel per call.
- X
- XFor many steps, the most natural unit of data seems to be an "MCU row".
- XThis consists of one complete horizontal strip of the image, as high as an
- XMCU. In a noninterleaved scan, an MCU row is always eight samples high (when
- Xlooking at samples) or one 8x8 block high (when looking at coefficients). In
- Xan interleaved scan, an MCU row consists of all the data for one horizontal
- Xrow of MCUs; this may be from one to four blocks high (eight to thirty-two
- Xsamples) depending on the sampling factors. The height and width of an MCU
- Xrow may be different in each component. (Note that the height and width of an
- XMCU row changes at the subsampling and de-subsampling steps. An unsubsampled
- Ximage has the same size in each component. The preceding statements apply to
- Xthe subsampled dimensions.)
- X
- XFor example, consider a 1024-pixel-wide image using (2h:2v)(1h:1v)(1h:1v)
- Xsubsampling. In the noninterleaved case, an MCU row of Y would contain 8x1024
- Xsamples or the same number of frequency coefficients, so it would occupy
- X8K bytes (samples) or 16K bytes (coefficients). An MCU row of Cb or Cr would
- Xcontain 8x512 samples and occupy half as much space. In the interleaved case,
- Xan MCU row would contain 16x1024 Y samples, 8x512 Cb and 8x512 Cr samples, so
- Xa total of 24K (samples) or 48K (coefficients) would be needed. This is a
- Xreasonable amount of data to expect to retain in memory at one time. (Bear in
- Xmind that we'll usually need to have several MCU rows resident in memory at
- Xonce, at the inputs and outputs to various pipeline steps.)
- X
- XThe worst case is probably (2h:4v)(1h:1v)(1h:1v) interleaving (this uses 10
- Xblocks per MCU, which is the maximum allowed by the spec). An MCU will then
- Xcontain 32 sample rows worth of Y, so it would occupy 40K or 80K bytes for a
- X1024-pixel-wide image. The most memory-intensive step is probably cross-block
- Xsmoothing, for which we'd need 3 MCU rows of coefficients as input and another
- Xone as output; that would be 320K of working storage. Anything much larger
- Xwould not fit in an 80x86 machine. (To decompress wider pictures on an 80x86,
- Xwe'll have to skip cross-block smoothing or else use temporary files.)
- X
- XThis unit is thus a reasonable-sized chunk for passing through the pipeline.
- XOf course, its major advantage is that it is a natural chunk size for the MCU
- Xassembly and disassembly steps to work with.
- X
- XFor the entropy (Huffman or arithmetic) encoding/decoding steps, the most
- Xconvenient chunk is a single MCU: one 8x8 block if not interleaved, three to
- Xten such blocks if interleaved. The advantage of this is that when handling
- Xinterleaved data, the blocks have the same sequence of component membership on
- Xeach call. (For example, Y,Y,Y,Y,Cb,Cr when using (2h:2v)(1h:1v)(1h:1v)
- Xsubsampling.) The code needs to know component membership so that it can
- Xapply the right set of compression coefficients to each block. A prebuilt
- Xarray describing this membership can be used during each call. This chunk
- Xsize also makes it easy to handle restart intervals: just count off one MCU
- Xper call and reinitialize when the count reaches zero (restart intervals are
- Xspecified in numbers of MCU).
- X
- XFor similar reasons, one MCU is also the best chunk size for the frequency
- Xcoefficient quantization and dequantization steps.
- X
- XFor subsampling and desubsampling, the best chunk size is to have each call
- Xtransform Vk sample rows from or to Vmax sample rows (Vk = this component's
- Xvertical sampling factor, Vmax = largest vertical sampling factor). There are
- Xeight such chunks in each MCU row. Using a whole MCU row as the chunk size
- Xwould reduce function call overhead a fraction, but would imply more buffering
- Xto provide context for cross-pixel smoothing.
- X
- X
- X*** Compression object structure ***
- X
- XI propose the following set of objects for the compressor. Here an "object"
- Xis the common interface for one or more modules having comparable functions.
- X
- XMost of these objects can be justified as information-hiding modules.
- XI've indicated what information is private to each object/module.
- X
- XNote that in all cases, the caller of a method is expected to have allocated
- Xany storage needed for it to return its result. (Typically this storage can
- Xbe re-used in successive calls, so malloc'ing and free'ing once per call is
- Xnot reasonable.) Also, much of the context required (compression parameters,
- Ximage size, etc) will be passed around in large common data structures, which
- Xaren't described here; see the header files. Notice that any object that
- Xmight need to allocate working storage receives an "init" and a "term" call;
- X"term" should be careful to free all allocated storage so that the JPEG system
- Xcan be used multiple times during a program run. (For the same reason,
- Xdepending on static initialization of variables is a no-no. The only
- Xexception to the free-all-allocated-storage rule is that storage allocated for
- Xthe entire processing of an image need not be explicitly freed, since the
- Xmemory manager's free_all cleanup will free it.)
- X
- X1. Input file conversion to standardized form. This provides these methods:
- X input_init: read the file header, report image size & component count.
- X get_input_row: read one pixel row, return it in our standard format.
- X input_term: finish up at the end.
- X In implementations that support multiple input formats, input_init could
- X set up an appropriate get_input_row method depending on the format it
- X finds. Note that in most applications, the selection and opening of the
- X input file will be under the control of the user interface module; and
- X indeed the user interface may have already read the input header, so that
- X all that input_init may have to do is return previously saved values. The
- X behind-the-scenes interaction between this object and the user interface is
- X not specified by this architecture.
- X (Hides format of input image and mechanism used to read it. This code is
- X likely to vary considerably from one implementation to another. Note that
- X the color space and number of color components of the source are not hidden;
- X but they are used only by the next object.)
- X
- END_OF_FILE
- if test 29060 -ne `wc -c <'arch.a'`; then
- echo shar: \"'arch.a'\" unpacked with wrong size!
- elif [ -f arch.b ]; then
- echo shar: Combining \"'arch.a'\" and \"'arch.b'\" into \"'architecture'\"
- cat arch.a arch.b > architecture
- echo shar: Removing \"'arch.a'\" and \"'arch.b'\"
- rm arch.a arch.b
- # end of 'arch.a'
- fi
- fi
- if test -f 'makefile.vms' -a "${1}" != "-c" ; then
- echo shar: Will not clobber existing file \"'makefile.vms'\"
- else
- echo shar: Extracting \"'makefile.vms'\" \(2044 characters\)
- sed "s/^X//" >'makefile.vms' <<'END_OF_FILE'
- X$! Makefile for Independent JPEG Group's software
- X$!
- X$! This is a command procedure for use on VAX/VMS systems that do not have MMS.
- X$! It builds the JPEG software by brute force, recompiling everything whether
- X$! or not it is necessary.
- X$! Thanks to Rick Dyson (dyson@iowasp.physics.uiowa.edu) for his help.
- X$!
- X$! Read SETUP instructions before running this!!
- X$!
- X$ DoCompile := CC /NoDebug /Optimize /Define = (TWO_FILE_COMMANDLINE,HAVE_STDC,INCLUDES_ARE_ANSI)
- X$!
- X$ DoCompile jcmain.c
- X$ DoCompile jdmain.c
- X$ DoCompile jcmaster.c
- X$ DoCompile jcdeflts.c
- X$ DoCompile jcarith.c
- X$ DoCompile jccolor.c
- X$ DoCompile jcexpand.c
- X$ DoCompile jchuff.c
- X$ DoCompile jcmcu.c
- X$ DoCompile jcpipe.c
- X$ DoCompile jcsample.c
- X$ DoCompile jfwddct.c
- X$ DoCompile jwrjfif.c
- X$ DoCompile jrdgif.c
- X$ DoCompile jrdppm.c
- X$ DoCompile jrdrle.c
- X$ DoCompile jrdtarga.c
- X$ DoCompile jdmaster.c
- X$ DoCompile jddeflts.c
- X$ DoCompile jbsmooth.c
- X$ DoCompile jdarith.c
- X$ DoCompile jdcolor.c
- X$ DoCompile jdhuff.c
- X$ DoCompile jdmcu.c
- X$ DoCompile jdpipe.c
- X$ DoCompile jdsample.c
- X$ DoCompile jquant1.c
- X$ DoCompile jquant2.c
- X$ DoCompile jrevdct.c
- X$ DoCompile jrdjfif.c
- X$ DoCompile jwrgif.c
- X$ DoCompile jwrppm.c
- X$ DoCompile jwrrle.c
- X$ DoCompile jwrtarga.c
- X$ DoCompile jutils.c
- X$ DoCompile jerror.c
- X$ DoCompile jmemmgr.c
- X$ DoCompile jmemsys.c
- X$!
- X$ Library /Create libjpeg.olb jcmaster.obj,jcdeflts.obj,jcarith.obj, -
- X jccolor.obj,jcexpand.obj,jchuff.obj,jcmcu.obj,jcpipe.obj, -
- X jcsample.obj,jfwddct.obj,jwrjfif.obj,jrdgif.obj,jrdppm.obj, -
- X jrdrle.obj,jrdtarga.obj,jdmaster.obj,jddeflts.obj,jbsmooth.obj, -
- X jdarith.obj,jdcolor.obj,jdhuff.obj,jdmcu.obj,jdpipe.obj, -
- X jdsample.obj,jquant1.obj,jquant2.obj,jrevdct.obj,jrdjfif.obj, -
- X jwrgif.obj,jwrppm.obj,jwrrle.obj,jwrtarga.obj,jutils.obj, -
- X jerror.obj,jmemmgr.obj,jmemsys.obj
- X$!
- X$ Link /Executable = cjpeg.exe jcmain.obj,libjpeg.olb/Library,Sys$Disk:[]MAKVMS.OPT/Option
- X$!
- X$ Link /Executable = djpeg.exe jdmain.obj,libjpeg.olb/Library,Sys$Disk:[]MAKVMS.OPT/Option
- X$!
- X$ Exit
- END_OF_FILE
- if test 2044 -ne `wc -c <'makefile.vms'`; then
- echo shar: \"'makefile.vms'\" unpacked with wrong size!
- fi
- # end of 'makefile.vms'
- fi
- echo shar: End of archive 1 \(of 18\).
- cp /dev/null ark1isdone
- MISSING=""
- for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ; do
- if test ! -f ark${I}isdone ; then
- MISSING="${MISSING} ${I}"
- fi
- done
- if test "${MISSING}" = "" ; then
- echo You have unpacked all 18 archives.
- rm -f ark[1-9]isdone ark[1-9][0-9]isdone
- else
- echo You still must unpack the following archives:
- echo " " ${MISSING}
- fi
- exit 0
- exit 0 # Just in case...
-