2005.01.28 16:24 "Re: [Tiff] issues with TIFFStreamOpen", by Edward Lam

If no one has a test case which can prove that the seek is required, I propose that we scrap the call to TIFFSeekFile() in TIFFClientOpen() regardless. If the seek is really necessary, I think it should be up to the caller of TIFFClientOpen() to do it. ReadOK() shouldn't change the file pointer anyhow, if it does, then it is a bug in the readproc.

It is probably a good idea to get rid off that seek, if it is really unnecessary.

I've logged this issue as a minor bug under #756.

How does anyone expect to treat streams generically? <sigh> We could do

I totally agree with that. ;-(

> Hence, one can not use streams within the API of SDKs. ;-(

Not to mention the fact that in gcc 2.96, we had to do ugly hacks so that we could seek using ostrstream's. :( We've debated here before whether we should just give up on iostreams completely because we've been bitten by poor implementations so many times. We've seen cases where streaming a buffer would cause a memory reallocation every *single* character!

With this fix I get a valid TIFF image with the correct size and color depth, but unfortunately it is all black.

I patched this to

140:    // extend the stream to the expected size
141:    os->seekp(0, ios::end);
142:    num_fill = origin + off - (toff_t)os->tellp();

which resulted in a valid TIFF file with my test image.

Excellent! Sorry about the obvious bug. It explains why you get a black image doesn't it? :) I don't see anything else wrong with the file now, shall we submit your latest version of tif_stream.cxx to bugzilla?

-Edward