tiff 3.9.0 writes bad files

View: New views
8 Messages — Rating Filter:   Alert me  

tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Indications are that libtiff 3.9.0 is writing defective TIFF files.
Please don't use or distribute it.

It seems that the StripOffset and StripByteCount for the last strip in
the file are being written as zero.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Libtiff 3.9.0 is definitely botched.  It was broken by a cast that I
added to the code on the day of the release.  This is the patch needed
to resolve the problem.   In the mean time I will create a fixed
release.

Index: tif_write.c
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_write.c,v
retrieving revision 1.22.2.3
diff -u -r1.22.2.3 tif_write.c
--- tif_write.c 20 Aug 2009 20:23:52 -0000 1.22.2.3
+++ tif_write.c 28 Aug 2009 02:07:19 -0000
@@ -1,4 +1,4 @@
-/* $Id: tif_write.c,v 1.22.2.3 2009-08-20 20:23:52 bfriesen Exp $ */
+/* $Id: tif_write.c,v 1.22.2.2 2009-06-03 23:49:30 fwarmerdam Exp $ */

  /*
   * Copyright (c) 1988-1997 Sam Leffler
@@ -630,7 +630,7 @@

              if( td->td_stripbytecount[strip] != 0
                  && td->td_stripoffset[strip] != 0
-                && (tsize_t) td->td_stripbytecount[strip] >= cc )
+                && td->td_stripbytecount[strip] >= cc )
              {
                  /*
                   * There is already tile data on disk, and the new tile

--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

It seems that my quick fix is not yet enough.  It gets a simple
'tiffcp' to work but the library fails to pass GraphicsMagick's TIFF
tests.  Any strip-oriented file written by GraphicsMagick is
defective when using this libtiff.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

This is what is happening when GraphicsMagick writes the TIFF.
Before I reverted my (apparently) improper cast, this is what happened
when tiffcp wrote a file as well.

% tiffdump -m 1000 tiger-rgb-strip-contig-08.tif
tiger-rgb-strip-contig-08.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 16214 (0x3f56) next 0 (0)
ImageWidth (256) SHORT (3) 1<73>
ImageLength (257) SHORT (3) 1<76>
BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<2>
DocumentName (269) ASCII (2) 30<tiger-rgb-strip-contig-08.tif\0>
ImageDescription (270) ASCII (2) 27<8-bit contiguous RGB image\0>
StripOffsets (273) LONG (4) 3<8 8111 0>        <-- last strip offset 0!
SamplesPerPixel (277) SHORT (3) 1<3>
RowsPerStrip (278) SHORT (3) 1<37>
StripByteCounts (279) LONG (4) 3<8103 8103 0>  <-- last strip length 0!
XResolution (282) RATIONAL (5) 1<72>
YResolution (283) RATIONAL (5) 1<72>
PlanarConfig (284) SHORT (3) 1<1>
ResolutionUnit (296) SHORT (3) 1<1>
PageNumber (297) SHORT (3) 2<1 0>
Software (305) ASCII (2) 65<GraphicsMagick 1.4 unreleased Q32 http://www.GraphicsMagick.org/\0>
SampleFormat (339) SHORT (3) 3<1 1 1>

Is no one else seeing this problem?  Libtiff 3.9.0 was released on the
20th.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Lee Howard-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Bob Friesenhahn wrote:
> Is no one else seeing this problem?  Libtiff 3.9.0 was released on the
> 20th.

I've been distributing a copy of libtiff 3.9.0beta1 intended for HylaFAX
users since November 2007 without any reports about its brokenness.  
Sourceforge reports 118 downloads of it.  I can't speak to how many
actually are in-use.  But that was a long time ago, so I don't recall
exactly the amount of testing that I did with it, but I know that I did
enough for me to feel comfortable with 3.9.0 functionality with HylaFAX.

(I tend to use 3.8.2, however, as that's often what comes with the distro.)

I know that's not a very concrete set of evidence, but I would suggest
that it presents a likelihood that whatever problem there was in the
3.9.0 release, it entered the source code *after* beta1.

For what it's worth, generally it's a good idea to run a beta and a
release candidacy period... even after applying what otherwise would
seem to be trivial or well-exposed patches.  It saves time in the
long-run from botching releases.  I don't fault anyone in this, however,
as I've had my own mistakes in this regard multiple times.

Thanks,

Lee.

_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Thu, 27 Aug 2009, Lee Howard wrote:
>
> I know that's not a very concrete set of evidence, but I would suggest that
> it presents a likelihood that whatever problem there was in the 3.9.0
> release, it entered the source code *after* beta1.

The beta package does not exhibit the problem.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Andreas Kleinert-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

What has been changed for 3.9.1 in addition?
Could you post the other patch(es), too?

Thanks,
Andreas

Bob Friesenhahn schrieb:
> It seems that my quick fix is not yet enough.  
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/

Re: tiff 3.9.0 writes bad files

by Bob Friesenhahn :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, 30 Aug 2009, Andreas Kleinert wrote:

> What has been changed for 3.9.1 in addition?
> Could you post the other patch(es), too?

These are the changes in the 'libtiff' subdirectory:

Index: libtiff/tif_config.vc.h
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_config.vc.h,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- libtiff/tif_config.vc.h 20 Sep 2006 13:35:12 -0000 1.1
+++ libtiff/tif_config.vc.h 27 Aug 2009 23:42:09 -0000 1.1.2.1
@@ -32,6 +32,12 @@
  /* The size of a `long', as computed by sizeof. */
  #define SIZEOF_LONG 4

+/* Signed 64-bit type */
+#define TIFF_INT64_T signed __int64
+
+/* Unsigned 64-bit type */
+#define TIFF_UINT64_T unsigned __int64
+
  /* Set the native cpu bit order */
  #define HOST_FILLORDER FILLORDER_LSB2MSB

Index: libtiff/tif_dirwrite.c
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_dirwrite.c,v
retrieving revision 1.37.2.4
retrieving revision 1.37.2.5
diff -u -r1.37.2.4 -r1.37.2.5
--- libtiff/tif_dirwrite.c 25 May 2008 01:55:38 -0000 1.37.2.4
+++ libtiff/tif_dirwrite.c 28 Aug 2009 17:24:56 -0000 1.37.2.5
@@ -1,4 +1,4 @@
-/* $Id: tif_dirwrite.c,v 1.37.2.4 2008-05-25 01:55:38 fwarmerdam Exp $ */
+/* $Id: tif_dirwrite.c,v 1.37.2.5 2009-08-28 17:24:56 fwarmerdam Exp $ */

  /*
   * Copyright (c) 1988-1997 Sam Leffler
@@ -100,8 +100,6 @@
  */
  if (done)
  {
-                tsize_t orig_rawcc = tif->tif_rawcc;
-
  if (tif->tif_flags & TIFF_POSTENCODE) {
  tif->tif_flags &= ~TIFF_POSTENCODE;
  if (!(*tif->tif_postencode)(tif)) {
@@ -114,12 +112,9 @@
  (*tif->tif_close)(tif); /* shutdown encoder */
  /*
  * Flush any data that might have been written
- * by the compression close+cleanup routines.  But
-                 * be careful not to write stuff if we didn't add data
-                 * in the previous steps as the "rawcc" data may well be
-                 * a previously read tile/strip in mixed read/write mode.
+ * by the compression close+cleanup routines.
  */
- if (tif->tif_rawcc > 0 && tif->tif_rawcc != orig_rawcc
+ if (tif->tif_rawcc > 0
                      && (tif->tif_flags & TIFF_BEENWRITING) != 0
                      && !TIFFFlushData1(tif)) {
  TIFFErrorExt(tif->tif_clientdata, tif->tif_name,
Index: libtiff/tif_write.c
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tif_write.c,v
retrieving revision 1.22.2.3
retrieving revision 1.22.2.4
diff -u -r1.22.2.3 -r1.22.2.4
--- libtiff/tif_write.c 20 Aug 2009 20:23:52 -0000 1.22.2.3
+++ libtiff/tif_write.c 28 Aug 2009 02:23:19 -0000 1.22.2.4
@@ -1,4 +1,4 @@
-/* $Id: tif_write.c,v 1.22.2.3 2009-08-20 20:23:52 bfriesen Exp $ */
+/* $Id: tif_write.c,v 1.22.2.4 2009-08-28 02:23:19 bfriesen Exp $ */

  /*
   * Copyright (c) 1988-1997 Sam Leffler
@@ -630,7 +630,7 @@

              if( td->td_stripbytecount[strip] != 0
                  && td->td_stripoffset[strip] != 0
-                && (tsize_t) td->td_stripbytecount[strip] >= cc )
+                && td->td_stripbytecount[strip] >= cc )
              {
                  /*
                   * There is already tile data on disk, and the new tile
Index: libtiff/tiffvers.h
===================================================================
RCS file: /cvs/maptools/cvsroot/libtiff/libtiff/tiffvers.h,v
retrieving revision 1.13.2.2
retrieving revision 1.13.2.3
diff -u -r1.13.2.2 -r1.13.2.3
--- libtiff/tiffvers.h 20 Aug 2009 22:31:00 -0000 1.13.2.2
+++ libtiff/tiffvers.h 28 Aug 2009 18:49:02 -0000 1.13.2.3
@@ -1,4 +1,4 @@
-#define TIFFLIB_VERSION_STR "LIBTIFF, Version 3.9.0\nCopyright (c) 1988-1996 Sam Leffler\nCopyright (c) 1991-1996 Silicon Graphics, Inc."
+#define TIFFLIB_VERSION_STR "LIBTIFF, Version 3.9.1\nCopyright (c) 1988-1996 Sam Leffler\nCopyright (c) 1991-1996 Silicon Graphics, Inc."
  /*
   * This define can be used in code that requires
   * compilation-related definitions specific to a
@@ -6,4 +6,4 @@
   * version checking should be done based on the
   * string returned by TIFFGetVersion.
   */
-#define TIFFLIB_VERSION 20090820
+#define TIFFLIB_VERSION 20090828

--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: Tiff@...
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/