makefile to equal the corresponding object file name (for example, jmemansi.oor jmemansi.obj for jmemansi.c).If you have plenty of (real or virtual) main memory, just use jmemnobs.c."Plenty" means about ten bytes for every pixel in the largest imagesyou plan to process, so a lot of systems don't meet this criterion.If yours doesn't, try jmemansi.c first.  If that doesn't compile, you'll haveto use jmemname.c; be sure to adjust select_file_name() for local conditions.You may also need to change unlink() to remove() in close_backing_store().Except with jmemnobs.c or jmemmac.c, you need to adjust the DEFAULT_MAX_MEMsetting to a reasonable value for your system (either by adding a #define forDEFAULT_MAX_MEM to jconfig.h, or by adding a -D switch to the Makefile).This value limits the amount of data space the program will attempt toallocate.  Code and static data space isn't counted, so the actual memoryneeds for cjpeg or djpeg are typically 100 to 150Kb more than the max-memorysetting.  Larger max-memory settings reduce the amount of I/O needed toprocess a large image, but too large a value can result in "insufficientmemory" failures.  On most Unix machines (and other systems with virtualmemory), just set DEFAULT_MAX_MEM to several million and forget it.  At theother end of the spectrum, for MS-DOS machines you probably can't go muchabove 300K to 400K.  (On MS-DOS the value refers to conventional memory only.Extended/expanded memory is handled separately by jmemdos.c.)BUILDING THE SOFTWARE=====================Now you should be able to compile the software.  Just say "make" (orwhatever's necessary to start the compilation).  Have a cup of coffee.Here are some things that could go wrong:If your compiler complains about undefined structures, you should be able toshut it up by putting "#define INCOMPLETE_TYPES_BROKEN" in jconfig.h.If you have trouble with missing system include files or inclusion of thewrong ones, read jinclude.h.  This shouldn't happen if you used configureor ckconfig.c to set up jconfig.h.There are a fair number of routines that do not use all of their parameters;some compilers will issue warnings about this, which you can ignore.  Thereare also a few configuration checks that may give "unreachable code" warnings.Any other warning deserves investigation.If you don't have a getenv() library routine, define NO_GETENV.Also see the system-specific hints, below.TESTING THE SOFTWARE====================As a quick test of functionality we've included a small sample image inseveral forms:	testorig.jpg	Starting point for the djpeg tests.	testimg.ppm	The output of djpeg testorig.jpg	testimg.bmp	The output of djpeg -bmp -colors 256 testorig.jpg	testimg.jpg	The output of cjpeg testimg.ppm	testprog.jpg	Progressive-mode equivalent of testorig.jpg.	testimgp.jpg	The output of cjpeg -progressive -optimize testimg.ppm(The first- and second-generation .jpg files aren't identical since JPEG islossy.)  If you can generate duplicates of the testimg* files then youprobably have working programs.With most of the makefiles, "make test" will perform the necessarycomparisons.If you're using a makefile that doesn't provide the test option, run djpegand cjpeg by hand and compare the output files to testimg* with whateverbinary file comparison tool you have.  The files should be bit-for-bitidentical.If the programs complain "MAX_ALLOC_CHUNK is wrong, please fix", then youneed to reduce MAX_ALLOC_CHUNK to a value that fits in type size_t.Try adding "#define MAX_ALLOC_CHUNK 65520L" to jconfig.h.  A less likelyconfiguration error is "ALIGN_TYPE is wrong, please fix": defining ALIGN_TYPEas long should take care of that one.If the cjpeg test run fails with "Missing Huffman code table entry", it's agood bet that you needed to define RIGHT_SHIFT_IS_UNSIGNED.  Go back to theconfiguration step and run ckconfig.c.  (This is a good plan for any othertest failure, too.)If you are using Unix (one-file) command line style on a non-Unix system,it's a good idea to check that binary I/O through stdin/stdout actuallyworks.  You should get the same results from "djpeg <testorig.jpg >out.ppm"as from "djpeg -outfile out.ppm testorig.jpg".  Note that the makefiles alluse the latter style and therefore do not exercise stdin/stdout!  If thischeck fails, try recompiling with USE_SETMODE or USE_FDOPEN defined.If it still doesn't work, better use two-file style.If you chose a memory manager other than jmemnobs.c, you should test thattemporary-file usage works.  Try "djpeg -bmp -colors 256 -max 0 testorig.jpg"and make sure its output matches testimg.bmp.  If you have any really largeimages handy, try compressing them with -optimize and/or decompressing with-colors 256 to make sure your DEFAULT_MAX_MEM setting is not too large.NOTE: this is far from an exhaustive test of the JPEG software; some modules,such as 1-pass color quantization, are not exercised at all.  It's just aquick test to give you some confidence that you haven't missed somethingmajor.INSTALLING THE SOFTWARE=======================Once you're done with the above steps, you can install the software bycopying the executable files (cjpeg, djpeg, jpegtran, rdjpgcom, and wrjpgcom)to wherever you normally install programs.  On Unix systems, you'll also wantto put the man pages (cjpeg.1, djpeg.1, jpegtran.1, rdjpgcom.1, wrjpgcom.1)in the man-page directory.  The pre-fab makefiles don't support this stepsince there's such a wide variety of installation procedures on differentsystems.If you generated a Makefile with the "configure" script, you can just say	make installto install the programs and their man pages into the standard places.(You'll probably need to be root to do this.)  We recommend first saying	make -n installto see where configure thought the files should go.  You may need to editthe Makefile, particularly if your system's conventions for man pagefilenames don't match what configure expects.If you want to install the IJG library itself, for use in compiling otherprograms besides ours, then you need to put the four include files	jpeglib.h jerror.h jconfig.h jmorecfg.hinto your include-file directory, and put the library file libjpeg.a(extension may vary depending on system) wherever library files go.If you generated a Makefile with "configure", it will do what it thinksis the right thing if you say	make install-libOPTIONAL STUFF==============Progress monitor:If you like, you can #define PROGRESS_REPORT (in jconfig.h) to enable displayof percent-done progress reports.  The routine provided in cdjpeg.c merelyprints percentages to stderr, but you can customize it to do somethingfancier.Utah RLE file format support:We distribute the software with support for RLE image files (Utah RasterToolkit format) disabled, because the RLE support won't compile without theUtah library.  If you have URT version 3.1 or later, you can enable RLEsupport as follows:	1.  #define RLE_SUPPORTED in jconfig.h.	2.  Add a -I option to CFLAGS in the Makefile for the directory	    containing the URT .h files (typically the "include"	    subdirectory of the URT distribution).	3.  Add -L... -lrle to LDLIBS in the Makefile, where ... specifies	    the directory containing the URT "librle.a" file (typically the	    "lib" subdirectory of the URT distribution).Support for 12-bit-deep pixel data:The JPEG standard allows either 8-bit or 12-bit data precision.  (For color,this means 8 or 12 bits per channel, of course.)  If you need to work withdeeper than 8-bit data, you can compile the IJG code for 12-bit operation.To do so:  1. In jmorecfg.h, define BITS_IN_JSAMPLE as 12 rather than 8.  2. In jconfig.h, undefine BMP_SUPPORTED, RLE_SUPPORTED, and TARGA_SUPPORTED,     because the code for those formats doesn't handle 12-bit data and won't     even compile.  (The PPM code does work, as explained below.  The GIF     code works too; it scales 8-bit GIF data to and from 12-bit depth     automatically.)  3. Compile.  Don't expect "make test" to pass, since the supplied test     files are for 8-bit data.Currently, 12-bit support does not work on 16-bit-int machines.Note that a 12-bit version will not read 8-bit JPEG files, nor vice versa;so you'll want to keep around a regular 8-bit compilation as well.(Run-time selection of data depth, to allow a single copy that does both,is possible but would probably slow things down considerably; it's very lowon our to-do list.)The PPM reader (rdppm.c) can read 12-bit data from either text-format orbinary-format PPM and PGM files.  Binary-format PPM/PGM files which have amaxval greater than 255 are assumed to use 2 bytes per sample, LSB first(little-endian order).  As of early 1995, 2-byte binary format is notofficially supported by the PBMPLUS library, but it is expected that afuture release of PBMPLUS will support it.  Note that the PPM reader willread files of any maxval regardless of the BITS_IN_JSAMPLE setting; incomingdata is automatically rescaled to either maxval=255 or maxval=4095 asappropriate for the cjpeg bit depth.The PPM writer (wrppm.c) will normally write 2-byte binary PPM or PGMformat, maxval 4095, when compiled with BITS_IN_JSAMPLE=12.  Since thisformat is not yet widely supported, you can disable it by compiling wrppm.cwith PPM_NORAWWORD defined; then the data is scaled down to 8 bits to make astandard 1-byte/sample PPM or PGM file.  (Yes, this means still another copyof djpeg to keep around.  But hopefully you won't need it for very long.Poskanzer's supposed to get that new PBMPLUS release out Real Soon Now.)Of course, if you are working with 12-bit data, you probably have it storedin some other, nonstandard format.  In that case you'll probably want towrite your own I/O modules to read and write your format.Note that a 12-bit version of cjpeg always runs in "-optimize" mode, inorder to generate valid Huffman tables.  This is necessary because ourdefault Huffman tables only cover 8-bit data.Removing code:If you need to make a smaller version of the JPEG software, some optionalfunctions can be removed at compile time.  See the xxx_SUPPORTED #defines injconfig.h and jmorecfg.h.  If at all possible, we recommend that you leave indecoder support for all valid JPEG files, to ensure that you can read anyone'soutput.  Taking out support for image file formats that you don't use is themost painless way to make the programs smaller.  Another possibility is toremove some of the DCT methods: in particular, the "IFAST" method may not beenough faster than the others to be worth keeping on your machine.  (If youdo remove ISLOW or IFAST, be sure to redefine JDCT_DEFAULT or JDCT_FASTESTto a supported method, by adding a #define in jconfig.h.)OPTIMIZATION============Unless you own a Cray, you'll probably be interested in making the JPEGsoftware go as fast as possible.  This section covers some machine-dependentoptimizations you may want to try.  We suggest that before trying any ofthis, you first get the basic installation to pass the self-test step.Repeat the self-test after any optimization to make sure that you haven'tbroken anything.The integer DCT routines perform a lot of multiplications.  Thesemultiplications must yield 32-bit results, but none of their input valuesare more than 16 bits wide.  On many machines, notably the 680x0 and 80x86CPUs, a 16x16=>32 bit multiply instruction is faster than a full 32x32=>32bit multiply.  Unfortunately there is no portable way to specify such amultiplication in C, but some compilers can generate one when you use theright combination of casts.  See the MULTIPLYxxx macro definitions injdct.h.  If your compiler makes "int" be 32 bits and "short" be 16 bits,defining SHORTxSHORT_32 is fairly likely to work.  When experimenting withalternate definitions, be sure to test not only whether the code still works(use the self-test), but also whether it is actually faster --- on somecompilers, alternate definitions may compute the right answer, yet be slowerthan the default.  Timing cjpeg on a large PGM (grayscale) input file is thebest way to check this, as the DCT will be the largest fraction of the runtimein that mode.  (Note: some of the distributed compiler-specific jconfig filesalready contain #define switches to select appropriate MULTIPLYxxxdefinitions.)If your machine has sufficiently fast floating point hardware, you may findthat the float DCT method is faster than the integer DCT methods, evenafter tweaking the integer multiply macros.  In that case you may want tomake the float DCT be the default method.  (The only objection to this isthat float DCT results may vary slightly across machines.)  To do that, add"#define JDCT_DEFAULT JDCT_FLOAT" to jconfig.h.  Even if you don't changethe default, you should redefine JDCT_FASTEST, which is the method selectedby djpeg's -fast switch.  Don't forget to update the documentation files(usage.doc and/or cjpeg.1, djpeg.1) to agree with what you've done.If access to "short" arrays is slow on your machine, it may be a win todefine type JCOEF as int rather than short.  This will cost a good deal ofmemory though, particularly in some multi-pass modes, so don't do it unlessyou have memory to burn and short is REALLY slow.If your compiler can compile function calls in-line, make sure the INLINEmacro in jmorecfg.h is defined as the keyword that marks a function