libtiff

History

Bob Friesenhahn 3adc33842b * Update libtool to version 2.2.8. * libtiff/tif_fax3.c (Fax3SetupState): Avoid under-allocation of buffer due to integer overflow in TIFFroundup() and several other potential overflows. In conjunction with the fix to TIFFhowmany(), fixes CVE-2010-1411. * libtiff/tiffiop.h (TIFFhowmany): Return zero if parameters would result in an integer overflow. This causes TIFFroundup() to also return zero if there would be an integer overflow.		2010-06-08 23:32:22 +00:00
..
.cvsignore	New	2005-11-21 00:55:38 +00:00
Makefile.am	libtiff 3.8.2 released.	2006-03-23 14:54:00 +00:00
Makefile.in	* Update libtool to version 2.2.8.	2010-06-08 23:32:22 +00:00
Makefile.w95
README.tiff2dib
README.Tiffile
tiff2dib.c	* contrib: Add an emacs formatting mode footer to all source files	2010-06-08 18:55:15 +00:00
Tiffile.cpp	* contrib: Add an emacs formatting mode footer to all source files	2010-06-08 18:55:15 +00:00

README.Tiffile

Frank,

I attached a file that uses RGBA interface (tif_getimage.c) to read a tiff
file and convert to a DIB.  It's advantage is that it is easy to read *any*
tiff file suported by libtiff and easily convert it to a DIB.  The disadvantage
is that bilevel (B&W) bitmaps (and all other non-rgba images) are also 
converted to RGBA, thus taking up 32x as much memory as needed (4 bytes per 
pixel, rather than 1 bit).  I read tiff files, but don't need to
write them.  And my files are typically small, so the overhead is mostly
inconsequential.  But for bilevel images, I overrode the get() and put()
routines of the RGBA interface to just copy the data from the input raster
to the output raster, rather than expanding out to full 32 bit format.  It
would be nice if there were a simple way to handle all palletized images,
but that would take more custom routines, and it's not that important to me.

Usage:

    m_pDIB = (PBITMAPINFOHEADER)::ReadTIFF(pathName);
    if (m_pDIB != 0) {
       m_format = IMAGETYPE_TIF;
    }

This is intended as Win32, but the modifications for new get() and put()
routines may be independent of platform.

Thanks for your work supporting the forum and the library!

Regards,

Mark James
mark@james.net