Imported Upstream version 1.8.3

author: Jörg Frings-Fürst <debian@jff-webhosting.net> 2015-11-06 05:38:49 +0100
committer: Jörg Frings-Fürst <debian@jff-webhosting.net> 2015-11-06 05:38:49 +0100
commit: 9491825ddff7a294d1f49061bae7044e426aeb2e (patch)
tree: 06e651099f87140ec534ae47fb8ce1ac6ec7976d /tiff/html/v4.0.0.html
parent: fa756339d4204bff7f2820067f58214d32780d17 (diff)
1 files changed, 269 insertions, 0 deletions
diff --git a/tiff/html/v4.0.0.html b/tiff/html/v4.0.0.html
new file mode 100755
index 0000000..9694a1e
--- /dev/null
+++ b/tiff/html/v4.0.0.html
@@ -0,0 +1,269 @@
+<HTML>
+<HEAD>
+<TITLE>
+	Changes in TIFF v4.0.0
+</TITLE>
+</HEAD>
+
+<BODY BGCOLOR=white>
+<FONT FACE="Helvetica, Arial, Sans">
+<FONT FACE="Helvetica, Arial, Sans"> 
+
+<BASEFONT SIZE=4>
+<B><FONT SIZE=+3>T</FONT>IFF <FONT SIZE=+2>C</FONT>HANGE <FONT SIZE=+2>I</FONT>NFORMATION</B>
+<BASEFONT SIZE=3>
+
+<UL>
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+<B>Current Version</B>: v4.0.0<BR>
+<B>Previous Version</B>: <A HREF=v3.9.5.html>v3.9.5</a><BR>
+<B>Master FTP Site</B>: <A HREF="ftp://ftp.remotesensing.org/pub/libtiff">
+ftp.remotesensing.org</a>, directory pub/libtiff</A><BR>
+<B>Master HTTP Site</B>: <A HREF="http://download.osgeo.org/libtiff">
+http://download.osgeo.org/libtiff</a> 
+<HR SIZE=4 WIDTH=65% ALIGN=left>
+</UL>
+
+<P>
+This document describes the changes made to the software between the
+<I>previous</I> and <I>current</I> versions (see above).  If you don't
+find something listed here, then it was not done in this timeframe, or
+it was not considered important enough to be mentioned. Please consult
+the ChangeLog file in the source package for full change details.  The
+following information is located here:
+<UL>
+<LI><A HREF="#hightlights">Major Changes</A>
+<LI><A HREF="#configure">Changes in the software configuration</A>
+<LI><A HREF="#libtiff">Changes in libtiff</A>
+<LI><A HREF="#tools">Changes in the tools</A>
+<LI><A HREF="#contrib">Changes in the contrib area</A>
+</UL>
+<p> 
+<P><HR WIDTH=65% ALIGN=left>
+
+<!--------------------------------------------------------------------------->
+
+<P><A NAME="highlights"><B><FONT SIZE=+3>M</FONT>AJOR CHANGES:</B></A></P>
+
+BigTIFF support changes:
+
+<UL>
+
+	<LI>The options parameter in the TIFFOpen and TIFFClientOpen funcs has
+	been extended. When creating new files, you can add option '4' to
+	specify you want to create a ClassicTIFF file, though that is the
+	default and the option is not strictly necessary. (As such, old
+	calling code will continue to function and create ClassicTIFF files.)
+	Or you can add option '8' to specify you want to create a BigTIFF file
+	instead. This new option is also reflected in some of the tools we
+	already upgraded. For instance, you can use the -8 option on tiffcp to
+	have tiffcp produce BigTIFF files instead of the default ClassicTIFF.
+	(Whilst on additional option is provided for version selection when
+	creating new files, no such option is necessary when reading TIFF
+	files. LibTiff reads ClassicTIFF and BigTIFF both, and the application
+	does not need to be aware which TIFF version an opened file is.)
+
+	<LI>Although the tag count in BigTIFF is 64bit, we restricted the
+	count in the implementation to a much more reasonable size. This is
+	necessary in current implementation, because all tag data gets read
+	automatically in the IFD reading stage, so if there's half a dozen
+	private tags with multiple gigabytes of data that causes considerable
+	overhead even if the application level is never interested in these
+	tags. Our choice to ignore tags with data longer then a certain sanity
+	value is much needed as things stand. We also recommend to step away
+	from writing tiles that are 8 kilobyte in their uncompressed form, or
+	writing single-line strips, in really big files, resulting in mega's
+	of tiles or strips. It's much more efficient to choose bigger tile or
+	strip sizes, up to several megabyte if needed, and have a few kilo of
+	tiles or strips instead.
+
+	<LI>Although it's rare, some application code does directly access
+	file offsets. Some of these are automatically upgraded because they
+	used the toff_t type, others need to be aware that the datatype
+	changed and need to start using toff_t or uint64. This impacts access
+	to tags like the EXIF IFD tag, for example, or the SubIfds tag, or to
+	StripOffsets or TileOffsets, the return type of functions like
+	TIFFCurrentDirOffset, and a parameter type to functions like
+	TIFFSetSubDirectory.
+
+	<LI>Although it's rare, some application code does use structures
+	like TIFFHeader or TIFFDirEntry that used to be an exact binary
+	representation of TIFF structures. These need to change. The old
+	TIFFHeader structure is replaced by the new TIFFHeaderClassic,
+	TIFFHeaderBig, and TIFFHeaderCommon structures that are an exact
+	binary representation of the ClassicTIFF and BigTIFF header, and of
+	the part that is common to both. There is no new equivalent for the
+	old TIFFDirEntry structure (or more precisely, there is still a
+	TIFFDirEntry structure, but it is changed, moved to library-private
+	definition, and no longer an exact binary representation of the tag
+	structure of either TIFF version).
+
+	<LI>Sizer functions, like TIFFTileSize or TIFFScanlineSize and the
+	like, return a tmsize_t value (tmsize_t is defined as int32 on 32bit
+	machines, and int64 on 64bit machines, and as such it is meant to
+	represent signed memory sizes). This is because we figure 98% of the
+	calling code uses the return value as sizes in allocations and the
+	like. So, any overflow that is theoretically possible with BigTIFF
+	when LibTiff is running on a 32bit system, is best detected inside the
+	sizer functions and it is best to return a type that makes sense as a
+	memory size. If your calling code is the exception and is interested
+	in actual file size, you best use the newer TIFFTileSize64 or
+	TIFFScanlineSize64 function that returns an uint64 type.
+
+	<LI>These TIFF tags require a 64-bit type as an argument in
+	libtiff 4.0.0:
+	<UL>
+	<LI> TIFFTAG_FREEBYTECOUNTS
+	<LI> TIFFTAG_FREEOFFSETS
+	<LI> TIFFTAG_STRIPBYTECOUNTS
+	<LI> TIFFTAG_STRIPOFFSETS
+	<LI> TIFFTAG_TILEBYTECOUNTS
+	<LI> TIFFTAG_TILEOFFSETS
+	</UL>
+
+</UL>
+
+Other important backward incompatible changes in the public API:
+
+<UL>
+	<LI> TIFFRewriteField() renamed into _TIFFRewriteField() and moved out
+	from the public interface (from tiffio.h to tiffiop.h). Type of its
+	'count' parameter changed from uint32 to tmsize_t.
+
+	<LI> TIFFMergeFieldInfo() returns non-void result now. It returns 0
+	if successful and -1 if failed. Though this is now obsoleted function
+	and should not be used in new programs. Use the new tag extension
+	scheme instead.
+
+	<LI> TIFFFieldWithTag() and TIFFFieldWithName() functions now return
+	pointer to TIFFField constant object instead of TIFFFieldInfo.
+
+	<LI> TIFFReassignTagToIgnore() function and TIFFIgnoreSense enumeration
+	have been removed. They was unused and never been used properly.
+	Should be unneeded for high-level applications.
+
+	<LI> TIFFTagValue structure removed from the public tiffio.h
+	to private tif_dir.h and not accessible anymore. It should be unneeded
+	for high-level applications.
+
+</UL>
+
+<P><HR WIDTH=65% ALIGN=left>
+<!--------------------------------------------------------------------------->
+
+<P><A NAME="configure"><B><FONT SIZE=+3>C</FONT>HANGES IN THE SOFTWARE CONFIGURATION:</B></A></P>
+
+<UL>
+
+	<LI>Updated autotools: Autoconf 2.68, Automake 1.11.1, libtool
+	2.4.
+
+	<LI>Enabled support for Automake silent build rules
+	(--enable-silent-rules or 'make V=0')
+
+	<LI>Enabled support for Automake colorized and parallel tests.
+
+	<LI>Added detection of 64-bit integer types since libtiff 4.0
+	requires use of 64-bit signed and unsigned integer types.
+
+	<LI>Libtiff now provides a more comprehensive test suite with
+	over 72 tests, which may be executed on Unix-like systems, or
+	under Microsoft Windows using MinGW/MSYS or Cygwin.
+
+	<LI>--disable-lzma configure option to disable use of liblzma.
+
+	<LI>--enable-defer-strile-load configure option to enable
+	experimental deferred strip/tile offset/size loading.  May
+	cause some extremely sophisticated uses of libtiff to fail.
+
+	<LI>--enable-chunky-strip-read configure option to enable
+	experimental enable reading large strips in chunks in
+	TIFFReadScanline().
+
+	<LI>Now always uses WIN32 native I/O functions for Microsoft
+	Windows except for under Cygwin.
+
+	<LI>Now provides a pkg-config support file (libtiff-4.pc).
+
+</UL>
+
+<P><HR WIDTH=65% ALIGN=left>
+
+<!--------------------------------------------------------------------------->
+
+<P><A NAME="libtiff"><B><FONT SIZE=+3>C</FONT>HANGES IN LIBTIFF:</B></A></P>
+
+<UL>
+
+        <LI>Patches/fixes made to stable libtiff (v3.9.X) are also
+        applied to 4.0.0.  There are too many to list here.  See the
+        distribution ChangeLog for a detailed change list.
+
+	<LI>There is considerable change in some files like
+	tif_dirread and tif_dirwrite. These changes don't impact
+	backwards compatibility, they are mostly a clean rewrite that
+	does allow BigTIFF support as well as somewhat more robust
+	reading of the unexpected already and will also serve future
+	API extension but does not impact current API or functionality
+	in a negative way that you need to know about.
+
+	<LI>Although there is still a functional definition for types
+	like toff_t (file offset), tstrip_t (strip index number), etc,
+	we recommend against using these in newer code. We have
+	learned that it is next to impossible to use these
+	consistently and make real abstraction of the binary format of
+	these types. Instead, at a certain level we always end up
+	doing casts anyway, and taking the exact binary format into
+	account, so these types are nothing but dangerously misleading
+	and obfuscating. You do not need to update calling code that
+	uses them, as 99.9% of such code will continue to work. But we
+	recommend against using them in newer calling code, and we
+	started replacing them with binary clear types like uint16,
+	uint32 and such in the library.
+
+	<LI>We do use and will continue to use one functional type
+	that is an exception to the above rule, being tmsize_t. This
+	is a signed memory size type, i.e. it is int32 on 32bit
+	machines, or int64 on 64bit machines.
+
+	<LI>Optionally support LZMA compression via TIFF tag 34925.
+	Tiffcp supports compression levels similar to "-c lzma:p1" or
+	"-c zip:p9 for setting the LZMA compression parameters.
+
+	<LI>Optionally defer the load of strip/tile offset and size
+	tags for optimized scanning of directories.  Enabled with the
+	--enable-defer-strile-load configure option (DEFER_STRILE_LOAD
+	#define in tif_config.h).
+
+	<LI>Optionally enable experimental support for reading big
+	strips in chunks.  Enabled with the --enable-chunky-strip-read
+	configure option.
+
+</UL>
+
+<P><HR WIDTH=65% ALIGN=left>
+
+<!-------------------------------------------------------------------------->
+	
+<P><A NAME="tools"><B><FONT SIZE=+3>C</FONT>HANGES IN THE TOOLS:</B></A></P>
+
+<UL>
+
+	<LI>tiffset: add -d and -sd switches to allow operation on
+	a particular directory, not just the first.
+
+</UL>
+
+<P><HR WIDTH=65% ALIGN=left>
+
+<!--------------------------------------------------------------------------->
+
+<P><A NAME="contrib"><B><FONT SIZE=+3>C</FONT>HANGES IN THE CONTRIB AREA:</B></A></P>
+
+<UL> 
+</UL>
+
+Last updated $Date: 2011-04-09 21:01:00 $.
+
+</BODY>
+</HTML>
author	Jörg Frings-Fürst <debian@jff-webhosting.net>	2015-11-06 05:38:49 +0100
committer	Jörg Frings-Fürst <debian@jff-webhosting.net>	2015-11-06 05:38:49 +0100
commit	9491825ddff7a294d1f49061bae7044e426aeb2e (patch)
tree	06e651099f87140ec534ae47fb8ce1ac6ec7976d /tiff/html/v4.0.0.html
parent	fa756339d4204bff7f2820067f58214d32780d17 (diff)