1998.05.06 13:46 "Re: RLE problems", by Bill Davis
> From email@example.com Wed May 6 06:14:16 1998
> >This could possibly be the Kofax problem I recently discovered, where the
> >image has been compressed incorrectly. Software that does lazy (technically
> >incorrect) decompression will decompress them ok, but libtiff does it
> >correctly, so won't.
> Hm-m, I beleive library should read anything could be read,
> and there are thousands of such "wrong" pictures...
> >Send me one of the images that doesn't work and I'll have a look.
> >If it is that I can tell you how to modify libtiff to handle it.
> Please let others know - I'm also interested.
> It is up to Sam include it or not into the library but my
> personal vote is to support it.
It may not be that simple. I don't use the RLE coding, but what I have read on this list indicates that changing the software to read the incorrect files will then prevent it from reading correct files.
I think it is a bad idea to not be able to read correct files just so incorrect ones can be read. But reading both with a selection seems useful. Ideally, everyone would stop buying TIFF writers that do not write standard formats, but that is not likely to happen.
We can use the network protocol philosophy of being conservative in what is written (output should strictly meet the spec) and liberal in what is read (accept anything that can be understood even if it is violating the standard). If a function is added to set the mode to RLE_CORRECT or RLE_WRONG (or RLE_BRAIN_DEAD or whatever), then a program could try to read a TIFF file correctly, and when that fails, could then close the file, open it again, set the brain dead mode, and read it that way. The calling program can then decide whether to tell the user that the file format is incorrect. A warning to the user is helpful in case the image is scrambled in other ways. If it doesn't look right, then the user knows why.