2014.06.17 13:25 "Re: [Tiff] In-memory tiffs", by Bob Friesenhahn
On Tue, 17 Jun 2014, "Benedikt Führer" wrote:
I have to questions regarding in-memory tiffs:
- I'm using the helper functions TIFFStreamOpen to try to write multi-directory tiffs into an ostringstream in binary mode. It works perfectly fine for the first directory but as soon as I call TIFFWriteDirectory the 2nd time, it will fail with the error message "Couldn't fetch directory count". What am I doing wrong here? I suspected that the library tries to read
It seems likely that the stream is failing to seek correctly. See _tiffisSeekProc() in libtiff/tif_stream.cxx. It may be that your ostringstream does not support necessary behavior or it may be that the libtiff C++ wrapper has bugs.
What version of libtiff are you using?
With libtiff 4.X there could be an interfacing weakness if C++'s I/O only supports signed 32-bit offsets but libtiff 4.X supports unsigned 64-bit offsets.
As far as I am aware, there is not currently a test case for the C++ wrapper so it could be broken and we would not know about it. It would be good if someone would contribute a C++-based test case for the libtiff 'test' subdirectory.
- Because of this problem I tried to debug the tiff source from within my VStudio project. I'm linking libtiff statically, so it's added in the linker input field and the include directory is known to the compiler. However it won't allow me to step into the source files even if I enter the libtiff directory as a directory to look for debug sources (and I'm sure the sources
These problems are likely due to inconsistent options between building libtiff and your project. Visual Studio projects and 'nmake' work fundamentally differently since 'nmake' does not inherently support multiple builds ('Debug', 'Release') at once.
The manifest issues are beyond me. Either study Microsoft documentation for at least a day in order to understand how to use manifests or take the easier way out by assuring that all DLLs are in the same directory as the using program.
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/