-
2010.02.22 21:16 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Lee Howard
-
2010.02.22 18:29 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Frank Warmerdam
-
2010.02.22 14:54 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Edward Lam
- 2010.02.22 15:13 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Andrew Brooks
- 2010.02.22 16:37 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Edward Lam
- 2010.02.22 19:41 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Lee Howard
-
2010.02.22 14:54 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Edward Lam
-
2010.02.22 18:29 "Re: [Tiff] Libtiff 4.0.0beta5 Released", by Frank Warmerdam
-
2010.03.16 22:34 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Lee Cooper
-
2010.03.16 19:45 "[Tiff] TIFFVStripSize overflow, JPEG decoding", by Lee Cooper
-
2010.03.16 21:08 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Bob Friesenhahn
-
2010.03.17 20:19 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Adam Goode
- 2010.03.17 20:59 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Lee Cooper
- 2010.03.17 21:36 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Tom Lane
-
2010.03.17 20:19 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Adam Goode
- 2010.03.17 20:18 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Adam Goode
-
2010.03.16 21:08 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Bob Friesenhahn
- 2010.03.17 16:42 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Jason Summers
-
2010.03.16 19:45 "[Tiff] TIFFVStripSize overflow, JPEG decoding", by Lee Cooper
2010.03.19 15:52 "Re: [Tiff] TIFFVStripSize overflow, JPEG decoding", by Adam Goode
On 03/17/2010 10:40 PM, Olivier Paquet wrote:
On Wed, Mar 17, 2010 at 8:15 PM, Adam Goode <adam@spicenitz.org> wrote:
I already tried using libtiff 4.0.2 to read the header and encountered the same overflow message.
Interesting, I did get tiffinfo from CVS to read the header. Possibly there was some fix there not in the beta, or possibly it was because I compiled it on a 64-bit machine?
Yes, TIFFVStripSize returns tmsize_t which is pointer sized. So it will be fine on 64-bit systems with libtiff 4.
Hmm, this seems a little odd. I would expect libtiff 4 to not have any machine-specific sizes, but to instead use the same size types on all architectures. It makes reading this kind of file problematic across systems.
Since this NDPI file is really a horrible abuse of TIFF, I'm not too upset that libtiff can't read it. But it would be nice if libtiff could give a tiffdump-like option of just reading headers without interpreting them too much. This is all that is needed for this kind of file.
Adam