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