TIFF and LibTiff Mail List Archive


1994.02.10 19:32 "LibTIFF working on MS-Windows 3.1.", by Soren Pingel Dalsgaard
1994.02.11 09:39 "Re: LibTIFF working on MS-Windows 3.1.", by Bjorn P. Brox
1994.02.11 01:09 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 14:40 "Re: LibTIFF working on MS-Windows 3.1.", by Jie Yao
1994.02.11 01:16 "Re: LibTIFF working on MS-Windows 3.1.", by Richard Minner
1994.02.11 10:17 "Re: LIBTIFFW working on MS-Windows 3.1.", by Niles Ritter
1994.02.14 11:03 "Error/warning handlers in libtiff", by Erik Corry
1994.02.16 22:38 "Re: Error/warning handlers in libtiff", by Sam Leffler
1994.02.11 18:27 "Re: LibTIFF working on MS-Windows 3.1.", by Francois Gauthier
1994.02.11 21:29 "Re: LibTIFF working on MS-Windows 3.1.", by Sam Leffler

1994.02.11 10:17 "Re: LIBTIFFW working on MS-Windows 3.1.", by Niles Ritter

Soren Dalsgaard writes,

The following changes has been made to the library:

As others have mentioned, there are of course ways to override the default action. The real point, though, is that you would like to formulate the new way of performing an interface-action in such a way that it can be gracefully integrated with the libtiff proper. The reason isn't just for other host's sake; if your code remains compatible with the public libtiff, then when improvements/new compression schemes (such as the long-awaited JPEG-in-TIFF) become part of libtiff you will not have to deal with so much grief.

Actually, they only look large to humans; to the computer they're *all* pairs of 4-byte integers :-) Seriously, for some applications the issue of keeping high precision is important. The current implementation in libtiff is good, but in general gives an accuracy of order (N), where N is the size of the denominator. Mathematicians have known for some time that you can do much better, and there is a theorem that by representing the desired real number as a continued fraction expansion (ie, a+1/(b+1/(c+...))), where a,b,c, are integers) you can find a fraction differing by order (N**2). (recursive code left as an exercise). The nice part is that the continued fraction will automatically be in reduced form, so you don't have to look for common factors.

This is one sure way to invite new flames about the TIFF spec's. A program which can only read a certain byte-order TIFF cannot claim to be a TIFF compliant program (and reveals a certain "endian-centric" orientation on the part of that programmer). This feature probably won't make it into the libtiff, although I don't speak for Sam Leffler.

I am of course assuming here that the reason one would want to be able to write foreign was to accomodate brain-damaged TIFF readers. The only other time I can imagine that this would be a desirable feature is if you were writing a HUGE TIFF image (say, 600Megs or so) which was going to go onto a archive run on a foreign-byte-order machine, in which case you'd like to avoid the byte-swapping overhead. But even then, if this was a networked environment some of the client machines may not be in the same byte-order, so we're back to square one.

BUT: where can I put these files for the public?

You should e-mail the changes (preferable in "diff" format) to Sam Leffler, rather than posting the changes to the group. Sam's been on sabbatical (I didn't know SGI was a university :-), but should be around soon.

His last posting on this list was on 17 Nov, and read as follows:

  From Wed Nov 17 07:46:55 1993
  Date: Wed, 17 Nov 93 01:21:33 -0800
  From: (Sam Leffler)
  Subject: I am away
  I am away on sabbatical until February.  If your mail is about:
  flexfax         send it to the flexfax mailing list (
  tiff            send it to the tiff mailing list (
  mailing list    send mail to
  Otherwise, I'll read your mail when I return.