]> git.saurik.com Git - wxWidgets.git/blame_incremental - src/tiff/man/TIFFOpen.3tiff
wxMessageBox off the main thread lost result code.
[wxWidgets.git] / src / tiff / man / TIFFOpen.3tiff
... / ...
CommitLineData
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
27TIFFOpen, TIFFFdOpen, TIFFClientOpen \- open a
28.SM TIFF
29file 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
52opens a
53.SM TIFF
54file whose name is
55.I filename
56and returns a handle to be used in subsequent calls to routines in
57.IR libtiff .
58If the open operation fails, then zero is returned.
59The
60.I mode
61parameter specifies if the file is to be opened for reading (``r''),
62writing (``w''), or appending (``a'') and, optionally, whether
63to override certain default aspects of library operation (see below).
64When a file is opened for appending, existing data will not
65be touched; instead new data will be written as additional subfiles.
66If an existing file is opened for writing, all previous data is
67overwritten.
68.PP
69If a file is opened for reading, the first
70.SM TIFF
71directory in the file is automatically read
72(also see
73.IR TIFFSetDirectory (3TIFF)
74for reading directories other than the first).
75If a file is opened for writing or appending, a default directory
76is automatically created for writing subsequent data.
77This directory has all the default values specified in
78.SM TIFF
79Revision 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
86column 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).
93To alter these values, or to define values for additional fields,
94.IR TIFFSetField (3TIFF)
95must be used.
96.PP
97.IR TIFFFdOpen
98is like
99.IR TIFFOpen
100except that it opens a
101.SM TIFF
102file given an open file descriptor
103.IR fd .
104The file's name and mode must reflect that of the open descriptor.
105The object associated with the file descriptor
106.BR "must support random access" .
107.PP
108.IR TIFFClientOpen
109is like
110.IR TIFFOpen
111except that the caller supplies a collection of functions that the
112library will use to do \s-1UNIX\s+1-like I/O operations.
113The
114.I readproc
115and
116.I writeproc
117are called to read and write data at the current file position.
118.I seekproc
119is called to change the current file position a la
120.IR lseek (2).
121.I closeproc
122is invoked to release any resources associated with an open file.
123.I sizeproc
124is invoked to obtain the size in bytes of a file.
125.I mapproc
126and
127.I unmapproc
128are called to map and unmap a file's contents in memory; c.f.
129.IR mmap (2)
130and
131.IR munmap (2).
132The
133.I clientdata
134parameter is an opaque ``handle'' passed to the client-specified
135routines passed as parameters to
136.IR TIFFClientOpen .
137.SH OPTIONS
138The open mode parameter can include the following flags in
139addition to the ``r'', ``w'', and ``a'' flags.
140Note however that option flags must follow the read-write-append
141specification.
142.TP
143.B l
144When creating a new file force information be written with
145Little-Endian byte order (but see below).
146By default the library will create new files using the native
147.SM CPU
148byte order.
149.TP
150.B b
151When creating a new file force information be written with
152Big-Endian byte order (but see below).
153By default the library will create new files using the native
154.SM CPU
155byte order.
156.TP
157.B L
158Force image data that is read or written to be treated with
159bits filled from Least Significant Bit (\s-1LSB\s+1) to
160Most Significant Bit (\s-1MSB\s+1).
161Note that this is the opposite to the way the library has
162worked from its inception.
163.TP
164.B B
165Force image data that is read or written to be treated with
166bits filled from Most Significant Bit (\s-1MSB\s+1) to
167Least Significant Bit (\s-1LSB\s+1); this is the default.
168.TP
169.B H
170Force image data that is read or written to be treated with
171bits filled in the same order as the native
172.SM CPU.
173.TP
174.B M
175Enable the use of memory-mapped files for images opened read-only.
176If the underlying system does not support memory-mapped files
177or if the specific image being opened cannot be memory-mapped
178then the library will fallback to using the normal system interface
179for reading information.
180By default the library will attempt to use memory-mapped files.
181.TP
182.B m
183Disable the use of memory-mapped files.
184.TP
185.B C
186Enable the use of ``strip chopping'' when reading images
187that are comprised of a single strip or tile of uncompressed data.
188Strip chopping is a mechanism by which the library will automatically
189convert the single-strip image to multiple strips,
190each of which has about 8 Kilobytes of data.
191This facility can be useful in reducing the amount of memory used
192to read an image because the library normally reads each strip
193in its entirety.
194Strip chopping does however alter the apparent contents of the
195image because when an image is divided into multiple strips it
196looks as though the underlying file contains multiple separate
197strips.
198Finally, note that default handling of strip chopping is a compile-time
199configuration parameter.
200The default behaviour, for backwards compatibility, is to enable
201strip chopping.
202.TP
203.B c
204Disable the use of strip chopping when reading images.
205.TP
206.B h
207Read TIFF header only, do not load the first image directory. That could be
208useful in case of the broken first directory. We can open the file and proceed
209to the other directories.
210.SH "BYTE ORDER"
211The
212.SM TIFF
213specification (\fBall versions\fP) states that compliant readers
214.IR "must be capable of reading images written in either byte order" .
215Nonetheless some software that claims to support the reading of
216.SM TIFF
217images is incapable of reading images in anything but the native
218.SM CPU
219byte order on which the software was written.
220(Especially notorious
221are applications written to run on Intel-based machines.)
222By default the library will create new files with the native
223byte-order of the
224.SM CPU
225on which the application is run.
226This ensures optimal performance and is portable to any application
227that conforms to the TIFF specification.
228To force the library to use a specific byte-order when creating
229a new file the ``b'' and ``l'' option flags may be included in
230the call to open a file; for example, ``wb'' or ``wl''.
231.SH "RETURN VALUES"
232Upon successful completion
233.IR TIFFOpen ,
234.IR TIFFFdOpen ,
235and
236.IR TIFFClientOpen
237return a
238.SM TIFF
239pointer.
240Otherwise, NULL is returned.
241.SH DIAGNOSTICS
242All error messages are directed to the
243.IR TIFFError (3TIFF)
244routine.
245Likewise, warning messages are directed to the
246.IR TIFFWarning (3TIFF)
247routine.
248.PP
249\fB"%s": Bad mode\fP.
250The specified
251.I mode
252parameter was not one of ``r'' (read), ``w'' (write), or ``a'' (append).
253.PP
254.BR "%s: Cannot open" .
255.IR TIFFOpen ()
256was unable to open the specified filename for read/writing.
257.PP
258.BR "Cannot read TIFF header" .
259An error occurred while attempting to read the header information.
260.PP
261.BR "Error writing TIFF header" .
262An error occurred while writing the default header information
263for a new file.
264.PP
265.BR "Not a TIFF file, bad magic number %d (0x%x)" .
266The magic number in the header was not (hex)
2670x4d4d or (hex) 0x4949.
268.PP
269.BR "Not a TIFF file, bad version number %d (0x%x)" .
270The version field in the header was not 42 (decimal).
271.PP
272.BR "Cannot append to file that has opposite byte ordering" .
273A file with a byte ordering opposite to the native byte
274ordering of the current machine was opened for appending (``a'').
275This is a limitation of the library.
276.SH "SEE ALSO"
277.IR libtiff (3TIFF),
278.IR TIFFClose (3TIFF)