home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Otherware
/
Otherware_1_SB_Development.iso
/
amiga
/
video
/
viewers
/
augjpeg.lzh
/
README
< prev
next >
Wrap
Text File
|
1991-08-15
|
10KB
|
224 lines
README 15-Aug-91
==================
This distribution contains the fourth draft of the free JPEG working group's
results. The copyright status of this code has not yet been decided, but in
any case we intend to make it freely usable by all comers, for either
commercial or non-commercial purposes. You may incorporate derivatives of
this code into proprietary products, so long as you do not attempt to stop
other people from using the original code (by copyrighting it yourself, for
example).
This code is the work of Tom Lane, Philip Gladstone, Luis Ortiz, and other
members of the free JPEG working group.
THIS CODE IS NOT COMPLETE NOR DEBUGGED. It is not guaranteed to be useful for
anything, nor to be compatible with subsequent releases.
Please report problems to tgl@cs.cmu.edu.
WHAT'S HERE
===========
This distribution contains a skeleton system based on the "architecture"
document I sent out a while ago (the latest draft of which is included).
The intermodule interfaces are fully fleshed out, but many of the modules
are just stubs or minimal implementations. The code does compile and it can
compress or decompress JPEG files into raw-format PPM or PGM files.
This software can be used on several levels:
* As canned software for PPM<=>JPEG conversion. Just edit the Makefile and
configuration files as needed (see SETUP), compile and go. Members of the
JPEG group will improve the out-of-the-box functionality as time goes on.
* As the basis for other JPEG programs. For example, you could incorporate
the decompressor into a general image viewing package by replacing the
output module with write-to-screen functions. For an implementation on
specific hardware, you might want to replace some of the inner loops with
assembly code. For a non-command-line-driven system, you might want a
different user interface. (Members of the group will be producing Macintosh
and Amiga versions with appropriate user interfaces, for example.)
* As a toolkit for experimentation with JPEG and JPEG-like algorithms. Most
of the individual decisions you might want to mess with are packaged up into
separate modules. For example, the details of color-space conversion and
subsampling techniques are each localized in one compressor and one
decompressor module. You'd probably also want to revise the user interface
to give you more detailed control over the JPEG compression parameters.
SETUP
=====
First, select a makefile and copy it to "Makefile". "makefile.unix"
is appropriate for most Unix and Unix-like systems. Special makefiles are
included for various PC compilers.
Look over the makefile and adjust options as needed. In particular, you'll
need to change the CC= and CFLAGS= definitions if you don't have gcc. If you
have a function-prototype-less compiler, be sure to uncomment the .c.o rule
and say "make ansi2knr". (Thanks to Peter Deutsch for ansi2knr.)
Also look over jconfig.h and adjust #defines as necessary. If you have an
ANSI-compilant C compiler (gcc for instance), no changes should be necessary
except for RIGHT_SHIFT_IS_UNSIGNED. For older compilers other mods may be
needed depending on what ANSI features are supported.
Then say "make".
If you have trouble with missing system include files or inclusion of the
wrong ones, you can fix it in jinclude.h.
Note you DON'T need the PBMPLUS library to compile; for the moment I made
hard-wired PPM read/write routines (sorry 'bout that, Jef). However, you'll
need the PBMPLUS program suite in order to accomplish much of anything useful,
since only PPM/PGM-format image files are currently supported.
As a quick test of functionality I've included three sample files.
testorig.jpg same as blkint.jpg from JPEG validation floppy.
testimg.ppm output of djpeg testorig.jpg
testimg.jpg output of cjpeg testimg.ppm
The two .jpg files aren't identical due to different parameter choices (and
wouldn't be anyway, since JPEG is lossy). However, if you can generate
duplicates of testimg.ppm and testimg.jpg then you probably have a working
port. "make test" will perform the necessary comparisons (by generating
testout.ppm and testout.jpg and comparing these to testimg.*).
If you need to make a smaller version of the JPEG software, some optional
functions can be removed at compile time. See the xxx_SUPPORTED #defines
in jconfig.h. (Not a lot is actually removed right now, but as more optional
stuff gets added, this mechanism will start to make a difference.)
USAGE
=====
The user interface is pretty minimal at this point. I haven't bothered to
generate man pages since the options need reconsideration anyhow. At the
moment, things work like this:
To compress: cjpeg [options] [file.ppm] >file.jpg
To decompress: djpeg [options] [file.jpg] >file.ppm
The programs read the specified input file, or standard input if none is
named. They always write to standard output (with trace/error messages to
standard error). The non-JPEG file format is raw-format PPM, or PGM for
monochrome images.
The command line options for cjpeg are:
-I Generate noninterleaved file (not yet supported).
-Q quality Scale quantization tables to adjust quality.
Quality is 0 (worst) to 100 (best); default is 75.
-a Use arithmetic coding rather than Huffman coding.
(Not currently supported, see LEGAL ISSUES.)
-o Perform optimization of entropy encoding parameters.
Without this, default Huffman or arithmetic
parameters are used. -o makes the JPEG file a tad
smaller, but compression uses much more memory.
Image quality is unaffected by -o.
-d Enable debug printout. More -d's give more printout.
-Q 100 will generate a quantization table of all 1's, meaning no quantization
loss; then any differences between input and output images are due to roundoff
error in the DCT or colorspace-conversion steps. Try -Q 2 (or so) for some
nice Cubist effects. (Note that -Q values below about 25 generate 2-byte
quantization tables, which are not decodable by pure baseline JPEG decoders.
cjpeg emits a warning message when you give such a -Q value.)
The command line options for djpeg are:
-b Perform cross-block smoothing. This is quite
memory-intensive & doesn't seem to help a lot
(I'm not convinced we've implemented it correctly).
-q n Quantize to n colors.
-D Use Floyd-Steinberg dithering in color quantization.
-2 Use two-pass color quantization (not yet supported).
-d Enable debug printout. More -d's give more printout.
Color quantization currently uses a rather shoddy algorithm (although it's not
too bad when dithered). You can get better results by applying ppmquant to
the unquantized output of djpeg.
Note that djpeg *can* read noninterleaved files even though cjpeg can't yet
generate them.
REFERENCES
==========
The best and most readily available introduction to the JPEG compression
algorithm is Wallace's article in the April '91 CACM:
Wallace, Gregory K. "The JPEG Still Picture Compression Standard",
Communications of the ACM, April 1991 (v. 34 no. 4), pp. 30-44.
(Adjacent articles in that issue discuss MPEG motion picture compression,
applications of JPEG, and related topics.) I highly recommend reading that
article before looking at any of the JPEG code.
For more detail about the JPEG standard you pretty much have to go to the
draft standard, which is not nearly as intelligible as Wallace's article.
The current version is ISO/IEC Committee Draft CD 10918-1 dated 1991-03-15.
SUPPORTING SOFTWARE
===================
You will probably want Jef Poskanzer's PBMPLUS image software; this 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. You can FTP
this free software from export.lcs.mit.edu (contrib/pbmplus.tar.Z) or
ftp.ee.lbl.gov (pbmplus.tar.Z).
If you are using X Windows you might want to use the xv or xloadimage viewers
to save yourself the trouble of converting PPM to some other format.
I believe both of these can be found in the contrib directory at
export.lcs.mit.edu.
LEGAL ISSUES
============
It appears that the arithmetic coding option of the JPEG spec is covered by
patents held by IBM, and possibly also patents of AT&T and Mitsubishi. Hence
arithmetic coding cannot legally be used without obtaining one or more
licenses. For this reason, support for arithmetic coding has been removed
from the free JPEG software. (Since arithmetic coding provides only a
marginal gain over the unpatented Huffman mode, it is unlikely that very many
people will choose to use it. If you do obtain such a license, contact me for
a copy of our arithmetic coding modules.) So far as I am aware, there are no
patent or copyright restrictions on the remaining code.
It may prove necessary for the free JPEG group to copyright this software.
(I have heard, for example, that copyright is required for any software to
be distributed as X Windows contrib software.) If we do that, we will not
place any restrictions on the distribution, use, or modification of the code.
TO DO
=====
Obviously most of the modules need fleshing out to provide more complete
implementations, or to provide faster paths for common cases. I would suggest
that we not start doing that just yet, but instead test out how portable the
code is and eliminate any portability problems that have snuck into the
intermodule interfaces. That way, subsequent improvement of individual
modules can proceed pretty much in isolation.
I'd appreciate it if people would compile and check out the code on as wide a
variety of systems as possible, and let me know of any portability problems
encountered (with solutions, if possible). I expect I missed some places
where casts were needed, and the usage of standard include files probably
still has some problems.
The current code seems to be reasonably portable to MS-DOS. The existing
memory manager module (jvirtmem.c) will eventually need to be replaced with
one that can swap "big" images out to temp files, but the current code doesn't
ask for big images (unless you use -I, -o or -b), so that functionality isn't
essential yet.
tom lane
tgl@cs.cmu.edu