Date: Fri, 01 Aug 1997 20:14:52 MDT To: Sam Leffler From: "Conrad J. Poelman (WSAT)" 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