AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2003.09.01 11:49 "[Tiff] Reading and writing to memory.", by Väinö Järvelä
2003.09.01 19:17 "[Tiff] Reading and writing to memory.", by Pushkar Pradhan
2003.09.02 05:43 "[Tiff] Reading and writing to memory.", by Väinö Järvelä
2003.09.01 20:02 "[Tiff] Reading and writing to memory.", by Frank Warmerdam
2003.09.02 05:46 "[Tiff] Reading and writing to memory.", by Väinö Järvelä
2003.09.02 10:13 "[Tiff] Reading and writing to memory.", by Väinö Järvelä

2003.09.01 20:02 "[Tiff] Reading and writing to memory.", by Frank Warmerdam

Vaino,

There are indeed fairly detailed semantics required of the IO functions. I don't know that these assumptions are well documented anywhere. You might be best off reviewing existing low level implementations carefully if you want to make your own.

There are already at least two memory based TIFF implementations for libtiff. in contrib/mfs there is one. I also have one I use as part of GDAL, based loosely on mfs.

I am not absolutely certain why you are getting the "dummy: Not a TIFF file, bad magic number" message. It may be that as currently setup even a writable data stream needs to support read, and that you are not allowing the tiff header to be read back by the code.

Is mmap and unmap procs mandatory?

They must be supplied, but a simple "unsupported" implementation is fine.

I can't help but wonder though if your overall approach is appropriate. Why is it that you need to hold your whole image in memory? Why not operate on the image in chunks as Pushkar suggests?

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent