TIFF and LibTiff Mail List Archive


2002.02.03 05:00 "tiff (libtiff)", by Harring Figueiredo
2002.02.03 21:42 "Re: tiff (libtiff)", by Peter Montgomery
2002.02.05 12:33 "Re: tiff (libtiff)", by Jon Saxton
2002.02.05 14:20 "Re: tiff (libtiff)", by Bjorn Brox
2002.02.05 14:34 "RE: tiff (libtiff)", by Mark A. James
2002.02.05 14:55 "Re: tiff (libtiff)", by Harring Figueiredo

2002.02.05 12:33 "Re: tiff (libtiff)", by Jon Saxton

I would like to know how I can manipulate a TIFF image that is already in memory ( I am receiving the image through the network ).

From what I can see in Libtiff, we can only get a handle to a Tiff by opening a file.

Just curious, are you receiving the file directly over a socket? My confusion stems from the fact that if you have a harddrive on a network and the drive is mapped to the local machine, then the library works like it always does. A network drive behaves no different from a local drive since the OS hides the magic ju-ju needed and presents a normal file handle.

Of course, if you are directly hooking up to a machine via a socket and squirting bits down the pipe, then that's a different story. The simplest solution in that case is to simply write the incoming data to disk as a temporary file and then handle it as usual. The drawback is that you have the added overhead of reading the image twice. This could be substantial depending on the image size.

I'm not sure of the best way to directly handle an image in memory, but perhaps letting the list know what platform you're working on may be of benefit to finding a solution.

Oh boy, I shall follow this discussion with interest.

In 1997 when I first started manipulating (small) TIFF files a principal requirement was dealing with images in memory and I couldn't see how to do that with libtiff which seemed to do everything with disk files. In UNIX environments that would be tolerable through memory-mapping but I was working in a networked PC environment. Now perhaps in my naivety I didn't understand libtiff well enough but I chose to write my own TIFF handlers (originally in C, then later in C++) independent of libtiff with the exception of the CCITT G3/G4 codecs which I carefully teased out of the file-oriented libtiff code.

My implementation was/is not as broad in scope as libtiff; it was geared towards the specific image types that my applications produced and consumed but it did allow me to do all the manipulations that I needed then and since. These include the cropping of CCITT G4 images, rotations, conversion of ABIC to G4/JPEG and downsampling: all operations on IFD objects.

The point is that this entire effort was driven by the same motivation as that expressed by Harring. The downside was being cut off from libtiff development and communal expertise, and being unable to contribute to the community with real code. For example, I routinely deal with TIFF files around 300 megabytes in size containing up to 14,000 images. I have code to access random IFDs in constant time and it would be nice to contribute that to libtiff because I have seen many complaints about the unwieldy nature of large TIFF files.

If it turns out that my original assessment of libtiff was wrong then it is probably too late for me to turn back now but I'm not so proud that I mind discovering my error. I've been known to make mistakes :-)

Anyway, in Harring's case I don't think he can be dealing with the TIFF input directly from a socket. TIFF seems to demand a seekable input stream and unless there is something I don't know about sockets it would be difficult to implement a TIFF reader using one as a source. TIFF output to a non-seekable stream *is* fairly straightforward. In C++ terms you can say

binary_stream << tiff;

but not

binary_stream >> tiff;

Jon Saxton <> OS/2 software developer
U.S. agent for Triton Technologies International Ltd