- 2010.04.29 23:59 "Re: [Tiff] "flexible" mode in TIFFClientOpen ?", by Toby Thain
- 2010.04.30 00:37 "Re: [Tiff] "flexible" mode in TIFFClientOpen ?", by Bob Friesenhahn
- 2010.04.30 02:48 "[Tiff] Flexible Mode", by Richard Nolde
2010.04.29 23:59 "Re: [Tiff] "flexible" mode in TIFFClientOpen ?", by Toby Thain
On 30-Apr-10, at 9:38 AM, Dmitry Fedorov wrote:
I work with libbioimage a library used to decode end encode several biological image formats and their metadata. Many of these are some variants of TIFF images, usually not exactly well formed but still we have to decode them. I use libtiff 4 b5 for decoding all of these variants supplying some run-time fixes to libtiff decoding behavior by knowing which format variant it is based on existing tags. I do run into some trouble when libtiff decides the image is invalid it would not decode it. It may happen for some silly reasons that would not hinder decoding the image completely. For example: in 1 channel image photometric is set to PALETTE and no palette is present, libtiff will stop right there, though if I simply set photometric to MINISBLACK everything will work.
I could imagine it would be a reasonable proposal to add another option to the modes passed within TIFFClientOpen to force the decoder to be less stringent, say "f" for flexible. Thus I could allow certain flexibility on these decoding issues when I really need to.
I would be more than glad to draft the code change and submit it if it is considered useful.
It is much more than just adding a flag, but involves changing a large number of consistency checks in fairly arbitrary ways. While the "missing palette" issue above is resolved for your image by assuming grey scale, can you defend it as a general heuristic? What other specific checks do your files fail?
Wouldn't it be easy just to maintain your own modified libtiff for your own circumstances?