Contents of Submission ---------------------- This submission to the MathSource archive contains the following files: README.txt - this file ReadTIFFpackage.m - plain ascii text file version of my package. notebook_ReadTIFFpackage.ma - notebook version of my package. test_ReadTIFFpackage.ma - Example notebook describing use of the package. Abstract -------- This package defines a function, readTIFFg, that can read a grayscale image stored in the TIFF file format and return a 2-D matrix (i.e., a List of Lists) representing the image's bitmap. A MathLink routine is used to read the binary files so a large image (>100K) can be read-in in under 10 seconds. The readTIFFg function can currently (v1.1) handle only bilevel (TIFF Class B) and grayscale (TIFF Class G) images that are saved to the file WITHOUT INTERNAL DATA COMPRESSION. With this exception, readTIFFg satisfies the requirements of a format compliant 'baseline' TIFF Class G file reader, and has been tested on files created by the many applications. readTIFFg may also, in many cases, successfully read files that violate the TIFF standard in some way. Several variables containing useful information about the image (e.g., its height and width) and the file's structure are set when the file is read-in, and these may be examined by setting the functions options. readTIFFpackage` needs access to the FastBinaryFiles` package written by Todd Gayley at Wolfram Research (tgayley@wri.com). Documentation at the start of the readTIFFpackage.m notebook describes how to obtain FastBinaryFiles` and install it for use by the readTIFFpackage`. After writing readTIFFpackage I found out that Jeffrey Adams (jeff@tiag.com) is about to release to the MathSource a more complete TIFF file reader and writer. This should be able to handle 1, 2, 4, 8, 24 and 32 bit GrayLevel, RGBColor and CMYKColor TIFF files. His package is called Graphics`Tiff` and the functions are ReadTIFF and WriteTIFF. I've decided to go ahead and release my package, since his uses MathLink with NEXTSTEP specific code, so until his code is ported to other platforms my readTIFFpackage` may prove useful to some users. To avoid any confusion between his ReadTIFF function and mine (which was called readTIFF) I've changed the name of my function to readTIFFg. This also highlights the fact that it is only designed to work on grayscale (Class G) images. Implemantation Notes -------------------- The 'rules' state that packages submitted to the MathSource archive must be plain ascii text files. To me, this seems rather silly. Why can't the packages be notebooks themselves? Whenever I develop a package for my own use it is actually a notebook in which all the appropriate code is contained in cells with the Initialization attribute. The advantage of having a package in notebook form is that documentation may be included in a more hyper-text-like way, examples (including graphics) may be included, and the actual programming may be structured by using the cell/sub-cell concept. In order to comply with the MathSource rules my submission does contain a plain ascii text version of my package. This is the file "ReadTIFFpackage.m". It was created by using the Save As Special... menu option with the File Format set to Package (TEXT). This plain text version does contain all the documentation from the original notebook version, but it is not formatted and is harder to read. The original notebook form of the package is also included with this submission. It is the file "notebook_ReadTIFFpackage.ma". My advise is to ignore/delete the plain text "ReadTIFFpackage.m" file, and rename "notebook_ReadTIFFpackage.ma" to be "ReadTIFFpackage.m".