
This directory contains the TIFF conversion routines.

TIFF Software "Release" 2.2 is a public domain package and can be obtained from:

    ucbvax.berkeley.edu         pub/tiff/tiff.tar.Z
        (128.132.130.12)
    uunet.uu.net                graphics/tiff.tar.Z
        (192.48.96.2)

Some files were changed to support Khoros and to support the Khoros
Imake system. File that have changed are:

tiffcompat.h
tif_compress.c

To support the different ifdefs for machine dependent code, the files
tiff_site.h and site_comp.h were added. These files were necessary because
the Khoros generated makefile will not know about these special compile
defines

--------------------------------------------------------------------------------
The following is the README supplied with the TIFF Software "Release" 2.2.:




Tue May 22 11:05:45 PDT 1990

TIFF Software "Release" 2.2
---------------------------
Chages in libtiff:

    o compat.h was renamed tiffcompat.h to avoid name clashes
    o the datatype enum constants were renamed to avoid name
      clashes (particularly BYTE w/ X11's BYTE)
    o apollo "support" was added (a define in machdep.h)
    o NeXT "support" was added (2 Makefiles and some function prototype stuff)
    o the handling of directory tags during writing was reworked;
      it is now possible to alter the value of any tag that does
      not affect compression at any time (previously everything
      was frozen once writing started)
    o a new "options" field was added to the TIFF structure; it is
      intended for compression-algorithm-specific options
    o support for Class F (FAX) images was added; by the Group 3
      fax encoding algorithm supports Class F format; this can be
      changed by setting an option bit or through the TIFFModeCCITTFax3
      routine -- see fax2tiff.c for example use
    o the WhitePoint, Predictor, and PrimaryChromaticities tags
      are now recognized and read in correctly; the Predictor
      tag can be set from the command line when using tiffcp
    o a bug in handling compact ASCII tag values was fixed
    o a short StripByteCounts tag is now accepted (previously only
      accepted long)
    o the dircount item at the front of a directory is now treated
      as unsigned
    o the directory reading code now recovers properly after encountering
      a bogus tag (it used to generate spurious error messages before
      resynchronizing)
    o some confusion about who "owned" response curve and colormap
      data has been cleared up -- all parameters are now *copied*
      into the library (i.e. passing a pointer in and then changing
      the data area that is pointed to no longer works); references
      to the library's copies are returned in calls to TIFFGetField
    o writing multiple directories was broken -- it now works (look
      at fax2tiff for an example of use)
    o the handling of the PageNumber tag has been corrected
    o a byte swapping bug in TIFFSetDirectory was fixed
    o Group 3 decoding no longer inverts the image data
    o tif_fax3.c has support for Class F images (the default); decoding
      should work (modulo a warning message) on non-Class F images;
      encoding works only one way or the other (i.e. as Class F or
      not as Class F)
    o LZW encoding has been signficantly changed:
      - bit codes were being written (and read) in lsb-msb order
	instead of (the required) msb-lsb order; this has been fixed
      - an incompatibility w/ the algorithm used by Aldus has
	been resolved; the LZW code now writes Aldus-compatible
	images and reads both Aldus and bit-reversed (incompatible)
	images (as generated by previous versions of this library);
	old style files are handled w/ a warning message
      In addition, the Predictor tag (for horizontal differencing) is
      now recognized and implemented for 8-bit and 16-bit data.
      Finally, a bug where a clear code was NOT being issued when
      the encoding tables filled up has been fixed -- this resulted
      in (possibly) degraded compression; but otherwise was benign.
    o the null encoding/decoding algorithm now swabs 32-bit data values
      (it used to only handle 16-bit data); this action is documented in
      the manual pages
    o prototype handling in tif_picio.c and tif_dir.c has been improved
      (hopefully); the library now compiles under a variety of compilers
      with and without function prototype checking
    o TIFFPrintDirectory has been updated to handle the new tags and
      changed so that all strings are now printed enclosed in quote
      marks ("...")
    o TIFFReadEncodedStrip and TIFFReadRawStrip have been changed
      so that a size parameter of -1 will return the entire strip.
    o the C++ definitions have been changed to indicate certain
      parameters are const (important for esoteric reasons)
    o a "cleanup-on-close" method has been added to the compression
      algorithm support; the routine is called just after all data
      has been flushed, but before writing out an image's directory
    o a TIFF_NOBITREV flag has been added for use by compression
      algorithms that want to handle bit reversal themselves; it
      should be set in an algorithm's "init" method

Changes in the tools:

    o fax2tiff has been changed to generate Class F TIFF images and
      to combine multiple fax files into a single TIFF file (useful
      for combining multiple pages of a document); old-style classic
      format images can still be had with an option
    o the test program lzw.c has been purged
    o a new (bogus) little program has been added: lzwcodes.c
      prints a trace of the LZW decoding algorithm at work (useful
      was debugging a broken LZW implementations)
    o miscellaneous prototype errors have been fixed
    o ras2tiff.c now gets BitsPerSample right
    o sgigt.c now uses getopt to parse arguments -- to specify an alternate
      directory a -d flag must now be used (consult the manual page);
      a problem with gray scale images that were <8 bits deep was fixed
    o tiffcp now has a -predictor flag for specifying the value of the
      Predictor tag (set it to 2 if you want horizontal differencing
      when encoding with LZW)
    o tiffdump.c has had lots of bugs fixed and now, also, dumps
      all directories in a file

Contributed Software:

    o Patrick Naughton contributed new versions of the tools in contrib.ras
    o Jim Salem contributed fixes to contrib.xtiff
    o Dan Sears contributed a new X-based viewer and several programs
      for generating test case images (see contrib.dbs)

Additions and other stuff:

There is a new document, doc/Class.txt, that describes the Class F
(FAX) spec.

The manual pages have been reworked.  In particular, the library is
now documented with a fairly extensive set of pages.

The issue of how to handle Alpha data has been clarified.  If you use
the Matteing tag, you are expected to save data that is pre-multipled
by Alpha.  If this means nothing to you, forget it.  Otherwise, check
out Porter & Duff's paper in the '84 SIGGRAPH proceedings: "Compositing
Digital Images".

At present I know of only one outstanding bug in the library.  Working
with multi-channel images whose PlanarConfiguration is 2 (separate)
appears to have some problem(s).  In particular, tiffcp used to convert
a contiguous image to separate channels with code of the form:

    for each row in the input file
	for each sample
	    extract data from the current row
	    write data for sample

but this is currently busted, so instead it does:

    for each sample
	for each row in the input file
	    extract data from the current row
	    write data for sample

(i.e. it makes multiple passes over the input file). 
I (currently) don't have time to fix this.

	Sam

Fri Dec 29 13:38:47 PST 1989

TIFF Software "Release" 2.1
---------------------------
This is the "3rd" release of stuff.  The major changes from 2.0
are described below.  For a thorough description of the contents
of the software check out the comments under the 2.0 release.

    Libtiff:
    -------
    o UNIX-dependencies have been isolated to ease porting
    o forward function declarations are now available in the
      sources (i.e. within the library); this eases porting
      for fascist C compilers; define USE_PROTOTYPES:
	1 means include forward declarations w/ parameters
	0 means include forward declarations w/o parameters
    o variable argument list handling is now controlled by
      a USE_VARARGS define:
	1 means use <varargs.h>
	0 means use <stdarg.h> (need ANSI-C declarations for this)
    o the library is known to work under HP-UX
    o filenames have been shortened to help people stuck with
      braindamaged filesystems
    o tiffio.h now has prototype declarations for C++ (both 1.2
      and 2.0 versions) and ANSI C 
    o new support for CCITT Group 3 Fax compression (Compression=3);
      both encoding and decoding, but not 2-d encoding
    o support for the FillOrder tag (mainly for Group 3 Fax)
    o dumpmode will swap short data if the header indicates it's needed
      (doesn't swap ints/longs however) -- this was for MS-DOS
    o meager support for MS-DOS (I don't know all the details, so just
      try it and see what happens)
    o some cleanups & changes to TIFFPrintDirectory
    o support for reading & writing both raw and encoded strips of data
      (this is mostly untested and fairly limited, so beware)
    o bug fixes:
      - directory handling:
	SubFileType was SHORT, now LONG
	LONG ImageWidth & ImageHeight now accepted
	FillOrder reinstated
	diagnostic messages about bad tags now display the right name
	 (an off by one error)
	PageNumber properly supported as two SHORT values
      - i/o is properly reinitialized for each directory after first
      - NeXT decoding is fixed
      - writing a dynamically extended image w/ multiple strips now works
	(only worked before with one strip)

    incompatible changes to libtiff:
    o the TIFFGetField parameter type for TIFFTAG_SUBFILETYPE is now
      long (was short)
    o TIFFGetField and TIFFSetField now expect two short  parameters
      for TIFFTAG_PAGENUMBER

    Tools:
    -----
    o sgigt:
      - clamps both width AND height against screen dimensions to avoid
	problems with the window manager and lrectwrite
      - incorrect range calculations in handling "mapped" images were fixed
      - images w/ widths that aren't a multiple of 8 are handled correctly
      - colormaps are now assumed to be 16-bit (they're immediately
	converted to 8-bit values right now -- this will change)
    o several programs now use getopt to parse arguments (yech!)
    o tiffdump now displays unsigned numbers as unsigned (e.g. g/%d/s//%u/g)
    o a bug in tiffmedian when writing dithered images was fixed; it
      also now generates 16-bit colormaps

    new tools:
    o fax2tiff converts a Group 3 fax file to a TIFF fax file
    o pal2rgb converts a Palette color image to an RGB image by
      applying the colormap
    o tiffdither dithers a b&w image into a bilevel image (suitable for
      use in creating fax files)

    new images:
    o g3test.g3 (a raw Group 3 encoded fax file)
    o g3test.tif (TIFF equivalent of g3test.g3, as created by fax2tiff)

    Contributed stuff:
    -----------------
    Chip Chapin's X-based TIFF viewer and two programs by Patrick Naughton
    for converting between Sun rasterfile format and TIFF (these require
    libpixrect.a, as opposed to the one in tools that doesn't).  The
    X viewer does not yet understand 16-bit colormaps (I'm not an X person,
    sorry)

    Documentation:
    -------------
    A copy of the 5.0 spec is now included.  This document was obtained
    from Bill Johnston of LBL who retrieved it from simtel20.  Beware
    that the document has been modified slightly from the original version
    to enhance printability.  We've tried to be very careful in making
    any changes, but there's always the possibility of mistakes being
    introduced.

    Thanks to...
    ------------
    Chip Chapin, Tony Apodaca and Patty Lopez for bug fixes.  The
    fax2tiff program is derived from work by Paul Haeberli and Jef
    Poskanzer.  Rick Richardson helped me out with testing the fax stuff.

    Known problems:
    --------------
    X TIFF viewer does not understand 16-bit colormaps (still thinks that
    they're 8-bit)

Tue Apr 25 20:53:39 PDT 1989

TIFF Software "Release" 2.0
---------------------------
This is the "2nd" release of my public domain TIFF support software.
Included is a library, libtiff, for reading and writing TIFF files.
The library, along with associated tool programs, should handle most
of your needs for reading and writing files that follow the 5.0 TIFF spec
for Classes B, G, P, and R.  The library does not entirely handle Class
B images because it does not support the CCITT compression schemes
(Compression = 1, 2), only the PackBits compression scheme (Compression
= 32773).

    o core requirements
	both "MM" and "II" byte orders are handled
	multiple subfiles can be read and written
	editing is NOT supported in that related subfiles (e.g.
	  a reduced resolution version of an image) are not automatically
	  updated
	
	Tags handled: NewSubfileType, ImageWidth, ImageLength, Rowsperstrip,
		      StripOffsets, StripByteCounts, XResolution, YResolution,
		      ResolutionUnit.
    o Class G for grayscale images
	SamplesPerPixel = 1
	BitsPerSample = 4, 8
	Compression = 1 (none) 5 (LZW)
	PhotometricInterpretation = 0 (Min-is-White), 1 (Min-is-Black)
    o Class P for palette color images
	SamplesPerPixel = 1
	BitsPerSample = 1-8
	Compression = 1 (none) 5 (LZW)
	PhotometricInterpretation = 3 (Palette RGB)
	ColorMap
    o Class R for RGB full color images
	SamplesPerPixel = 3
	BitsPerSample = <8,8,8>
	PlanarConfiguration = 1, 2
	Compression = 1 (none) 5 (LZW)
	PhotometricInterpretation = 2 (RGB)

In addition, the library supports some optional compression algorithms
that are, in some cases, of dubious value.
	Compression = 32766	NeXT 2-bit encoding
	Compression = 32809	ThunderScan 4-bit encoding
(unregistered compression schemes whose use is not recommended)
	Compresison = 32900	Pixar picio encoding
	Compression = 32901	SGI run-length encoding (like PackBits)

LIBTIFF
-------
Libtiff is the software library that you can use to read and write TIFF
files (most all the tools use it to do their work).  The library
provides a simple scanline-based interface.  For example, to read the
contents of a file, the following might be used:

	#include "tiffio.h"

	TIFF *tif;
	unsigned short imagelength;
	char *buf;
	int row;

	tif = TIFFOpen("myfile.tif", "r");
	TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &imagelength);
	buf = malloc(TIFFScanlineSize(tif));
	for (row = 0; row < imagelength; row++)
		TIFFReadScanline(tif, buf, row);

(this example assumes samples are packed contiguously.)  Similarly, to
write a file, something like the following can be used:

	tif = TIFFOpen("myfile.tif", "w");
	TIFFSetField(tif, TIFFTAG_IMAGEWIDTH, imagewidth);
	TIFFSetField(tif, TIFFTAG_COMPRESSION, COMPRESSION_LZW);
	... <set other required tags>
	row = 0;
	while (...more scanlines to write...)
		TIFFWriteScanline(tif, buf, row);
	TIFFClose(tif);
 
(once again, we assume samples are packed contiguously.)

Unlike the stdio library, libtiff only supports reading OR writing of a
file.   There is also an append mode, but this has not really been
tested.

TOOLS
-----
There are two device-dependent programs:

o tiffgt is used to display the contents of a TIFF file on a
  framebuffer.  The version included in this release was written
  for the Silicon Graphics Graphics Library (GL), although it
  should be a simple matter to tailor it for other systems.
o tiffsv is used to save all or part of a framebuffer in a
  TIFF file.  Once again, the version of tiffsv included here
  was written for the GL, but should be tailorable to other devices.

The remaining programs should be device-independent:

o tiffinfo formats information about one or more TIFF files
o tiffdump displays the verbatim contents of the TIFF directory in a
  file (it's very useful for debugging bogus files that you may get from
  someone that claims they support TIFF).
o tiffcp is used to copy and convert TIFF images (e.g. switching from
  Compression=5 to Compression=1).
o tiffcmp can be used to compare the contents of two TIFF files (it does
  not check all the directory information, but does check all the data).
o tiff2bw is a simple program to convert a color image to grayscale.
o ras2tiff is a quick hack that converts Sun rasterfile format images to
  TIFF -- it's less than complete.
o Finally, tiffmedian is a version of Paul Heckbert's median cut program
  that reads an RGB TIFF image, and creates a TIFF palette file as a
  result.  It's useful for converting full-color RGB images to 8-bit
  color for your friends that have cheapo 8-bit framebuffers.

Check out the manual pages for details about the above programs.

BUILDING THE SOFTWARE
---------------------
The software, as distributed, is setup for building the software on an
SGI machine (release 3.1D if you care).  To configure things for your
machine, check for Makefiles in the libtiff and tools directories for
your machine:

    Makefile.sgi	Makefile for a GT, GTX, or Personal Iris
    Makefile.sun	Makefile for a Sun-3 or Sun-4 running SunOS 3.5+
    Makefile.vax	Makefile for a VAX running 4.3BSD
    Makefile.tahoe	Makefile for a TAHOE running 4.3BSD
    Makefile.mips	Makefile for a MIPS running MIPS OS 2.?

If your machine is not represented, you'll have to make up a Makefile
that's right for you.  In libtiff the important things to setup are

    AR=/usr/bin/ar			whatever your library archiver is called
    RANLIB=/usr/bin/ranlib		if you need to ranlib a library
    IPATH=-I. -I/usr/include/bsd	list of directories to search includes
    CONF=....				configuring optional support

Also, the file machdep.h has some defines specify if your machine has
unsigned characters or not (and how to sign extend them to integers).
You only need to get the UCHARS macro defined properly for the library
to work (this file comes from somewhere else, which is why there is a
lot of other stuff present).  (Note that the native byte ordering for
your machine is deduced at runtime -- see tiff_open.c for details.)

To build the library, just
	cd libtiff; make

In the tools directory, you'll want to setup the MACHALL macro,

	MACHALL=ras2tiff tiffgt tiffsv

and add definitions for how to build tiffgt and tiffsv for your machine
(if appropriate).  If you have a Pixar, you may want to play around
with some of these programs as well.

To build the tools library, just
	cd ../tools; make

CHECKING OUT THE SOFTWARE
-------------------------
Assuming you have working versions of tiffgt and tiffsv, you can just
use them to view any of the sample images included in the tools
directory (the list is given below).  Otherwise, you can check out the
operation of the library with tiffcp and tiffcmp; for example,

	tiffcp -lzw cramps.tif x.tif
	tifcmp cramps.tif x.tif

(tifcmp should be silent if the files compare correctly).

CONVERTING TIFF FILES FROM PREVIOUS VERSIONS OF LIBTIFF
-------------------------------------------------------
Previous versions of libtiff created files with some bogus tags in
them.  A quick&dirty program, fixit, is included in the tools directory
to patch, IN-PLACE, these files.  Since fixit works in-place, you may
want to first make a copy of the file before using it.  To patch a
file,

	fixit file.tif

You can use tiffdump to examine the result.

BUGS AND SUCH....
-----------------
This software is free.  The only thing that I ask in return is that you
tell me when you find a problem or fix a bug.  I also gladly accept
software contributions, although I hesitate to include such software in
my regular stuff if I am personally unable to test it.

There is a mailing list associated with the software,
tiff@ucbvax.berkeley.edu, that you can join by sending a message to
tiff-request@ucbvax.berkeley.edu.  You can also reach me directly at
sam@ucbvax.berkeley.edu.

ACKNOWLEDGEMENTS
----------------
The LZW algorithm is derived from the compress program (the proper
attribution is included in the source code).  The Picio algorithm is
from Pixar.  Patrick Naughton at Sun has helped several times in
finding limitations of the library with respect to bogus TIFF files
generated by so called TIFF-compliant programs.

FILE CONTENTS
-------------
The following files may be of particular interest:

libtiff/machdep.h		machine dependent definitions
libtiff/tiff.h			TIFF spec definitions
libtiff/tiffio.h		TIFF library definitions
libtiff/tiff_ccittfax.c		not implemented
libtiff/tiff_ccittrle.c		not implemented
libtiff/tiff_compress.c		list of supported compression algorithms
libtiff/tiff_dir.c		directory handling code
libtiff/tiff_dumpmode.c		"no" compression algorithm
libtiff/tiff_lzw.c		LZW encoding and decoding
libtiff/tiff_next.c		NeXT 2-bit encoding algorithm
libtiff/tiff_packbits.c		Packbits encoding and decoding
libtiff/tiff_picio.c		Pixar picio RLE support
libtiff/tiff_sgi.c		Silicon Graphics RLE support (~Packbits)
libtiff/tiff_thunder.c		Thunderscan decoding (no encoding)

tools/sgigt.c		TIFF picture get for SGI framebuffer (uses GL)
tools/sgisv.c		save image on SGI framebuffer in TIFF file
tools/tiff2bw.c		convert color TIFF file to B&W
tools/tiffcmp.c		compare two TIFF files
tools/tiffcp.c		copy/convert TIFF files (used to change compression)
tools/tiffdump.c	dump TIFF header and directory tags w/o library
tools/tiffinfo.c	print info about TIFF file(s)
tools/tiffmedian.c	median cut RGB -> palette conversion program
tools/ras2tiff.c	convert Sun rasterfile format to TIFF (limited)

The following programs are old and haven't been
tested recently (I no longer have the hardware):

tools/cg8gt.c		TIFF picture get for the Sun cg8 24-bit framebuffer
tools/picio2tiff.c	convert Pixar picio file to TIFF file
tools/pixargt.c		TIFF picture get for Pixar framebuffer

The following programs are less than useful:

tools/tiff2ps.c		convert TIFF to PostScript (untested)
tools/hist.c		picio encoding analysis program
tools/fixit.c		fixup TIFF files created by old libtiff
tools/lzw.c		generate LZW output shown in 5.0 TIFF spec (for testing)

The following images files are included for testing:

	PlanarConfiguration = 1 (packed data)
tools/cramps.tif	800x607 8-bit b&w (packbits) "cramps poster"
tools/jello.tif		256x192 8-bit RGB (lzw palette) Paul Heckbert "jello"
tools/logo.tif		564x90 8-bit RGBA (unencoded) Pixar logo
tools/logo-picio.tif	logo.tif compressed with Picio
tools/quad-lzw.tif	512x384 8-bit RGB (lzw) "quadric surfaces"
tools/text.tif		1512x359 4-bit b&w (thunderscan) am-express credit card
	PlanarConfiguration = 2 (separated samples)
tools/oxford.tif	601x81 8-bit RGB (lzw) screendump off oxford

--------------------------------------------------------------------------------
The following is the README from the actual tiff library:



Tue Apr 17 17:47:27 PDT 1990

compat.h was renamed tiffcompat.h to avoid name clashes (since it's
now included by tiffio.h and so must be public).

If you compile the code with prototypes (USE_PROTOTYPES=1), then
you must have USE_VARARGS=0.

Two new configuration-related defines were added:

CLASSF_SUPPORT	if this is defined in tif_fax3.c, the Class F
		support will be enabled; i.e. the default is not to
		conform to the Class F (FAX) spec
SUBFILE_COMPAT	if this is defined in tif_dir.c, an entry will be
		included in the tag table to support short SubFileType
		tags, as (incorrectly) generated by earlier versions
		of this library

By default, CLASSF_SUPPORT is defined and SUBFILE_COMPAT is not defined.

Thu Dec 28 14:52:03 PST 1989

Comments on portability:

I've tried to isolate as many of the UNIX-dependencies as possible in
two files: compat.h and tif_compat.c.  There are still some problems
with the use of lseek().  Most of this is fairly untried, so don't be
suprised if you find bogus stuff.  I personally don't care to devote
much effort to making the code work (untouched) on lots of non-UNIX
platforms.

Two general portability-related defines are:
    USE_VARARGS		define as 0 or 1 to select between the
			use of varargs.h and stdarg.h; i.e.
			-DUSE_VARARGS=0 means use stdarg.h
    USE_PROTOTYPES	define as 0 or 1 to select function
			declarations with parameter types
Beware that if __STDC__ is defined and the USE_* symbols are
NOT defined, then compat.h defines:
    USE_PROTOTYPES	1
    USE_VARARGS		0

There is also a control over how to use the C preprocessor to paste
lexical tokens together.  Ansi C defines the ## operator.  This is
used if __STDC__ is defined; otherwise the usual trick is done (see
compat.h).

Tue Apr 25 20:42:03 PDT 1989

The TIFF library is designed to hide as much of the details of TIFF as
possible.  In particular, TIFF directories are read in their entirety
into an internal format.  This means that only the tags known by the
library are available to a user and that certain tag data may be
maintained that a user doesn't care about (e.g. color response
curves).

To add support for a new directory tag the following changes will be
needed:

1. Define the tag in tiff.h.
2. Add a field to the directory structure in tiffio.h and define a
   FIELD_* bit.
3. Add an entry in the FieldInfo array defined at the top of tiff_dir.c.
4. Add entries in TIFFSetField() and TIFFGetField1() for the new tag.
5. (optional) If the value associated with the tag is not a scalar value
   (e.g. the array for GrayResponseCurve), then add the appropriate
   code to TIFFReadDirectory() and TIFFWriteDirectory().  You're best
   off finding a similar tag and cribbing code.
6. Add support to TIFFPrintDirectory() in tiff_print.c to print the
   tag's value.

To add support for a compression algorithm:

1. Define the tag value in tiff.h.
2. Edit the file tiff_compress.c to add an entry to the
   CompressionSchemes[] array.
3. Create a file with the compression scheme code, by convention files
   are named tiff_*.c (except perhaps on System V where the tiff_ prefix
   pushes some filenames over 14 chars.
4. Edit the Makefile to include the new source file.

A compression scheme, say foo, can have up to 6 entry points:

TIFFfoo(tif)		/* initialize scheme and setup entry points in tif */
fooPreDecode(tif)	/* called once per strip, after data is read,
			   but before the first row in a strip is decoded */
fooDecode(tif, bp, cc)	/* decode cc bytes of data into the supplied buffer */
fooStripEncode(tif)	/* called once per strip, before the first row in
			   a strip is encoded */
fooEncode(tif, bp, cc)	/* encode cc bytes of user data (bp) */
fooPostEncode(tif)	/* called once per strip, just before data is written */
fooSeek(tif, row)	/* seek forwards row scanlines from the beginning
			   of a strip (row will always be >0 and <rows/strip */
fooCleanup(tif)		/* called when compression scheme is replaced by user */

The library handles most I/O buffering.  There are two data buffers
when decoding data: a raw data buffer that holds all the data in a
strip, and a user-supplied scanline buffer that compression schemes
place decoded data into.  When encoding data the data in the
user-supplied scanline buffer is encoded into the raw data buffer (from
where it's written).  Decoding routines should never have to explicitly
read data -- a full strip's worth of raw data is read and scanlines
never cross strip boundaries.  Encoding routines must be cognizant of
the raw data buffer size and call TIFFFlushData1() when necessary.
Note that any pending data is automatically flushed when a new strip is
started, so there's no need do that in the tif_encodestrip routine (if
one exists).

The variables tif_rawcc, tif_rawdata, and tif_rawcp in a TIFF structure
are associated with the raw data buffer.  tif_rawcc must be non-zero
for the library to automatically flush data.  The variable
tif_scanlinesize is the size a user's scanline buffer should be.  This
should not be used by compression routines, except where it relates to
the compression algorithm.  That is, the cc parameter to the tif_decode
and tif_encode routines should be used in terminating
decompression/compression.  This ensures these routines can be used,
for example, to decode/encode entire strips of data.

In general, if you have a new compression algorithm to add, work from
the code for an existing routine.  In particular, tiff_dumpmode.c has
the trivial code for the "nil" compression scheme, tiff_packbits.c is a
simple byte-oriented scheme that has to watch out for buffer
boundaries, and tiff_lzw.c has the LZW scheme that has the most
complexity -- it tracks the buffer boundary at a bit level.

Of course, using a private compression scheme (or private tags) limits
the portability of your TIFF files.

