]>
Commit | Line | Data |
---|---|---|
8414a40c VZ |
1 | .\" |
2 | .\" Copyright (c) 1988-1997 Sam Leffler | |
3 | .\" Copyright (c) 1991-1997 Silicon Graphics, Inc. | |
4 | .\" | |
5 | .\" Permission to use, copy, modify, distribute, and sell this software and | |
6 | .\" its documentation for any purpose is hereby granted without fee, provided | |
7 | .\" that (i) the above copyright notices and this permission notice appear in | |
8 | .\" all copies of the software and related documentation, and (ii) the names of | |
9 | .\" Sam Leffler and Silicon Graphics may not be used in any advertising or | |
10 | .\" publicity relating to the software without the specific, prior written | |
11 | .\" permission of Sam Leffler and Silicon Graphics. | |
12 | .\" | |
13 | .\" THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, | |
14 | .\" EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY | |
15 | .\" WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
16 | .\" | |
17 | .\" IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR | |
18 | .\" ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, | |
19 | .\" OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, | |
20 | .\" WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF | |
21 | .\" LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE | |
22 | .\" OF THIS SOFTWARE. | |
23 | .\" | |
24 | .if n .po 0 | |
25 | .TH TIFFOpen 3TIFF "July 1, 2005" "libtiff" | |
26 | .SH NAME | |
27 | TIFFOpen, TIFFFdOpen, TIFFClientOpen \- open a | |
28 | .SM TIFF | |
29 | file for reading or writing | |
30 | .SH SYNOPSIS | |
31 | .B "#include <tiffio.h>" | |
32 | .sp | |
33 | .BI "TIFF* TIFFOpen(const char *" filename ", const char *" mode ")" | |
34 | .br | |
35 | .BI "TIFF* TIFFFdOpen(const int " fd ", const char *" filename ", const char *" mode ")" | |
36 | .sp | |
37 | .B "typedef tsize_t (*TIFFReadWriteProc)(thandle_t, tdata_t, tsize_t);" | |
38 | .br | |
39 | .B "typedef toff_t (*TIFFSeekProc)(thandle_t, toff_t, int);" | |
40 | .br | |
41 | .B "typedef int (*TIFFCloseProc)(thandle_t);" | |
42 | .br | |
43 | .B "typedef toff_t (*TIFFSizeProc)(thandle_t);" | |
44 | .br | |
45 | .B "typedef int (*TIFFMapFileProc)(thandle_t, tdata_t*, toff_t*);" | |
46 | .br | |
47 | .B "typedef void (*TIFFUnmapFileProc)(thandle_t, tdata_t, toff_t);" | |
48 | .sp | |
49 | .BI "TIFF* TIFFClientOpen(const char *" filename ", const char *" mode ", thandle_t " clientdata ", TIFFReadWriteProc " readproc ", TIFFReadWriteProc " writeproc ", TIFFSeekProc " seekproc ", TIFFCloseProc " closeproc ", TIFFSizeProc " sizeproc ", TIFFMapFileProc " mapproc ", TIFFUnmapFileProc " unmapproc ")" | |
50 | .SH DESCRIPTION | |
51 | .IR TIFFOpen | |
52 | opens a | |
53 | .SM TIFF | |
54 | file whose name is | |
55 | .I filename | |
56 | and returns a handle to be used in subsequent calls to routines in | |
57 | .IR libtiff . | |
58 | If the open operation fails, then zero is returned. | |
59 | The | |
60 | .I mode | |
61 | parameter specifies if the file is to be opened for reading (``r''), | |
62 | writing (``w''), or appending (``a'') and, optionally, whether | |
63 | to override certain default aspects of library operation (see below). | |
64 | When a file is opened for appending, existing data will not | |
65 | be touched; instead new data will be written as additional subfiles. | |
66 | If an existing file is opened for writing, all previous data is | |
67 | overwritten. | |
68 | .PP | |
69 | If a file is opened for reading, the first | |
70 | .SM TIFF | |
71 | directory in the file is automatically read | |
72 | (also see | |
73 | .IR TIFFSetDirectory (3TIFF) | |
74 | for reading directories other than the first). | |
75 | If a file is opened for writing or appending, a default directory | |
76 | is automatically created for writing subsequent data. | |
77 | This directory has all the default values specified in | |
78 | .SM TIFF | |
79 | Revision 6.0: | |
80 | .IR BitsPerSample =1, | |
81 | .IR ThreshHolding "=bilevel art scan," | |
82 | .IR FillOrder =1 | |
83 | (most significant bit of each data byte is filled first), | |
84 | .IR Orientation =1 | |
85 | (the 0th row represents the visual top of the image, and the 0th | |
86 | column represents the visual left hand side), | |
87 | .IR SamplesPerPixel =1, | |
88 | .IR RowsPerStrip =infinity, | |
89 | .IR ResolutionUnit =2 | |
90 | (inches), and | |
91 | .IR Compression =1 | |
92 | (no compression). | |
93 | To alter these values, or to define values for additional fields, | |
94 | .IR TIFFSetField (3TIFF) | |
95 | must be used. | |
96 | .PP | |
97 | .IR TIFFFdOpen | |
98 | is like | |
99 | .IR TIFFOpen | |
100 | except that it opens a | |
101 | .SM TIFF | |
102 | file given an open file descriptor | |
103 | .IR fd . | |
104 | The file's name and mode must reflect that of the open descriptor. | |
105 | The object associated with the file descriptor | |
106 | .BR "must support random access" . | |
107 | .PP | |
108 | .IR TIFFClientOpen | |
109 | is like | |
110 | .IR TIFFOpen | |
111 | except that the caller supplies a collection of functions that the | |
112 | library will use to do \s-1UNIX\s+1-like I/O operations. | |
113 | The | |
114 | .I readproc | |
115 | and | |
116 | .I writeproc | |
117 | are called to read and write data at the current file position. | |
118 | .I seekproc | |
119 | is called to change the current file position a la | |
120 | .IR lseek (2). | |
121 | .I closeproc | |
122 | is invoked to release any resources associated with an open file. | |
123 | .I sizeproc | |
124 | is invoked to obtain the size in bytes of a file. | |
125 | .I mapproc | |
126 | and | |
127 | .I unmapproc | |
128 | are called to map and unmap a file's contents in memory; c.f. | |
129 | .IR mmap (2) | |
130 | and | |
131 | .IR munmap (2). | |
132 | The | |
133 | .I clientdata | |
134 | parameter is an opaque ``handle'' passed to the client-specified | |
135 | routines passed as parameters to | |
136 | .IR TIFFClientOpen . | |
137 | .SH OPTIONS | |
138 | The open mode parameter can include the following flags in | |
139 | addition to the ``r'', ``w'', and ``a'' flags. | |
140 | Note however that option flags must follow the read-write-append | |
141 | specification. | |
142 | .TP | |
143 | .B l | |
144 | When creating a new file force information be written with | |
145 | Little-Endian byte order (but see below). | |
146 | By default the library will create new files using the native | |
147 | .SM CPU | |
148 | byte order. | |
149 | .TP | |
150 | .B b | |
151 | When creating a new file force information be written with | |
152 | Big-Endian byte order (but see below). | |
153 | By default the library will create new files using the native | |
154 | .SM CPU | |
155 | byte order. | |
156 | .TP | |
157 | .B L | |
158 | Force image data that is read or written to be treated with | |
159 | bits filled from Least Significant Bit (\s-1LSB\s+1) to | |
160 | Most Significant Bit (\s-1MSB\s+1). | |
161 | Note that this is the opposite to the way the library has | |
162 | worked from its inception. | |
163 | .TP | |
164 | .B B | |
165 | Force image data that is read or written to be treated with | |
166 | bits filled from Most Significant Bit (\s-1MSB\s+1) to | |
167 | Least Significant Bit (\s-1LSB\s+1); this is the default. | |
168 | .TP | |
169 | .B H | |
170 | Force image data that is read or written to be treated with | |
171 | bits filled in the same order as the native | |
172 | .SM CPU. | |
173 | .TP | |
174 | .B M | |
175 | Enable the use of memory-mapped files for images opened read-only. | |
176 | If the underlying system does not support memory-mapped files | |
177 | or if the specific image being opened cannot be memory-mapped | |
178 | then the library will fallback to using the normal system interface | |
179 | for reading information. | |
180 | By default the library will attempt to use memory-mapped files. | |
181 | .TP | |
182 | .B m | |
183 | Disable the use of memory-mapped files. | |
184 | .TP | |
185 | .B C | |
186 | Enable the use of ``strip chopping'' when reading images | |
187 | that are comprised of a single strip or tile of uncompressed data. | |
188 | Strip chopping is a mechanism by which the library will automatically | |
189 | convert the single-strip image to multiple strips, | |
190 | each of which has about 8 Kilobytes of data. | |
191 | This facility can be useful in reducing the amount of memory used | |
192 | to read an image because the library normally reads each strip | |
193 | in its entirety. | |
194 | Strip chopping does however alter the apparent contents of the | |
195 | image because when an image is divided into multiple strips it | |
196 | looks as though the underlying file contains multiple separate | |
197 | strips. | |
198 | Finally, note that default handling of strip chopping is a compile-time | |
199 | configuration parameter. | |
200 | The default behaviour, for backwards compatibility, is to enable | |
201 | strip chopping. | |
202 | .TP | |
203 | .B c | |
204 | Disable the use of strip chopping when reading images. | |
205 | .TP | |
206 | .B h | |
207 | Read TIFF header only, do not load the first image directory. That could be | |
208 | useful in case of the broken first directory. We can open the file and proceed | |
209 | to the other directories. | |
210 | .SH "BYTE ORDER" | |
211 | The | |
212 | .SM TIFF | |
213 | specification (\fBall versions\fP) states that compliant readers | |
214 | .IR "must be capable of reading images written in either byte order" . | |
215 | Nonetheless some software that claims to support the reading of | |
216 | .SM TIFF | |
217 | images is incapable of reading images in anything but the native | |
218 | .SM CPU | |
219 | byte order on which the software was written. | |
220 | (Especially notorious | |
221 | are applications written to run on Intel-based machines.) | |
222 | By default the library will create new files with the native | |
223 | byte-order of the | |
224 | .SM CPU | |
225 | on which the application is run. | |
226 | This ensures optimal performance and is portable to any application | |
227 | that conforms to the TIFF specification. | |
228 | To force the library to use a specific byte-order when creating | |
229 | a new file the ``b'' and ``l'' option flags may be included in | |
230 | the call to open a file; for example, ``wb'' or ``wl''. | |
231 | .SH "RETURN VALUES" | |
232 | Upon successful completion | |
233 | .IR TIFFOpen , | |
234 | .IR TIFFFdOpen , | |
235 | and | |
236 | .IR TIFFClientOpen | |
237 | return a | |
238 | .SM TIFF | |
239 | pointer. | |
240 | Otherwise, NULL is returned. | |
241 | .SH DIAGNOSTICS | |
242 | All error messages are directed to the | |
243 | .IR TIFFError (3TIFF) | |
244 | routine. | |
245 | Likewise, warning messages are directed to the | |
246 | .IR TIFFWarning (3TIFF) | |
247 | routine. | |
248 | .PP | |
249 | \fB"%s": Bad mode\fP. | |
250 | The specified | |
251 | .I mode | |
252 | parameter was not one of ``r'' (read), ``w'' (write), or ``a'' (append). | |
253 | .PP | |
254 | .BR "%s: Cannot open" . | |
255 | .IR TIFFOpen () | |
256 | was unable to open the specified filename for read/writing. | |
257 | .PP | |
258 | .BR "Cannot read TIFF header" . | |
259 | An error occurred while attempting to read the header information. | |
260 | .PP | |
261 | .BR "Error writing TIFF header" . | |
262 | An error occurred while writing the default header information | |
263 | for a new file. | |
264 | .PP | |
265 | .BR "Not a TIFF file, bad magic number %d (0x%x)" . | |
266 | The magic number in the header was not (hex) | |
267 | 0x4d4d or (hex) 0x4949. | |
268 | .PP | |
269 | .BR "Not a TIFF file, bad version number %d (0x%x)" . | |
270 | The version field in the header was not 42 (decimal). | |
271 | .PP | |
272 | .BR "Cannot append to file that has opposite byte ordering" . | |
273 | A file with a byte ordering opposite to the native byte | |
274 | ordering of the current machine was opened for appending (``a''). | |
275 | This is a limitation of the library. | |
276 | .SH "SEE ALSO" | |
277 | .IR libtiff (3TIFF), | |
278 | .IR TIFFClose (3TIFF) |