RubyGems - laag-libtiff - Versions diffs - 4.0.9.0 - Mend

laag-libtiff 4.0.9.0

Files changed (629) hide show

data/vendor/gitlab.com/libtiff/libtiff/html/addingtags.html ADDED Viewed

@@ -0,0 +1,292 @@
+<HTML>
+<HEAD>
+<TITLE>
+Modifying The TIFF Library
+</TITLE>
+</HEAD>
+<BODY BGCOLOR=white>
+<FONT FACE="Arial, Helvetica, Sans">
+<H1>
+Defining New TIFF Tags
+</H1>
+Libtiff has built-in knowledge of all the standard TIFF tags, as
+well as extentions.  The following describes how to add knowledge of
+new tags as builtins to libtiff, or how to application specific tags can
+be used by applications without modifying libtiff.
+<p>
+<h2>TIFFFieldInfo</h2>
+How libtiff manages specific tags is primarily controlled by the
+definition for that tag value stored internally as a TIFFFieldInfo structure.
+This structure looks like this:
+<p>
+<pre>
+typedef	struct {
+  ttag_t    field_tag;          /* field's tag */
+  short	    field_readcount;    /* read count/TIFF_VARIABLE/TIFF_SPP */
+  short	    field_writecount;   /* write count/TIFF_VARIABLE */
+  TIFFDataType field_type;      /* type of associated data */
+  unsigned short field_bit;     /* bit in fieldsset bit vector */
+  unsigned char field_oktochange;/* if true, can change while writing */
+  unsigned char field_passcount;/* if true, pass dir count on set */
+  char	*field_name;		/* ASCII name */
+} TIFFFieldInfo;
+</pre>
+<ul>
+<li> <b>field_tag</b>: the tag number.  For instance 277 for the
+SamplesPerPixel tag.  Builtin tags will generally have a #define in
+tiff.h for each known tag. <p>
+<li> <b>field_readcount</b>: The number of values which should be read.
+The special value TIFF_VARIABLE (-1) indicates that a variable number of
+values may be read.  The special value TIFFTAG_SPP (-2) indicates that there
+should be one value for each sample as defined by TIFFTAG_SAMPLESPERPIXEL.
+The special value TIFF_VARIABLE2 (-3) is presumably similar to TIFF_VARIABLE
+though I am not sure what the distinction in behaviour is.  This field
+is TIFF_VARIABLE for variable length ascii fields.<p>
+<li> <b>field_writecount</b>: The number of values which should be written.
+Generally the same as field_readcount.  A few built-in exceptions exist, but
+I haven't analysed why they differ. <p>
+<li> <b>field_type</b>: Type of the field.  One of TIFF_BYTE, TIFF_ASCII,
+TIFF_SHORT, TIFF_LONG, TIFF_RATIONAL, TIFF_SBYTE, TIFF_UNDEFINED,
+TIFF_SSHORT, TIFF_SLONG, TIFF_SRATIONAL, TIFF_FLOAT, TIFF_DOUBLE or
+TIFF_IFD.  Note that some fields can support more than one type (for
+instance short and long).  These fields should have multiple TIFFFieldInfos.
+<p>
+<li> <b>field_bit</b>: Built-in tags stored in special fields in the
+TIFF structure have assigned field numbers to distinguish them (ie.
+FIELD_SAMPLESPERPIXEL).  New tags should generally just use
+FIELD_CUSTOM indicating they are stored in the generic tag list.<p>
+<li> <b>field_oktochange</b>: TRUE if it is OK to change this tag value
+while an image is being written.  FALSE for stuff that must be set once
+and then left unchanged (like ImageWidth, or PhotometricInterpretation for
+instance).<p>
+<li> <b>field_passcount</b>: If TRUE, then the count value must be passed
+in TIFFSetField(), and TIFFGetField(), otherwise the count is not required.
+This should generally be TRUE for non-ascii variable count tags unless
+the count is implicit (such as with the colormap).<p>
+<li> <b>field_name</b>: A name for the tag.  Normally mixed case (studly caps)
+like "StripByteCounts" and relatively short. <p>
+</ul>
+A TIFFFieldInfo definition exists for each built-in tag in the tif_dirinfo.c
+file.  Some tags which support multiple data types have more than one
+definition, one per data type supported. <p>
+Various functions exist for getting the internal TIFFFieldInfo definitions,
+including _TIFFFindFieldInfo(), and _TIFFFindFieldInfoByName().  See
+tif_dirinfo.c for details.  There must be some mechanism to get the whole
+list, though I don't see it off hand.<p>
+<h2>Default Tag Auto-registration</h2>
+In libtiff 3.6.0 a new mechanism was introduced allowing libtiff to
+read unrecognised tags automatically.  When an unknown tags is encountered,
+it is automatically internally defined with a default name and a type
+derived from the tag value in the file.  Applications only need to predefine
+application specific tags if they need to be able to set them in a file, or
+if particular calling conventions are desired for TIFFSetField() and
+TIFFGetField().<p>
+When tags are autodefined like this the <b>field_readcount</b> and
+<b>field_writecount</b> values are always TIFF_VARIABLE.  The
+<b>field_passcount</b> is always TRUE, and the <b>field_bit</b> is
+FIELD_CUSTOM.  The field name will be "Tag %d" where the %d is the tag
+number.<p>
+<h2>Defining Application Tags</h2>
+For various reasons, it is common for applications to want to define
+their own tags to store information outside the core TIFF specification.
+This is done by calling TIFFMergeFieldInfo() with one or more TIFFFieldInfos.
+<p>
+The libgeotiff library provides geospatial information extentions within
+a TIFF file.  First, a set of TIFFFieldInfo's is prepared with information
+on the new tags:<p>
+<pre>
+static const TIFFFieldInfo xtiffFieldInfo[] = {
+  /* XXX Insert Your tags here */
+    { TIFFTAG_GEOPIXELSCALE,	-1,-1, TIFF_DOUBLE,	FIELD_CUSTOM,
+      TRUE,	TRUE,	"GeoPixelScale" },
+    { TIFFTAG_GEOTRANSMATRIX,	-1,-1, TIFF_DOUBLE,	FIELD_CUSTOM,
+      TRUE,	TRUE,	"GeoTransformationMatrix" },
+    { TIFFTAG_GEOTIEPOINTS,	-1,-1, TIFF_DOUBLE,	FIELD_CUSTOM,
+      TRUE,	TRUE,	"GeoTiePoints" },
+    { TIFFTAG_GEOKEYDIRECTORY, -1,-1, TIFF_SHORT,	FIELD_CUSTOM,
+      TRUE,	TRUE,	"GeoKeyDirectory" },
+    { TIFFTAG_GEODOUBLEPARAMS,	-1,-1, TIFF_DOUBLE,	FIELD_CUSTOM,
+      TRUE,	TRUE,	"GeoDoubleParams" },
+    { TIFFTAG_GEOASCIIPARAMS,	-1,-1, TIFF_ASCII,	FIELD_CUSTOM,
+      TRUE,	FALSE,	"GeoASCIIParams" }
+};
+</pre>
+In order to define the tags, we call TIFFMergeFieldInfo() on the
+desired TIFF handle with the list of TIFFFieldInfos.<p>
+<pre>
+#define	N(a)	(sizeof (a) / sizeof (a[0]))
+    /* Install the extended Tag field info */
+    TIFFMergeFieldInfo(tif, xtiffFieldInfo, N(xtiffFieldInfo));
+</pre>
+The tags need to be defined for each TIFF file opened - and when reading
+they should be defined before the tags of the file are read, yet a valid
+TIFF * is needed to merge the tags against.   In order to get them
+registered at the appropriate part of the setup process, it is necessary
+to register our merge function as an extender callback with libtiff.
+This is done with TIFFSetTagExtender().  We also keep track of the
+previous tag extender (if any) so that we can call it from our extender
+allowing a chain of customizations to take effect. <P>
+<pre>
+static TIFFExtendProc _ParentExtender = NULL;
+static
+void _XTIFFInitialize(void)
+{
+    static int first_time=1;
+    if (! first_time) return; /* Been there. Done that. */
+    first_time = 0;
+    /* Grab the inherited method and install */
+    _ParentExtender = TIFFSetTagExtender(_XTIFFDefaultDirectory);
+}
+</pre>
+The extender callback is looks like this.  It merges in our new fields
+and then calls the next extender if there is one in effect.<p>
+<pre>
+static void
+_XTIFFDefaultDirectory(TIFF *tif)
+{
+    /* Install the extended Tag field info */
+    TIFFMergeFieldInfo(tif, xtiffFieldInfo, N(xtiffFieldInfo));
+    /* Since an XTIFF client module may have overridden
+     * the default directory method, we call it now to
+     * allow it to set up the rest of its own methods.
+     */
+    if (_ParentExtender)
+        (*_ParentExtender)(tif);
+}
+</pre>
+The above approach ensures that our new definitions are used when reading
+or writing any TIFF file.  However, since on reading we already have
+default definitions for tags, it is usually not critical to pre-define them.
+If tag definitions are only required for writing custom tags, you can just
+call TIFFMergeFieldInfo() before setting new tags.  The whole extender
+architecture can then be avoided.<p>
+<A NAME=AddingTags><P><H2>Adding New Builtin Tags</H2></A>
+A similar approach is taken to the above.  However, the TIFFFieldInfo
+should be added to the tiffFieldInfo[] list in tif_dirinfo.c.  Ensure that
+new tags are added in sorted order by the tag number.<p>
+Normally new built-in tags should be defined with FIELD_CUSTOM; however, if
+it is desirable for the tag value to have it's own field in the TIFFDirectory
+structure, then you will need to #define a new FIELD_ value for it, and
+add appropriate handling as follows:
+<OL>
+<LI>Define the tag in <B>tiff.h</B>.
+<LI>Add a field to the directory structure in <B>tif_dir.h</B>
+   and define a <TT>FIELD_*</TT> bit (also update the definition of
+   <TT>FIELD_CODEC</TT> to reflect your addition).
+<LI>Add an entry in the <TT>TIFFFieldInfo</TT> array defined at the top of
+   <B>tif_dirinfo.c</B>.
+   Note that you must keep this array sorted by tag
+   number and that the widest variant entry for a tag should come
+   first (e.g. <TT>LONG</TT> before <TT>SHORT</TT>).
+<LI>Add entries in <TT>_TIFFVSetField()</TT> and <TT>_TIFFVGetField()</TT>
+   for the new tag.
+<LI>(<I>optional</I>) If the value associated with the tag is not a scalar value
+   (e.g. the array for <TT>TransferFunction</TT>) and requires
+   special processing,
+   then add the appropriate code to <TT>TIFFReadDirectory()</TT> and
+   <TT>TIFFWriteDirectory()</TT>.  You're best off finding a similar tag and
+   cribbing code.
+<LI>Add support to <TT>TIFFPrintDirectory()</TT> in <B>tif_print.c</B>
+    to print the tag's value.
+</OL>
+<P>
+If you want to maintain portability, beware of making assumptions
+about data types.  Use the typedefs (<TT>uint16</TT>, etc. when dealing with
+data on disk and <TT>t*_t</TT> when stuff is in memory) and be careful about
+passing items through printf or similar vararg interfaces.
+<A NAME=AddingCODECTags><P><H2>Adding New Codec-private Tags</H2></A>
+To add tags that are meaningful <EM>only when a particular compression
+algorithm is used</EM> follow these steps:
+<OL>
+<LI>Define the tag in <B>tiff.h</B>.
+<LI>Allocate storage for the tag values in the private state block of
+   the codec.
+<LI>Insure the state block is created when the codec is initialized.
+<LI>At <TT>TIFFInitfoo</TT> time override the method pointers in the
+    TIFF structure
+   for getting, setting and printing tag values.  For example,
+<PRE>
+    sp->vgetparent = tif->tif_vgetfield;
+    tif->tif_vgetfield = fooVGetField;	/* hook for codec tags */
+    sp->vsetparent = tif->tif_vsetfield;
+    tif->tif_vsetfield = fooVSetField;	/* hook for codec tags */
+    tif->tif_printdir = fooPrintDir;	/* hook for codec tags */
+</PRE>
+   (Actually you may decide not to override the
+   <TT>tif_printdir</TT> method, but rather just specify it).
+<LI>Create a private <TT>TIFFFieldInfo</TT> array for your tags and
+    merge them into the core tags at initialization time using
+    <TT>_TIFFMergeFieldInfo</TT>; e.g.
+<PRE>
+    _TIFFMergeFieldInfo(tif, fooFieldInfo, N(fooFieldInfo));
+</PRE>
+   (where <TT>N</TT> is a macro used liberaly throughout the distributed code).
+<LI>Fill in the get and set routines.  Be sure to call the parent method
+   for tags that you are not handled directly.  Also be sure to set the
+   <TT>FIELD_*</TT> bits for tags that are to be written to the file.  Note that
+   you can create ``pseudo-tags'' by defining tags that are processed
+   exclusively in the get/set routines and never written to file (see
+   the handling of <TT>TIFFTAG_FAXMODE</TT> in <B>tif_fax3.c</B>
+   for an example of this).
+<LI>Fill in the print routine, if appropriate.
+</OL>
+Note that space has been allocated in the <TT>FIELD_*</TT> bit space for
+codec-private tags.  Define your bits as <TT>FIELD_CODEC+&lt;offset&gt;</TT> to
+keep them away from the core tags.  If you need more tags than there
+is room for, just increase <TT>FIELD_SETLONGS</TT> at the top of
+<B>tiffiop.h</B>.
+<HR>
+Last updated: $Date: 2016-09-25 20:05:44 $
+</BODY>
+</HTML>

data/vendor/gitlab.com/libtiff/libtiff/html/bigtiffdesign.html ADDED Viewed

@@ -0,0 +1,80 @@
+<html>
+<head>
+<title>BigTIFF Design</title>
+</head>
+<body>
+<h1>BigTIFF Design</h1>
+<p>This is the HTML equivalent of a former Wiki working place for preparing a 64-bit (larger than 4GB) TIFF
+format specification. The design is based on a proposal by Steve Carlsen of Adobe, with input from various
+other parties.</p>
+<h2>Briefly</h2>
+<ul>
+<li>Version = 43</li>
+<li>8-byte offset to first IFD</li>
+<li>Value/Offset fields are 8 bytes</li>
+<li>8-byte offset to the next IFD</li>
+<li>add TIFFType of LONG8, an 8 byte (unsigned) int</li>
+<li>StripOffsets and TileOffsets and ByteCounts can be LONG8</li>
+</ul>
+<h2>More Detail</h2>
+<ul>
+<li>The Version ID, in header bytes 2-3, formerly decimal 42, now changes to 43</li>
+<li>Header bytes 4-5 contain the decimal number 8.<ul>
+  <li>If there is some other number here, a reader should give up.</li>
+  <li>This is to provide a nice way to move to 16-byte pointers some day.</li></ul></li>
+<li>Header bytes 6-7 are reserved and must be zero.<ul>
+  <li>If they're not, a reader should give up.</li></ul></li>
+<li>Header bytes 8-15 contain the 8-byte offset to the first IFD.</li>
+<li>Value/Offset fields are 8 bytes long, and take up bytes 8-15 in an IFD entry.<ul>
+  <li>If the value is <= 8 bytes, it must be stored in the field.</li>
+  <li>All values must begin at an 8-byte-aligned address.</li></ul></li>
+<li>8-byte offset to the Next_IFD, at the end of an IFD.</li>
+<li>To keep IFD entries 8-byte-aligned, we begin with an 8-byte (instead of 2-byte) count of the number of directory entries.</li>
+<li>Add TIFFTypes of LONG8 (= 16), an 8 byte (unsigned) int, and SLONG8 (= 17).</li>
+<li>Add TIFFType IFD8 (=18) an 8byte IFD offset.</li>
+<li>StripOffsets and TileOffsets and ByteCounts may be LONG8 or the traditionally allowed LONG or SHORT.</li>
+<li>The proposed extension is ".tf8", and call it "8-Byte TIFF".</li>
+</ul>
+<p>Otherwise, it's just like "original TIFF." ("TIFF Classic?")</p>
+<h2>Open Issues</h2>
+<ul>
+<li>What to call the new format<ul>
+  <li>ChrisCox -- I don't think end users will understand what "8-byte TIFF" means</li>
+  <li>AndreyKiselev - 23 Sep 2004 -- What about TIFF64? "64" is a widely used buzzword and should be directly associated with the 64-bit offsets and 64-bit architectures.</li></ul></li>
+<li>What 3 character file extension to use (gotta be DOS compatible)</li>
+<li>What 4 character file type to use (for Macintosh)</li>
+<li>What MIME type to use</li>
+</ul>
+<h2>Samples</h2>
+<p><a href="http://www.awaresystems.be/imaging/tiff/bigtiff/BigTIFFSamples.zip">Example files</a> from Joris Van Damme</p>
+<h2>Changes</h2>
+<ul>
+<li>TIFFType 13 is ttIFD, 14 is assigned to ttUnicode, and 15 is assigned to ttComplex. So, I changed the types for ttLong8 and ttSLong8 to 16 and 17, respectively.<ul>
+  <li>AndreyKiselev - 23 Sep 2004 -- Where are these fields defined? Is there any new Technical Note or something? And what is encoding behind the word "Unicode"?</li>
+  <li>ChrisCox - 27 Sep 2004 -- They are in the Adobe TIFF definitions.  I am still working on releasing updated TIFF documentation.</li></ul></li>
+<li>Added list of open issues.</li>
+<li>settle on version 43</li>
+<li>cleanup</li>
+<li>TIFFType 18 (8 byte IFD) added.</li>
+<li>Clarified that fields which may be LONG8 can also be one of the old supported types.</li>
+</ul>
+<h2>See also</h2>
+<p><a href="http://www.awaresystems.be/imaging/tiff/bigtiff.html">AWare Systems' informal overview of the BigTIFF proposal</a></p>
+</body>
+</html>

data/vendor/gitlab.com/libtiff/libtiff/html/bigtiffpr.html ADDED Viewed

@@ -0,0 +1,77 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html lang="en">
+<head>
+  <title>Extending LibTiff library with support for the new BigTIFF format</title>
+  <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
+  <meta http-equiv="content-language" content="en">
+</head>
+<body lang="en" text="#000000" bgcolor="#ffffff" link="#0000ff" alink="#0000ff" vlink="#0000ff">
+  <h1>Extending LibTiff library with support for the new BigTIFF format</h1>
+  <p>
+    <a href="http://www.simplesystems.org/libtiff//">LibTiff</a> maintainers have started work on LibTiff 4.0,
+    the next major upgrade of the time-proven <a href="http://www.awaresystems.be/imaging/tiff.html">TIFF</a>
+    codec. This upgrade will include support for the new BigTIFF file format. It is planned a preliminary
+    version (LibTiff 4.0alpha1) will be operational by June 15, 2007. Testing and final release improvements
+    for LibTiff 4.0 will be completed by July 30, 2007.
+  </p>
+  <p>
+    BigTIFF logically extends the original TIFF file format (referred to as 'ClassicTIFF' from now on),
+    breaking the 4 gigabyte boundary, with 64bit offsets allowing files up to 18,000 petabytes in size. The
+    BigTIFF specification is the result of work by a variety of parties on the LibTiff mailing list, including
+    the current LibTiff maintainers, Joris Van Damme and Adobe staff. The BigTIFF specification has not yet
+    been officially approved by the TIFF specification owner (Adobe), but implementation within LibTiff
+    could accelerate that process. For more information on the BigTIFF file format, we recommend AWare Systems'
+    <a href="http://www.awaresystems.be/imaging/tiff/bigtiff.html">BigTIFF page</a>.
+  </p>
+  <p>
+    BigTIFF will be especially useful for people and vendors that are confronted with very large images, and
+    still seek to use an open, simple, and extendable format. This requirement is frequently encountered in the
+    geospatial field, but also concerns large format scanners, medical imaging and other fields.
+  </p>
+  <p>
+    The LibTiff BigTIFF upgrade is made possible by four sponsors funding the project. The programming work will
+    primarily be done by <a href="http://www.awaresystems.be/index.html">Joris Van Damme (AWare Systems)</a>.
+    LibTiff's licensing agreement will remain unchanged. More details on the project itself, are available from
+    the <a href="http://www.simplesystems.org/libtiff//BigTIFFProposal.html">BigTIFF in LibTiff project page</a>.
+  </p>
+  <p>
+    The sponsors are, in alphabetical order:
+  </p>
+  <table cellspacing="4" cellpadding="4" border="0">
+    <tbody>
+      <tr>
+        <td><img src="bigtiffpr_images/esri.png" width="128" height="78" alt="ESRI" border="0"></td>
+        <td><a href="http://www.esri.com/">ESRI</a> has been giving customers around the world the power to
+          think and plan geographically since 1969.  As the leader in GIS, ESRI applies innovative technologies to help
+          organizations create, analyze, and visualize information for more informed decisions.  Running on more than
+          a million desktops and thousands of servers, ESRI applications are the foundation of the world's mapping and
+          spatial analysis infrastructure.</td>
+      </tr>
+      <tr>
+        <td><img src="bigtiffpr_images/leica.png" width="128" height="85" alt="Leica Geosystems Geospatial Imaging" border="0"></td>
+        <td><a href="http://gi.leica-geosystems.com/default.aspx">Leica Geosystems Geospatial Imaging</a> offers a
+          range of workflow solutions for photogrammetry, mapping, remote sensing, catalog management and exploitation
+          of geospatial imagery. Enterprise organizations use this imagery as the basis for generating information for
+          both education and decision making processes. Those who use Leica Geosystems products every day trust them
+          for their precision, seamless integration, interoperability and superior customer support.</td>
+      </tr>
+      <tr>
+        <td><img src="bigtiffpr_images/safe.png" width="128" height="53" alt="Safe Software" border="0"></td>
+        <td><a href="http://www.safe.com/">Safe Software</a> is the maker of FME, a powerful spatial ETL (Extract,
+          Transform and Load) tool that enables true data interoperability. FME manages the translation,
+          transformation, integration and web-based distribution of geospatial data in 200 GIS, CAD, raster and
+          database formats. Safe Software's FME technology is also embedded in numerous market-leading GIS and
+          ETL applications.</td>
+      </tr>
+      <tr>
+        <td><img src="bigtiffpr_images/weogeo.png" width="128" height="37" alt="WeoGeo" border="0"></td>
+	<td><a href="http://www.weogeo.com/">WeoGeo</a> is a web-based data management resource for the geospatial
+          industry that allows the free market exchange of mapping related imagery products, featuring an innovative
+          solution that efficiently manages digital mapping files of any size. With an intuitive user interface
+          and the scalable power of Amazon Web Services (AWS), geospatial professionals can view, sort, search,
+          and share complex, high volume maps quickly and effectively.</td>
+      </tr>
+    </tbody>
+  </table>
+</body>
+</html>