LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2005
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2005.01.28 16:24 "Re: issues with TIFFStreamOpen", by Edward Lam
Michael Rinne wrote: > > 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