AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2001.02.06 12:44 "redefining put method for TIFFRGBAImageGet()", by Elan Ruskin
2001.02.06 16:59 "Re: redefining put method for TIFFRGBAImageGet()", by Chris 'Xenon' Hanson

2001.02.06 16:59 "Re: redefining put method for TIFFRGBAImageGet()", by Chris 'Xenon' Hanson

It says in the libtiff documentation that there's some way to override the put method used by TIFFRGBAImageGet with a function better suited to my local raster representation, but it's not particularly clear from either the documentation or the source how I should write this new put method. Could someone please shed light on the issue?

Because I'm doing DSP on these images, I need to turn the TIFF into an array of floats, one per pixel (grayscale), instead of the packed ABGRABGRABGR format that the library provides. I furthermore need the raster origin to be at the top left, in raster[0][0], rather than at the bottom left (which results in my images being vertically flipped). From the structure definition in tiffio.h it looks like I need to replace the TIFFRGBAImage->put with a function of type (void *)(TIFFRGBAImage *) but I don't know what needs to be in the put function. It takes a TIFFRGBAImage, but how does it work out from that where to put the raster data? Where does it get its input? What sort of input does it get?

At the moment my program works by using the default ...Get() to read in the default raster format, then I unpack and repack that to my specifications, but this is inefficient and I need good speed on this particular operation. Could anyone supply me with an example put method?

I've been lurking for a while, and I too have the same situation.

Our app is designed for multi-band imagery (more than 3 channels of imagery, sometimes more than 8 bit integer data per channel). We store each channel separately, not in the packed/interleaved RGBA style TIFFlib prefers. I too am using a Get followed by a deinterleave process, but this requires that I temporarily need double the amount of memory available (one for the full image buffer for TIFFlib to write into, one for my software's internal representation) while I convert between the two.

I looked into meddling with the put methods a while ago, but they are cryptic (to say the least) and the only example I could find (the SGI displayer) uses the original put methods, but intercepts them to display data as it is read.

It appears one cannot use the default put methods unless one has allocated the requisite block of memory per TIFFlib's recommendation. However, writing ones own fully custom put methods looks obscure and daunting. It also appears one would need to write a whole bunch of new put methods, one for each type of file data organization TIFFlib supports -- very likely to be error-prone and difficult to test/validate.

If anyone else has done this successfully, I'd love to know the details. I was forestalling addressing this, but I know my users will want to use large images, and my current memory-hungry method will not be favorable.

Other than this difficulty, I've found the TIFFlib to be amazingly friendly and easy to use. I think I've just pushed it beyond its intended limits.

P.S. Elan, have you addressed 16-bit per channel TIFFs yet? I need to do that myself, and have not yet tried it. If you have tips about that, I'd love to see them too. I am going to have to on-the-fly up-promote them to floats myself, so we're facing similar problems.

Chris - Xenon

  Chris Hanson | Xenon@3DNature.com | I've got friends in low latitudes!
      Learn about the new WCS Version 5!     http://www.3DNature.com
  "There is no Truth. There is only Perception. To Perceive is to Exist." - Xen