freeswitch/libs/tiff-4.0.2/contrib/pds/README

Date:    Fri, 01 Aug 1997 20:14:52 MDT
To:      Sam Leffler <sam@cthulhu.engr.sgi.com>

From:    "Conrad J. Poelman (WSAT)" <poelmanc@plk.af.mil>
Subject: Potential TIFF library additions

Delivery-Date: Fri, 01 Aug 1997 19:21:06 -0700

Sam,

You probably don't remember me, but I sent in a couple of bug fixes
regarding the TIFF library about a 16 months ago or so...

I just wanted to send you two other additions that I have made to our
local version of the TIFF library in hopes that you will want to
incorporate them into your next major release of the TIFF library.
(These additions are based on TIFF version 3.4beta31, but they sit on
top of the library so they shouldn't be much trouble to incorporate them
into any more recent version.) They are internally documented to a
reasonable extent and we've been successfully using them in our code
here for over a year. If you think they would make good additions to the
TIFF library, I'd be happy to clean them up more, document them more,
and/or integrate them with the latest version of the TIFF library, but I
figured I'd see if you were interested in using them before I went to
all that trouble.

TIFF Image Iterator
-------------------
Your ReadRGBA() routine works well for reading many different formats
(TILED, STIP, compressed or not, etc.) of the most basic types of data
(RGB, 8-bit greyscale, 8-bit colormapped) into an SGI-style data array,
and serves as a good template for users with other needs. I used it as
an exmaple of how to make an iterator which, rather than fill a data
array, calls an arbitrary user-supplied callback function for each
"chunk" of data - that "chunk" might be a strip or a tile, and might
have one sample-per-pixel or two, and might be 8-bit data or 16-bit or
24-bit. The callback function can do whatever it wants with the data -
store it in a big array, convert it to RGBA, or draw it directly to the
screen. I was able to use this iterator to read 16-bit greyscale and 32-
and 64-bit floating point data, which wasn't possible with ReadRGBA().

I have tested this routine with 8- and 16-bit greyscale data as well as
with 32- and 64-bit floating point data. I believe nearly all of our
data is organized in strips, so actually I'd appreciate it if you had
some tiled images that I could test it with.

It should certainly be possible and would be cleanest to reimplement
ReadRGBA() in terms of the image iterator, but I haven't done that.


Private Sub-Directory Read/Write
--------------------------------
TIFF-PL is a Phillips Laboratory extension to the TIFF tags that allows
us to store satellite imaging-specific information in a TIFF format,
such as the satellite's trajectory, the imaging time, etc. In order to
give us the flexibility to modify the tag definitions without getting
approval from the TIFF committee every time, we were given only three
TIFF tags - a PL signature, a PL version number, and PL directory
offset, which lists the position in the file at which to find a private
sub-directory of tags-value pairs. So I wrote two routines:
TIFFWritePrivateDataSubDirectory(), which takes a list of tags and a
"get" function and writes the tag values into the TIFF file, returning
the offset within the file at which it wrote the directory; and
TIFFReadPrivateDataSubDirectory(), which takes an offset, a list of
tags, and a "set" function and reads all the data from the private
directory. The functions themselves are pretty simple. (The files are
huge because I had to basically copy all of the tif_dirread.c and
tif_dirwrite.c files in order to access the various fetching routines
which were all declared static and therefore inaccessible in the TIFF
library.)


I'm including the four source files (tif_imgiter.h, tif_imgiter.c,
tif_pdsdirread.c, tif_pdsdirwrite.c) in case you want to take a look at
them. I can also send you some sample code that uses them if you like.
If you're interested in having them incorporated into the standard TIFF
library, I'd be happy to do that integration and clean up and document
the routines. (For example, I've already realized that instead of
limiting the SEP callback function to three bands (R,G,B) it should take
an array to enable the handling of n-banded multi-spectral data...) If
not, I'll just leave them as they are, since they work fine for us now.

Holler if you have any questions.

-- Conrad
__________________________________________________________________
  Capt Conrad J. Poelman         PL/WSAT   (Phillips Laboratory)
    505-846-4347                   3550 Aberdeen Ave SE 
      (FAX) 505-846-4374             Kirtland AFB, NM 87117-5776