install.doc

linux下的jpeg解码库

inline-able.  Some compilers have a switch that tells the compiler to inline
any function it thinks is profitable (e.g., -finline-functions for gcc).
Enabling such a switch is likely to make the compiled code bigger but faster.

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 [e-mail] 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 [e-mail].  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:

(Thanks to Simon Middleton for these hints on compiling with Desktop C.)
After renaming the files according to Acorn conventions, take a copy of
makefile.ansi, change all occurrences of 'libjpeg.a' to 'libjpeg.o' and
change these definitions as indicated:

CFLAGS= -throwback -IC: -Wn
LDLIBS=C:o.Stubs
SYSDEPMEM=jmemansi.o
LN=Link
AR=LibFile -c -o

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
and CHAR_IS_UNSIGNED.

Run the makefile using !AMU not !Make.  If you want to use the 'clean' and
'test' makefile entries then you will have to fiddle with the syntax a bit
and rename the test files.


Amiga:

SAS C 6.50 reportedly is too buggy to compile the IJG code properly.
A patch to update to 6.51 is available from SAS or AmiNet FTP sites.

The supplied config files are set up to use jmemname.c as the memory
manager, with temporary files being created on the device named by
"JPEGTMP:".


Atari ST/STE/TT:
 
Copy the project files makcjpeg.st, makdjpeg.st, maktjpeg.st, and makljpeg.st
to cjpeg.prj, djpeg.prj, jpegtran.prj, and libjpeg.prj respectively.  The
project files should work as-is with Pure C.  For Turbo C, change library
filenames "pc..." to "tc..." in each project file.  Note that libjpeg.prj
selects jmemansi.c as the recommended memory manager.  You'll probably want to
adjust the DEFAULT_MAX_MEM setting --- you want it to be a couple hundred K
less than your normal free memory.  Put "#define DEFAULT_MAX_MEM nnnn" into
jconfig.h to do this.

To use the 68881/68882 coprocessor for the floating point DCT, add the
compiler option "-8" to the project files and replace pcfltlib.lib with
pc881lib.lib in cjpeg.prj and djpeg.prj.  Or if you don't have a
coprocessor, you may prefer to remove the float DCT code by undefining
DCT_FLOAT_SUPPORTED in jmorecfg.h (since without a coprocessor, the float
code will be too slow to be useful).  In that case, you can delete
pcfltlib.lib from the project files.

Note that you must make libjpeg.lib before making cjpeg.ttp, djpeg.ttp,
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.

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
an abnormal program exit.  If you check your disk afterwards, you will find
cluster chains that are allocated but not used by a file.  This should not
happen in cjpeg/djpeg/jpegtran, since we enable a signal catcher to explicitly
close temp files before exiting.  But if you use the JPEG library with your
own code, be sure to supply a signal catcher, or else use a different
system-dependent memory manager.


Cray:

Should you be so fortunate as to be running JPEG on a Cray YMP, there is a
compiler bug in old versions of Cray's Standard C (prior to 3.1).  If you
still have an old compiler, you'll need to insert a line reading
"#pragma novector" just before the loop	
    for (i = 1; i <= (int) htbl->bits[l]; i++)
      huffsize[p++] = (char) l;
in fix_huff_tbl (in V5beta1, line 204 of jchuff.c and line 176 of jdhuff.c).
[This bug may or may not still occur with the current IJG code, but it's
probably a dead issue anyway...]


HP-UX:

If you have HP-UX 7.05 or later with the "software development" C compiler,
you should run the compiler in ANSI mode.  If using the configure script,
say
	./configure CC='cc -Aa'
(or -Ae if you prefer).  If configuring by hand, use makefile.ansi and add
"-Aa" to the CFLAGS line in the makefile.

If you have a pre-7.05 system, or if you are using the non-ANSI C compiler
delivered with a minimum HP-UX system, then you must use makefile.unix
(and do NOT add -Aa); or just run configure without the CC option.

On HP 9000 series 800 machines, the HP C compiler is buggy in revisions prior
to A.08.07.  If you get complaints about "not a typedef name", you'll have to
use makefile.unix, or run configure without the CC option.


Macintosh, generic comments:

The supplied user-interface files (cjpeg.c, djpeg.c, etc) are set up to
provide a Unix-style command line interface.  You can use this interface on
the Mac by means of the ccommand() library routine provided by Metrowerks
CodeWarrior or Think C.  This is only appropriate for testing the library,
however; to make a user-friendly equivalent of cjpeg/djpeg you'd really want
to develop a Mac-style user interface.  There isn't a complete example
available at the moment, but there are some helpful starting points:
1. Sam Bushell's free "To JPEG" applet provides drag-and-drop conversion to
JPEG under System 7 and later.  This only illustrates how to use the
compression half of the library, but it does a very nice job of that part.
The CodeWarrior source code is available from http://www.pobox.com/~jsam.
2. Jim Brunner prepared a Mac-style user interface for both compression and
decompression.  Unfortunately, it hasn't been updated since IJG v4, and
the library's API has changed considerably since then.  Still it may be of
some help, particularly as a guide to compiling the IJG code under Think C.
Jim's code is available from the Info-Mac archives, at sumex-aim.stanford.edu
or mirrors thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.

jmemmac.c is the recommended memory manager back end for Macintosh.  It uses
NewPtr/DisposePtr instead of malloc/free, and has a Mac-specific
implementation of jpeg_mem_available().  It also creates temporary files that
follow Mac conventions.  (That part of the code relies on System-7-or-later OS
functions.  See the comments in jmemmac.c if you need to run it on System 6.)
NOTE that USE_MAC_MEMMGR must be defined in jconfig.h to use jmemmac.c.

You can also use jmemnobs.c, if you don't care about handling images larger
than available memory.  If you use any memory manager back end other than
jmemmac.c, we recommend replacing "malloc" and "free" by "NewPtr" and
"DisposePtr", because Mac C libraries often have peculiar implementations of
malloc/free.  (For instance, free() may not return the freed space to the
Mac Memory Manager.  This is undesirable for the IJG code because jmemmgr.c
already clumps space requests.)


Macintosh, Metrowerks CodeWarrior:

The Unix-command-line-style interface can be used by defining USE_CCOMMAND.
You'll also need to define TWO_FILE_COMMANDLINE to avoid stdin/stdout.
This means that when using the cjpeg/djpeg programs, you'll have to type the
input and output file names in the "Arguments" text-edit box, rather than
using the file radio buttons.  (Perhaps USE_FDOPEN or USE_SETMODE would
eliminate the problem, but I haven't heard from anyone who's tried it.)

On 680x0 Macs, Metrowerks defines type "double" as a 10-byte IEEE extended
float.  jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power
of 2.  Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.

The supplied configuration file jconfig.mac can be used for your jconfig.h;
it includes all the recommended symbol definitions.  If you have AppleScript
installed, you can run the supplied script makeproj.mac to create CodeWarrior
project files for the library and the testbed applications, then build the
library and applications.  (Thanks to Dan Sears and Don Agro for this nifty
hack, which saves us from trying to maintain CodeWarrior project files as part
of the IJG distribution...)


Macintosh, Think C:

The documentation in Jim Brunner's "JPEG Convert" source code (see above)
includes detailed build instructions for Think C; it's probably somewhat
out of date for the current release, but may be helpful.

If you want to build the minimal command line version, proceed as follows.
You'll have to prepare project files for the programs; we don't include any
in the distribution since they are not text files.  Use the file lists in
any of the supplied makefiles as a guide.  Also add the ANSI and Unix C
libraries in a separate segment.  You may need to divide the JPEG files into
more than one segment; we recommend dividing compression and decompression
modules.  Define USE_CCOMMAND in jconfig.h so that the ccommand() routine is
called.  You must also define TWO_FILE_COMMANDLINE because stdin/stdout
don't handle binary data correctly.

On 680x0 Macs, Think C defines type "double" as a 12-byte IEEE extended float.
jmemmgr.c won't like this: it wants sizeof(ALIGN_TYPE) to be a power of 2.
Add "#define ALIGN_TYPE long" to jconfig.h to eliminate the complaint.

jconfig.mac should work as a jconfig.h configuration file for Think C,
but the makeproj.mac AppleScript script is specific to CodeWarrior.  Sorry.


MIPS R3000:

MIPS's cc version 1.31 has a rather nasty optimization bug.  Don't use -O
if you have that compiler version.  (Use "cc -V" to check the version.)
Note that the R3000 chip is found in workstations from DEC and others.


MS-DOS, generic comments for 16-bit compilers:

The IJG code is designed to work well in 80x86 "small" or "medium" memory
models (i.e., data pointers are 16 bits unless explicitly declared "far";
code pointers can be either size).  You may be able to use small model to
compile cjpeg or djpeg by itself, but you will probably have to use medium
model for any larger application.  This won't make much difference in
performance.  You *will* take a noticeable performance hit if you use a
large-data memory model, and you should avoid "huge" model if at all
possible.  Be sure that NEED_FAR_POINTERS is defined in jconfig.h if you use
a small-data memory model; be sure it is NOT defined if you use a large-data
model.  (The supplied makefiles and jconfig files for Borland and Microsoft C
compile in medium model and define NEED_FAR_POINTERS.)

The DOS-specific memory manager, jmemdos.c, should be used if possible.
It needs some assembly-code routines which are in jmemdosa.asm; make sure
your makefile assembles that file and includes it in the library.  If you
don't have a suitable assembler, you can get pre-assembled object files for
jmemdosa by FTP from ftp.uu.net:/graphics/jpeg/jdosaobj.zip.  (DOS-oriented
distributions of the IJG source code often include these object files.)

When using jmemdos.c, jconfig.h must define USE_MSDOS_MEMMGR and must set
MAX_ALLOC_CHUNK to less than 64K (65520L is a typical value).  If your
C library's far-heap malloc() can't allocate blocks that large, reduce
MAX_ALLOC_CHUNK to whatever it can handle.

If you can't use jmemdos.c for some reason --- for example, because you
don't have an assembler to assemble jmemdosa.asm --- you'll have to fall
back to jmemansi.c or jmemname.c.  You'll probably still need to set
MAX_ALLOC_CHUNK in jconfig.h, because most DOS C libraries won't malloc()
more than 64K at a time.  IMPORTANT: if you use jmemansi.c or jmemname.c,
you will have to compile in a large-data memory model in order to get the
right stdio library.  Too bad.

wrjpgcom needs to be compiled in large model, because it malloc()s a 64KB
work area to hold the comment text.  If your C library's malloc can't
handle that, reduce MAX_COM_LENGTH as necessary in wrjpgcom.c.

Most MS-DOS compilers treat stdin/stdout as text files, so you must use
two-file command line style.  But if your compiler has either fdopen() or
setmode(), you can use one-file style if you like.  To do this, define
USE_SETMODE or USE_FDOPEN so that stdin/stdout will be set to binary mode.
(USE_SETMODE seems to work with more DOS compilers than USE_FDOPEN.)  You
should test that I/O through stdin/stdout produces the same results as I/O
to explicitly named files... the "make test" procedures in the supplied
makefiles do NOT use stdin/stdout.


MS-DOS, generic comments for 32-bit compilers:

None of the above comments about memory models apply if you are using a
32-bit flat-memory-space environment, such as DJGPP or Watcom C.  (And you
should use one if you have it, as performance will be much better than
8086-compatible code!)  For flat-memory-space compilers, do NOT define