install.doc

Jpeg source code,jpeg编码解码示范

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.  Such an interface exists for pre-v5
IJG libraries (see the Think C entry, below) but at this writing it has not
been updated to work with the current release.

We recommend replacing "malloc" and "free" by "NewPtr" and "DisposePtr" in
whichever memory manager back end you use, because Mac C libraries often
have inferior implementations of malloc/free.  jmemmac.c is recommended;
it is a customized version of jmemansi.c with this change and a Mac-specific
implementation of jpeg_mem_available().  You can also use jmemnobs.c if you
don't care about handling images larger than available memory.


Macintosh, MPW:

We don't directly support MPW in the current release, but Larry Rosenstein
ported an earlier version of the IJG code without very much trouble.  There's
useful notes and conversion scripts in his kit for porting PBMPLUS to MPW.
You can obtain the kit by FTP to ftp.apple.com, files /pub/lsr/pbmplus-port*.


Macintosh, Metrowerks CodeWarrior:

Metrowerks release DR2 has problems with the IJG code; don't use it.  Release
DR3.5 or later should be OK.

The Unix-command-line-style interface can be used by defining USE_CCOMMAND.
You'll also need to define either TWO_FILE_COMMANDLINE (to avoid stdin/stdout)
or USE_FDOPEN (to make stdin/stdout work in binary mode).  See the Think C
entry for more details.

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.


Macintosh, Think C:

Jim Brunner has prepared a Mac-style user interface for the IJG library.
Unfortunately, the released version of it only works with pre-v5 libraries;
still, it may be a useful starting point.  You can obtain Jim's additional
source code from the Info-Mac archives, at sumex-aim.stanford.edu or mirrors
thereof; see file /info-mac/dev/src/jpeg-convert-c.hqx.  Jim's documentation
also includes more detailed build instructions for Think C.

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.


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 be compiled 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
NEED_FAR_POINTERS, and do NOT use jmemdos.c.  Use jmemnobs.c if the
environment supplies adequate virtual memory, otherwise use jmemansi.c or
jmemname.c.

You'll still need to be careful about binary I/O through stdin/stdout.
See the last paragraph of the previous section.


MS-DOS, Borland C:

Be sure to convert all the source files to DOS text format (CR/LF newlines).
Although Borland C will often work OK with unmodified Unix (LF newlines)
source files, sometimes it will give bogus compile errors.
"Illegal character '#'" is the most common such error.  (This is true with
Borland C 3.1, but perhaps is fixed in newer releases.)

If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
jconfig.bcc already includes #define USE_SETMODE to make this work.
(fdopen does not work correctly.)


MS-DOS, DJGPP:

Use a recent version of DJGPP (1.11 or better).  If you prefer two-file
command line style, change the supplied jconfig.dj to define
TWO_FILE_COMMANDLINE.  makefile.dj is set up to generate only COFF files
(cjpeg, djpeg, etc) when you say make.  After testing, say "make exe" to
make executables with stub.exe, or "make standalone" if you want executables
that include go32.  You will probably need to tweak the makefile's pointer to
go32.exe to do "make standalone".


MS-DOS, Microsoft C:

makefile.mc6 works with Microsoft C, Visual C++, etc.  Note that this
makefile assumes that the working copy of itself is called "makefile".
If you want to call it something else, say "makefile.mak", be sure to adjust
the dependency line that reads "$(RFILE) : makefile".  Otherwise the make
will fail because it doesn't know how to create "makefile".  Worse, some
releases of Microsoft's make utilities give an incorrect error message in
this situation.

If you want one-file command line style, just undefine TWO_FILE_COMMANDLINE.
jconfig.mc6 already includes #define USE_SETMODE to make this work.
(fdopen does not work correctly.)

Old versions of MS C fail with an "out of macro expansion space" error
because they can't cope with the macro TRACEMS8 (defined in jerror.h).
If this happens to you, the easiest solution is to change TRACEMS8 to
expand to nothing.  You'll lose the ability to dump out JPEG coefficient
tables with djpeg -debug -debug, but at least you can compile.

Original MS C 6.0 is very buggy; it compiles incorrect code unless you turn
off optimization entirely (remove -O from CFLAGS).  6.00A is better, but it
still generates bad code if you enable loop optimizations (-Ol or -Ox).

MS C 8.0 reportedly fails to compile jquant1.c if optimization is turned off
(yes, off).


Microsoft Windows (all versions):

Some Windows system include files define typedef boolean as "unsigned char".
The IJG code also defines typedef boolean, but we make it "int" by default.
This doesn't affect the IJG programs because we don't import those Windows
include files.  But if you use the JPEG library in your own program, and some
of your program's files import one definition of boolean while some import the
other, you can get all sorts of mysterious problems.  A good preventive step
is to change jmorecfg.h to define boolean as unsigned char.  We recommend
making that part of jmorecfg.h read like this:
	#ifndef __RPCNDR_H__	/* don't conflict if rpcndr.h already read */
	typedef unsigned char boolean;
	#endif
In v6a and later, using incompatible definitions of boolean will usually lead
to the failure message "JPEG parameter struct mismatch", rather than the
difficult-to-diagnose bugs it caused with earlier versions.

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
default error handler does a couple of inappropriate things:
  1. it tries to write error and warning messages on stderr;
  2. in event of a fatal error, it exits by calling exit().
A simple stopgap solution for problem 1 is to replace the line
	fprintf(stderr, "%s\n", buffer);
(in output_message in jerror.c) with something like
	MessageBox(GetActiveWindow(),buffer,"JPEG Error",MB_OK);
It's highly recommended that you at least do that much, since otherwise
error messages will disappear into nowhere.
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.

You may also want to modify jdatasrc.c and jdatadst.c to use Windows file
operations rather than fread/fwrite.  This is only necessary if your C
compiler doesn't provide a competent implementation of C stdio functions.

Many people want to convert the IJG library into a DLL.  This is reasonably
straightforward, but watch out for the following:
  1. Don't try to compile as a DLL in small or medium memory model; use
large model, or even better, 32-bit flat model.  Many places in the IJG code
assume the address of a local variable is an ordinary (not FAR) pointer;
that isn't true in a medium-model DLL.
  2. Microsoft C cannot pass file pointers between applications and DLLs.
(See Microsoft Knowledge Base, PSS ID Number Q50336.)  So jdatasrc.c and
jdatadst.c don't work if you open a file in your application and then pass
the pointer to the DLL.  One workaround is to make jdatasrc.c/jdatadst.c
part of your main application rather than part of the DLL.
  3. You'll probably need to modify the macros GLOBAL() and EXTERN() to
attach suitable linkage keywords to the exported routine names.  Similarly,
you'll want to modify METHODDEF() and JMETHOD() to ensure function pointers
are declared in a way that lets application routines be called back through
the function pointers.  These macros are in jmorecfg.h.  Typical definitions
for a 16-bit DLL are:
	#define GLOBAL(type)		type _far _pascal _loadds _export
	#define EXTERN(type)		extern type _far _pascal
	#define METHODDEF(type)		static type _far _pascal
	#define JMETHOD(type,methodname,arglist)  \
		type (_far _pascal *methodname) arglist
Although not all the GLOBAL routines are actually intended to be called by
the application, the performance cost of making them all DLL entry points is
negligible.

The unmodified IJG library presents a very C-specific application interface,
so the resulting DLL is only usable from C or C++ applications.  There has
been some talk of writing wrapper code that would present a simpler interface
usable from other languages, such as Visual Basic.  This is on our to-do list
but hasn't been very high priority --- any volunteers out there?


Microsoft Windows, Borland C:

Borland C++ 4.5 fails with an internal compiler error when trying to compile
jdmerge.c in 32-bit mode.  If enough people complain, perhaps Borland will fix
it.  In the meantime, the simplest known workaround is to add a redundant
definition of the variable range_limit in h2v1_merged_upsample(), at the head
of the block that handles odd image width (about line 268 in v6 jdmerge.c):
  /* If image width is odd, do the last output column separately */
  if (cinfo->output_width & 1) {
    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
    cb = GETJSAMPLE(*inptr1);
Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
doesn't trigger the bug.
Recent reports suggest that this bug does not occur with "bcc32a" (the
Pentium-optimized version of the compiler).


SGI:

On some SGI systems, you may need to set "AR2= ar -ts" in the Makefile.
If you are using configure, you can do this by saying
	./configure RANLIB='ar -ts'
This change is not needed on all SGIs.  Use it only if the make fails at the
stage of linking the completed programs.

On the MIPS R4000 architecture (Indy, etc.), the compiler option "-mips2"
reportedly speeds up the float DCT method substantially, enough to make it
faster than the default int method (but still slower than the fast int
method).  If you use -mips2, you may want to alter the default DCT method to
be float.  To do this, put "#define JDCT_DEFAULT JDCT_FLOAT" in jconfig.h.


VMS:

On an Alpha/VMS system with MMS, be sure to use the "/Marco=Alpha=1"
qualifier with MMS when building the JPEG package.

VAX/VMS v5.5-1 may have problems with the test step of the build procedure
reporting differences when it compares the original and test images.  If the
error points to the last block of the files, it is most likely bogus and may
be safely ignored.  It seems to be because the files are Stream_LF and
Backup/Compare has difficulty with the (presumably) null padded files.
This problem was not observed on VAX/VMS v6.1 or AXP/VMS v6.1.