summaryrefslogtreecommitdiff
path: root/tiff/html/man/TIFFOpen.3tiff.html
diff options
context:
space:
mode:
authorJörg Frings-Fürst <debian@jff-webhosting.net>2015-11-06 05:38:49 +0100
committerJörg Frings-Fürst <debian@jff-webhosting.net>2015-11-06 05:38:49 +0100
commit9491825ddff7a294d1f49061bae7044e426aeb2e (patch)
tree06e651099f87140ec534ae47fb8ce1ac6ec7976d /tiff/html/man/TIFFOpen.3tiff.html
parentfa756339d4204bff7f2820067f58214d32780d17 (diff)
Imported Upstream version 1.8.3
Diffstat (limited to 'tiff/html/man/TIFFOpen.3tiff.html')
-rwxr-xr-xtiff/html/man/TIFFOpen.3tiff.html421
1 files changed, 421 insertions, 0 deletions
diff --git a/tiff/html/man/TIFFOpen.3tiff.html b/tiff/html/man/TIFFOpen.3tiff.html
new file mode 100755
index 0000000..2379121
--- /dev/null
+++ b/tiff/html/man/TIFFOpen.3tiff.html
@@ -0,0 +1,421 @@
+<!-- Creator : groff version 1.18.1 -->
+<!-- CreationDate: Sat Feb 24 18:37:16 2007 -->
+<html>
+<head>
+<meta name="generator" content="groff -Thtml, see www.gnu.org">
+<meta name="Content-Style" content="text/css">
+<title>TIFFOpen</title>
+</head>
+<body>
+
+<h1 align=center>TIFFOpen</h1>
+<a href="#NAME">NAME</a><br>
+<a href="#SYNOPSIS">SYNOPSIS</a><br>
+<a href="#DESCRIPTION">DESCRIPTION</a><br>
+<a href="#OPTIONS">OPTIONS</a><br>
+<a href="#BYTE ORDER">BYTE ORDER</a><br>
+<a href="#RETURN VALUES">RETURN VALUES</a><br>
+<a href="#DIAGNOSTICS">DIAGNOSTICS</a><br>
+<a href="#SEE ALSO">SEE ALSO</a><br>
+
+<hr>
+<a name="NAME"></a>
+<h2>NAME</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p>TIFFOpen, TIFFFdOpen, TIFFClientOpen &minus; open a
+<small>TIFF</small> file for reading or writing</p>
+</td>
+</table>
+<a name="SYNOPSIS"></a>
+<h2>SYNOPSIS</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p><b>#include &lt;tiffio.h&gt;</b></p>
+<!-- INDENTATION -->
+<p><b>TIFF* TIFFOpen(const char *</b><i>filename</i><b>,
+const char *</b><i>mode</i><b>)<br>
+TIFF* TIFFFdOpen(const int</b> <i>fd</i><b>, const char
+*</b><i>filename</i><b>, const char
+*</b><i>mode</i><b>)</b></p>
+<!-- INDENTATION -->
+<p><b>typedef tsize_t (*TIFFReadWriteProc)(thandle_t,
+tdata_t, tsize_t);<br>
+typedef toff_t (*TIFFSeekProc)(thandle_t, toff_t, int);<br>
+typedef int (*TIFFCloseProc)(thandle_t);<br>
+typedef toff_t (*TIFFSizeProc)(thandle_t);<br>
+typedef int (*TIFFMapFileProc)(thandle_t, tdata_t*,
+toff_t*);<br>
+typedef void (*TIFFUnmapFileProc)(thandle_t, tdata_t,
+toff_t);</b></p>
+<!-- INDENTATION -->
+<p><b>TIFF* TIFFClientOpen(const char
+*</b><i>filename</i><b>, const char *</b><i>mode</i><b>,
+thandle_t</b> <i>clientdata</i><b>, TIFFReadWriteProc</b>
+<i>readproc</i><b>, TIFFReadWriteProc</b>
+<i>writeproc</i><b>, TIFFSeekProc</b> <i>seekproc</i><b>,
+TIFFCloseProc</b> <i>closeproc</i><b>, TIFFSizeProc</b>
+<i>sizeproc</i><b>, TIFFMapFileProc</b> <i>mapproc</i><b>,
+TIFFUnmapFileProc</b> <i>unmapproc</i><b>)</b></p>
+</td>
+</table>
+<a name="DESCRIPTION"></a>
+<h2>DESCRIPTION</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p><i>TIFFOpen</i> opens a <small>TIFF</small> file whose
+name is <i>filename</i> and returns a handle to be used in
+subsequent calls to routines in <i>libtiff</i>. If the open
+operation fails, then zero is returned. The <i>mode</i>
+parameter specifies if the file is to be opened for reading
+(&lsquo;&lsquo;r&rsquo;&rsquo;), writing
+(&lsquo;&lsquo;w&rsquo;&rsquo;), or appending
+(&lsquo;&lsquo;a&rsquo;&rsquo;) and, optionally, whether to
+override certain default aspects of library operation (see
+below). When a file is opened for appending, existing data
+will not be touched; instead new data will be written as
+additional subfiles. If an existing file is opened for
+writing, all previous data is overwritten.</p>
+<!-- INDENTATION -->
+<p>If a file is opened for reading, the first
+<small>TIFF</small> directory in the file is automatically
+read (also see <i>TIFFSetDirectory</i>(3TIFF) for reading
+directories other than the first). If a file is opened for
+writing or appending, a default directory is automatically
+created for writing subsequent data. This directory has all
+the default values specified in <small>TIFF</small> Revision
+6.0: <i>BitsPerSample</i>=1, <i>ThreshHolding</i>=bilevel
+art scan, <i>FillOrder</i>=1 (most significant bit of each
+data byte is filled first), <i>Orientation</i>=1 (the 0th
+row represents the visual top of the image, and the 0th
+column represents the visual left hand side),
+<i>SamplesPerPixel</i>=1, <i>RowsPerStrip</i>=infinity,
+<i>ResolutionUnit</i>=2 (inches), and <i>Compression</i>=1
+(no compression). To alter these values, or to define values
+for additional fields, <i>TIFFSetField</i>(3TIFF) must be
+used.</p>
+<!-- INDENTATION -->
+<p><i>TIFFFdOpen</i> is like <i>TIFFOpen</i> except that it
+opens a <small>TIFF</small> file given an open file
+descriptor <i>fd</i>. The file&rsquo;s name and mode must
+reflect that of the open descriptor. The object associated
+with the file descriptor <b>must support random
+access</b>.</p>
+<!-- INDENTATION -->
+<p><i>TIFFClientOpen</i> is like <i>TIFFOpen</i> except that
+the caller supplies a collection of functions that the
+library will use to do <small>UNIX</small> -like I/O
+operations. The <i>readproc</i> and <i>writeproc</i> are
+called to read and write data at the current file position.
+<i>seekproc</i> is called to change the current file
+position a la <i>lseek</i>(2). <i>closeproc</i> is invoked
+to release any resources associated with an open file.
+<i>sizeproc</i> is invoked to obtain the size in bytes of a
+file. <i>mapproc</i> and <i>unmapproc</i> are called to map
+and unmap a file&rsquo;s contents in memory; c.f.
+<i>mmap</i>(2) and <i>munmap</i>(2). The <i>clientdata</i>
+parameter is an opaque &lsquo;&lsquo;handle&rsquo;&rsquo;
+passed to the client-specified routines passed as parameters
+to <i>TIFFClientOpen</i>.</p>
+</td>
+</table>
+<a name="OPTIONS"></a>
+<h2>OPTIONS</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p>The open mode parameter can include the following flags
+in addition to the &lsquo;&lsquo;r&rsquo;&rsquo;,
+&lsquo;&lsquo;w&rsquo;&rsquo;, and
+&lsquo;&lsquo;a&rsquo;&rsquo; flags. Note however that
+option flags must follow the read-write-append
+specification.</p>
+</td>
+</table>
+<!-- TABS -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="5" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>l</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>When creating a new file force information be written
+with Little-Endian byte order (but see below). By default
+the library will create new files using the native
+<small>CPU</small> byte order.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>b</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>When creating a new file force information be written
+with Big-Endian byte order (but see below). By default the
+library will create new files using the native
+<small>CPU</small> byte order.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>L</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Force image data that is read or written to be treated
+with bits filled from Least Significant Bit (
+<small>LSB</small> ) to Most Significant Bit (
+<small>MSB</small> ). Note that this is the opposite to the
+way the library has worked from its inception.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>B</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Force image data that is read or written to be treated
+with bits filled from Most Significant Bit (
+<small>MSB</small> ) to Least Significant Bit (
+<small>LSB</small> ); this is the default.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>H</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Force image data that is read or written to be treated
+with bits filled in the same order as the native
+<small>CPU.</small></p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>M</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Enable the use of memory-mapped files for images opened
+read-only. If the underlying system does not support
+memory-mapped files or if the specific image being opened
+cannot be memory-mapped then the library will fallback to
+using the normal system interface for reading information.
+By default the library will attempt to use memory-mapped
+files.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>m</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Disable the use of memory-mapped files.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>C</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Enable the use of &lsquo;&lsquo;strip
+chopping&rsquo;&rsquo; when reading images that are
+comprised of a single strip or tile of uncompressed data.
+Strip chopping is a mechanism by which the library will
+automatically convert the single-strip image to multiple
+strips, each of which has about 8 Kilobytes of data. This
+facility can be useful in reducing the amount of memory used
+to read an image because the library normally reads each
+strip in its entirety. Strip chopping does however alter the
+apparent contents of the image because when an image is
+divided into multiple strips it looks as though the
+underlying file contains multiple separate strips. Finally,
+note that default handling of strip chopping is a
+compile-time configuration parameter. The default behaviour,
+for backwards compatibility, is to enable strip
+chopping.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>c</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Disable the use of strip chopping when reading
+images.</p>
+</td>
+<td width="0%">
+</td>
+<tr valign="top" align="left">
+<td width="10%"></td>
+<td width="2%">
+
+<p><b>h</b></p>
+</td>
+<td width="6%"></td>
+<td width="80%">
+
+<p>Read TIFF header only, do not load the first image
+directory. That could be useful in case of the broken first
+directory. We can open the file and proceed to the other
+directories.</p>
+</td>
+<td width="0%">
+</td>
+</table>
+<a name="BYTE ORDER"></a>
+<h2>BYTE ORDER</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p>The <small>TIFF</small> specification (<b>all
+versions</b>) states that compliant readers <i>must be
+capable of reading images written in either byte order</i>.
+Nonetheless some software that claims to support the reading
+of <small>TIFF</small> images is incapable of reading images
+in anything but the native <small>CPU</small> byte order on
+which the software was written. (Especially notorious are
+applications written to run on Intel-based machines.) By
+default the library will create new files with the native
+byte-order of the <small>CPU</small> on which the
+application is run. This ensures optimal performance and is
+portable to any application that conforms to the TIFF
+specification. To force the library to use a specific
+byte-order when creating a new file the
+&lsquo;&lsquo;b&rsquo;&rsquo; and
+&lsquo;&lsquo;l&rsquo;&rsquo; option flags may be included
+in the call to open a file; for example,
+&lsquo;&lsquo;wb&rsquo;&rsquo; or
+&lsquo;&lsquo;wl&rsquo;&rsquo;.</p>
+</td>
+</table>
+<a name="RETURN VALUES"></a>
+<h2>RETURN VALUES</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p>Upon successful completion <i>TIFFOpen</i>,
+<i>TIFFFdOpen</i>, and <i>TIFFClientOpen</i> return a
+<small>TIFF</small> pointer. Otherwise, NULL is
+returned.</p>
+</td>
+</table>
+<a name="DIAGNOSTICS"></a>
+<h2>DIAGNOSTICS</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p>All error messages are directed to the
+<i>TIFFError</i>(3TIFF) routine. Likewise, warning messages
+are directed to the <i>TIFFWarning</i>(3TIFF) routine.</p>
+<!-- INDENTATION -->
+<p><b>&quot;%s&quot;: Bad mode</b>. The specified
+<i>mode</i> parameter was not one of
+&lsquo;&lsquo;r&rsquo;&rsquo; (read),
+&lsquo;&lsquo;w&rsquo;&rsquo; (write), or
+&lsquo;&lsquo;a&rsquo;&rsquo; (append).</p>
+<!-- INDENTATION -->
+<p><b>%s: Cannot open</b>. <i>TIFFOpen</i>() was unable to
+open the specified filename for read/writing.</p>
+<!-- INDENTATION -->
+<p><b>Cannot read TIFF header</b>. An error occurred while
+attempting to read the header information.</p>
+<!-- INDENTATION -->
+<p><b>Error writing TIFF header</b>. An error occurred while
+writing the default header information for a new file.</p>
+<!-- INDENTATION -->
+<p><b>Not a TIFF file, bad magic number %d (0x%x)</b>. The
+magic number in the header was not (hex) 0x4d4d or (hex)
+0x4949.</p>
+<!-- INDENTATION -->
+<p><b>Not a TIFF file, bad version number %d (0x%x)</b>. The
+version field in the header was not 42 (decimal).</p>
+<!-- INDENTATION -->
+<p><b>Cannot append to file that has opposite byte
+ordering</b>. A file with a byte ordering opposite to the
+native byte ordering of the current machine was opened for
+appending (&lsquo;&lsquo;a&rsquo;&rsquo;). This is a
+limitation of the library.</p>
+</td>
+</table>
+<a name="SEE ALSO"></a>
+<h2>SEE ALSO</h2>
+<!-- INDENTATION -->
+<table width="100%" border=0 rules="none" frame="void"
+ cols="2" cellspacing="0" cellpadding="0">
+<tr valign="top" align="left">
+<td width="8%"></td>
+<td width="91%">
+<p><i>libtiff</i>(3TIFF), <i>TIFFClose</i>(3TIFF)</p>
+</td>
+</table>
+<hr>
+</body>
+</html>