]>
Commit | Line | Data |
---|---|---|
8414a40c VZ |
1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
2 | <html lang="en"> | |
3 | <head> | |
4 | <title>Using The TIFF Library</title> | |
5 | <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> | |
6 | <meta http-equiv="content-language" content="en"> | |
7 | <style type="text/css"> | |
8 | <!-- | |
9 | th {text-align: left; vertical-align: top; font-style: italic; font-weight: normal} | |
10 | --> | |
11 | </style> | |
12 | </head> | |
13 | <body lang="en" text="#000000" bgcolor="#ffffff" link="#0000ff" alink="#0000ff" vlink="#0000ff"> | |
14 | <table border="0" cellspacing="0" cellpadding="0"> | |
15 | <tr> | |
16 | <td style="padding-left: 1em; padding-right: 1em"><img src="images/cat.gif" width="113" height="146" alt=""></td> | |
17 | <td> | |
18 | <h1>Using The TIFF Library</h1> | |
19 | <p> | |
20 | <tt>libtiff</tt> is a set of C functions (a library) that support | |
21 | the manipulation of TIFF image files. | |
22 | The library requires an ANSI C compilation environment for building | |
23 | and presumes an ANSI C environment for use. | |
24 | </p> | |
25 | </td> | |
26 | </tr> | |
27 | </table> | |
28 | <br> | |
29 | <p> | |
30 | <tt>libtiff</tt> | |
31 | provides interfaces to image data at several layers of abstraction (and cost). | |
32 | At the highest level image data can be read into an 8-bit/sample, | |
33 | ABGR pixel raster format without regard for the underlying data organization, | |
34 | colorspace, or compression scheme. Below this high-level interface | |
35 | the library provides scanline-, strip-, and tile-oriented interfaces that | |
36 | return data decompressed but otherwise untransformed. These interfaces | |
37 | require that the application first identify the organization of stored | |
38 | data and select either a strip-based or tile-based API for manipulating | |
39 | data. At the lowest level the library | |
40 | provides access to the raw uncompressed strips or tiles, | |
41 | returning the data exactly as it appears in the file. | |
42 | </p> | |
43 | <p> | |
44 | The material presented in this chapter is a basic introduction | |
45 | to the capabilities of the library; it is not an attempt to describe | |
46 | everything a developer needs to know about the library or about TIFF. | |
47 | Detailed information on the interfaces to the library are given in | |
48 | the <a href="http://www.remotesensing.org/libtiff/man/index.html">UNIX | |
49 | manual pages</a> that accompany this software. | |
50 | </p> | |
51 | <p> | |
52 | Michael Still has also written a useful introduction to libtiff for the | |
53 | IBM DeveloperWorks site available at | |
54 | <a href="http://www.ibm.com/developerworks/linux/library/l-libtiff">http://www.ibm.com/developerworks/linux/library/l-libtiff</a>. | |
55 | </p> | |
56 | <p> | |
57 | The following sections are found in this chapter: | |
58 | </p> | |
59 | <ul> | |
60 | <li><a href="#version">How to tell which version you have</a></li> | |
61 | <li><a href="#typedefs">Library Datatypes</a></li> | |
62 | <li><a href="#mman">Memory Management</a></li> | |
63 | <li><a href="#errors">Error Handling</a></li> | |
64 | <li><a href="#fio">Basic File Handling</a></li> | |
65 | <li><a href="#dirs">TIFF Directories</a></li> | |
66 | <li><a href="#tags">TIFF Tags</a></li> | |
67 | <li><a href="#compression">TIFF Compression Schemes</a></li> | |
68 | <li><a href="#byteorder">Byte Order</a></li> | |
69 | <li><a href="#dataplacement">Data Placement</a></li> | |
70 | <li><a href="#tiffrgbaimage">TIFFRGBAImage Support</a></li> | |
71 | <li><a href="#scanlines">Scanline-based Image I/O</a></li> | |
72 | <li><a href="#strips">Strip-oriented Image I/O</a></li> | |
73 | <li><a href="#tiles">Tile-oriented Image I/O</a></li> | |
74 | <li><a href="#other">Other Stuff</a></li> | |
75 | </ul> | |
76 | <hr> | |
77 | <h2 id="version">How to tell which version you have</h2> | |
78 | <p> | |
79 | The software version can be found by looking at the file named | |
80 | <tt>VERSION</tt> | |
81 | that is located at the top of the source tree; the precise alpha number | |
82 | is given in the file <tt>dist/tiff.alpha</tt>. | |
83 | If you have need to refer to this | |
84 | specific software, you should identify it as: | |
85 | </p> | |
86 | <p style="margin-left: 40px"> | |
87 | <tt>TIFF <<i>version</i>> <<i>alpha</i>></tt> | |
88 | </p> | |
89 | <p> | |
90 | where <tt><<i>version</i>></tt> is whatever you get from | |
91 | <tt>"cat VERSION"</tt> and <tt><<i>alpha</i>></tt> is | |
92 | what you get from <tt>"cat dist/tiff.alpha"</tt>. | |
93 | </p> | |
94 | <p> | |
95 | Within an application that uses <tt>libtiff</tt> the <tt>TIFFGetVersion</tt> | |
96 | routine will return a pointer to a string that contains software version | |
97 | information. | |
98 | The library include file <tt><tiffio.h></tt> contains a C pre-processor | |
99 | define <tt>TIFFLIB_VERSION</tt> that can be used to check library | |
100 | version compatiblity at compile time. | |
101 | </p> | |
102 | <hr> | |
103 | <h2 id="typedefs">Library Datatypes</h2> | |
104 | <p> | |
105 | <tt>libtiff</tt> defines a portable programming interface through the | |
106 | use of a set of C type definitions. | |
107 | These definitions, defined in in the files <b>tiff.h</b> and | |
108 | <b>tiffio.h</b>, | |
109 | isolate the <tt>libtiff</tt> API from the characteristics | |
110 | of the underlying machine. | |
111 | To insure portable code and correct operation, applications that use | |
112 | <tt>libtiff</tt> should use the typedefs and follow the function | |
113 | prototypes for the library API. | |
114 | </p> | |
115 | <hr> | |
116 | <h2 id="mman">Memory Management</h2> | |
117 | <p> | |
118 | <tt>libtiff</tt> uses a machine-specific set of routines for managing | |
119 | dynamically allocated memory. | |
120 | <tt>_TIFFmalloc</tt>, <tt>_TIFFrealloc</tt>, and <tt>_TIFFfree</tt> | |
121 | mimic the normal ANSI C routines. | |
122 | Any dynamically allocated memory that is to be passed into the library | |
123 | should be allocated using these interfaces in order to insure pointer | |
124 | compatibility on machines with a segmented architecture. | |
125 | (On 32-bit UNIX systems these routines just call the normal <tt>malloc</tt>, | |
126 | <tt>realloc</tt>, and <tt>free</tt> routines in the C library.) | |
127 | </p> | |
128 | <p> | |
129 | To deal with segmented pointer issues <tt>libtiff</tt> also provides | |
130 | <tt>_TIFFmemcpy</tt>, <tt>_TIFFmemset</tt>, and <tt>_TIFFmemmove</tt> | |
131 | routines that mimic the equivalent ANSI C routines, but that are | |
132 | intended for use with memory allocated through <tt>_TIFFmalloc</tt> | |
133 | and <tt>_TIFFrealloc</tt>. | |
134 | </p> | |
135 | <hr> | |
136 | <h2 id="errors">Error Handling</h2> | |
137 | <p> | |
138 | <tt>libtiff</tt> handles most errors by returning an invalid/erroneous | |
139 | value when returning from a function call. | |
140 | Various diagnostic messages may also be generated by the library. | |
141 | All error messages are directed to a single global error handler | |
142 | routine that can be specified with a call to <tt>TIFFSetErrorHandler</tt>. | |
143 | Likewise warning messages are directed to a single handler routine | |
144 | that can be specified with a call to <tt>TIFFSetWarningHandler</tt> | |
145 | </p> | |
146 | <hr> | |
147 | <h2 id="fio">Basic File Handling</h2> | |
148 | <p> | |
149 | The library is modeled after the normal UNIX stdio library. | |
150 | For example, to read from an existing TIFF image the | |
151 | file must first be opened: | |
152 | </p> | |
153 | <p style="margin-left: 40px"> | |
154 | <tt>#include "tiffio.h"<br> | |
155 | main()<br> | |
156 | {<br> | |
157 | TIFF* tif = TIFFOpen("foo.tif", "r");<br> | |
158 | ... do stuff ...<br> | |
159 | TIFFClose(tif);<br> | |
160 | }</tt> | |
161 | </p> | |
162 | <p> | |
163 | The handle returned by <tt>TIFFOpen</tt> is <i>opaque</i>, that is | |
164 | the application is not permitted to know about its contents. | |
165 | All subsequent library calls for this file must pass the handle | |
166 | as an argument. | |
167 | </p> | |
168 | <p> | |
169 | To create or overwrite a TIFF image the file is also opened, but with | |
170 | a <tt>"w"</tt> argument: | |
171 | <p> | |
172 | <p style="margin-left: 40px"> | |
173 | <tt>#include "tiffio.h"<br> | |
174 | main()<br> | |
175 | {<br> | |
176 | TIFF* tif = TIFFOpen("foo.tif", "w");<br> | |
177 | ... do stuff ...<br> | |
178 | TIFFClose(tif);<br> | |
179 | }</tt> | |
180 | </p> | |
181 | <p> | |
182 | If the file already exists it is first truncated to zero length. | |
183 | </p> | |
184 | <table> | |
185 | <tr> | |
186 | <td valign=top><img src="images/warning.gif" width="40" height="40" alt=""></td> | |
187 | <td><i>Note that unlike the stdio library TIFF image files may not be | |
188 | opened for both reading and writing; | |
189 | there is no support for altering the contents of a TIFF file.</i></td> | |
190 | </tr> | |
191 | </table> | |
192 | <p> | |
193 | <tt>libtiff</tt> buffers much information associated with writing a | |
194 | valid TIFF image. Consequently, when writing a TIFF image it is necessary | |
195 | to always call <tt>TIFFClose</tt> or <tt>TIFFFlush</tt> to flush any | |
196 | buffered information to a file. Note that if you call <tt>TIFFClose</tt> | |
197 | you do not need to call <tt>TIFFFlush</tt>. | |
198 | </p> | |
199 | <hr> | |
200 | <h2 id="dirs">TIFF Directories</h2> | |
201 | <p> | |
202 | TIFF supports the storage of multiple images in a single file. | |
203 | Each image has an associated data structure termed a <i>directory</i> | |
204 | that houses all the information about the format and content of the | |
205 | image data. | |
206 | Images in a file are usually related but they do not need to be; it | |
207 | is perfectly alright to store a color image together with a black and | |
208 | white image. | |
209 | Note however that while images may be related their directories are | |
210 | not. | |
211 | That is, each directory stands on its own; their is no need to read | |
212 | an unrelated directory in order to properly interpret the contents | |
213 | of an image. | |
214 | </p> | |
215 | <p> | |
216 | <tt>libtiff</tt> provides several routines for reading and writing | |
217 | directories. In normal use there is no need to explicitly | |
218 | read or write a directory: the library automatically reads the first | |
219 | directory in a file when opened for reading, and directory information | |
220 | to be written is automatically accumulated and written when writing | |
221 | (assuming <tt>TIFFClose</tt> or <tt>TIFFFlush</tt> are called). | |
222 | </p> | |
223 | <p> | |
224 | For a file open for reading the <tt>TIFFSetDirectory</tt> routine can | |
225 | be used to select an arbitrary directory; directories are referenced by | |
226 | number with the numbering starting at 0. Otherwise the | |
227 | <tt>TIFFReadDirectory</tt> and <tt>TIFFWriteDirectory</tt> routines can | |
228 | be used for sequential access to directories. | |
229 | For example, to count the number of directories in a file the following | |
230 | code might be used: | |
231 | </p> | |
232 | <p style="margin-left: 40px"> | |
233 | <tt>#include "tiffio.h"<br> | |
234 | main(int argc, char* argv[])<br> | |
235 | {<br> | |
236 | TIFF* tif = TIFFOpen(argv[1], "r");<br> | |
237 | if (tif) {<br> | |
238 | int dircount = 0;<br> | |
239 | do {<br> | |
240 | dircount++;<br> | |
241 | } while (TIFFReadDirectory(tif));<br> | |
242 | printf("%d directories in %s\n", dircount, argv[1]);<br> | |
243 | TIFFClose(tif);<br> | |
244 | }<br> | |
245 | exit(0);<br> | |
246 | }</tt> | |
247 | </p> | |
248 | <p> | |
249 | Finally, note that there are several routines for querying the | |
250 | directory status of an open file: | |
251 | <tt>TIFFCurrentDirectory</tt> returns the index of the current | |
252 | directory and | |
253 | <tt>TIFFLastDirectory</tt> returns an indication of whether the | |
254 | current directory is the last directory in a file. | |
255 | There is also a routine, <tt>TIFFPrintDirectory</tt>, that can | |
256 | be called to print a formatted description of the contents of | |
257 | the current directory; consult the manual page for complete details. | |
258 | </p> | |
259 | <hr> | |
260 | <h2 id="tags">TIFF Tags</h2> | |
261 | <p> | |
262 | Image-related information such as the image width and height, number | |
263 | of samples, orientation, colorimetric information, etc. | |
264 | are stored in each image | |
265 | directory in <i>fields</i> or <i>tags</i>. | |
266 | Tags are identified by a number that is usually a value registered | |
267 | with the Aldus (now Adobe) Corporation. | |
268 | Beware however that some vendors write | |
269 | TIFF images with tags that are unregistered; in this case interpreting | |
270 | their contents is usually a waste of time. | |
271 | </p> | |
272 | <p> | |
273 | <tt>libtiff</tt> reads the contents of a directory all at once | |
274 | and converts the on-disk information to an appropriate in-memory | |
275 | form. While the TIFF specification permits an arbitrary set of | |
276 | tags to be defined and used in a file, the library only understands | |
277 | a limited set of tags. | |
278 | Any unknown tags that are encountered in a file are ignored. | |
279 | There is a mechanism to extend the set of tags the library handles | |
280 | without modifying the library itself; | |
281 | this is described <a href="addingtags.html">elsewhere</a>. | |
282 | </p> | |
283 | <p> | |
284 | <tt>libtiff</tt> provides two interfaces for getting and setting tag | |
285 | values: <tt>TIFFGetField</tt> and <tt>TIFFSetField</tt>. | |
286 | These routines use a variable argument list-style interface to pass | |
287 | parameters of different type through a single function interface. | |
288 | The <i>get interface</i> takes one or more pointers to memory locations | |
289 | where the tag values are to be returned and also returns one or | |
290 | zero according to whether the requested tag is defined in the directory. | |
291 | The <i>set interface</i> takes the tag values either by-reference or | |
292 | by-value. | |
293 | The TIFF specification defines | |
294 | <i>default values</i> for some tags. | |
295 | To get the value of a tag, or its default value if it is undefined, | |
296 | the <tt>TIFFGetFieldDefaulted</tt> interface may be used. | |
297 | </p> | |
298 | <p> | |
299 | The manual pages for the tag get and set routines specifiy the exact data types | |
300 | and calling conventions required for each tag supported by the library. | |
301 | </p> | |
302 | <hr> | |
303 | <h2 id="compression">TIFF Compression Schemes</h2> | |
304 | <p> | |
305 | <tt>libtiff</tt> includes support for a wide variety of | |
306 | data compression schemes. | |
307 | In normal operation a compression scheme is automatically used when | |
308 | the TIFF <tt>Compression</tt> tag is set, either by opening a file | |
309 | for reading, or by setting the tag when writing. | |
310 | </p> | |
311 | <p> | |
312 | Compression schemes are implemented by software modules termed <i>codecs</i> | |
313 | that implement decoder and encoder routines that hook into the | |
314 | core library i/o support. | |
315 | Codecs other than those bundled with the library can be registered | |
316 | for use with the <tt>TIFFRegisterCODEC</tt> routine. | |
317 | This interface can also be used to override the core-library | |
318 | implementation for a compression scheme. | |
319 | </p> | |
320 | <hr> | |
321 | <h2 id="byteorder">Byte Order</h2> | |
322 | <p> | |
323 | The TIFF specification says, and has always said, that | |
324 | <em>a correct TIFF | |
325 | reader must handle images in big-endian and little-endian byte order</em>. | |
326 | <tt>libtiff</tt> conforms in this respect. | |
327 | Consequently there is no means to force a specific | |
328 | byte order for the data written to a TIFF image file (data is | |
329 | written in the native order of the host CPU unless appending to | |
330 | an existing file, in which case it is written in the byte order | |
331 | specified in the file). | |
332 | </p> | |
333 | <hr> | |
334 | <h2 id="dataplacement">Data Placement</h2> | |
335 | <p> | |
336 | The TIFF specification requires that all information except an | |
337 | 8-byte header can be placed anywhere in a file. | |
338 | In particular, it is perfectly legitimate for directory information | |
339 | to be written after the image data itself. | |
340 | Consequently TIFF is inherently not suitable for passing through a | |
341 | stream-oriented mechanism such as UNIX pipes. | |
342 | Software that require that data be organized in a file in a particular | |
343 | order (e.g. directory information before image data) does not | |
344 | correctly support TIFF. | |
345 | <tt>libtiff</tt> provides no mechanism for controlling the placement | |
346 | of data in a file; image data is typically written before directory | |
347 | information. | |
348 | </p> | |
349 | <hr> | |
350 | <h2 id="tiffrgbaimage">TIFFRGBAImage Support</h2> | |
351 | <p> | |
352 | <tt>libtiff</tt> provides a high-level interface for reading image | |
353 | data from a TIFF file. This interface handles the details of | |
354 | data organization and format for a wide variety of TIFF files; | |
355 | at least the large majority of those files that one would normally | |
356 | encounter. Image data is, by default, returned as ABGR | |
357 | pixels packed into 32-bit words (8 bits per sample). Rectangular | |
358 | rasters can be read or data can be intercepted at an intermediate | |
359 | level and packed into memory in a format more suitable to the | |
360 | application. | |
361 | The library handles all the details of the format of data stored on | |
362 | disk and, in most cases, if any colorspace conversions are required: | |
363 | bilevel to RGB, greyscale to RGB, CMYK to RGB, YCbCr to RGB, 16-bit | |
364 | samples to 8-bit samples, associated/unassociated alpha, etc. | |
365 | </p> | |
366 | <p> | |
367 | There are two ways to read image data using this interface. If | |
368 | all the data is to be stored in memory and manipulated at once, | |
369 | then the routine <tt>TIFFReadRGBAImage</tt> can be used: | |
370 | </p> | |
371 | <p> | |
372 | <p style="margin-left: 40px"> | |
373 | <tt>#include "tiffio.h"<br> | |
374 | main(int argc, char* argv[])<br> | |
375 | {<br> | |
376 | TIFF* tif = TIFFOpen(argv[1], "r");<br> | |
377 | if (tif) {<br> | |
378 | uint32 w, h;<br> | |
379 | size_t npixels;<br> | |
380 | uint32* raster;<br> | |
381 | <br> | |
382 | TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, &w);<br> | |
383 | TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &h);<br> | |
384 | npixels = w * h;<br> | |
385 | raster = (uint32*) _TIFFmalloc(npixels * sizeof (uint32));<br> | |
386 | if (raster != NULL) {<br> | |
387 | if (TIFFReadRGBAImage(tif, w, h, raster, 0)) {<br> | |
388 | ...process raster data...<br> | |
389 | }<br> | |
390 | _TIFFfree(raster);<br> | |
391 | }<br> | |
392 | TIFFClose(tif);<br> | |
393 | }<br> | |
394 | exit(0);<br> | |
395 | }</tt> | |
396 | </p> | |
397 | <p> | |
398 | Note above that <tt>_TIFFmalloc</tt> is used to allocate memory for | |
399 | the raster passed to <tt>TIFFReadRGBAImage</tt>; this is important | |
400 | to insure the ``appropriate type of memory'' is passed on machines | |
401 | with segmented architectures. | |
402 | </p> | |
403 | <p> | |
404 | Alternatively, <tt>TIFFReadRGBAImage</tt> can be replaced with a | |
405 | more low-level interface that permits an application to have more | |
406 | control over this reading procedure. The equivalent to the above | |
407 | is: | |
408 | </p> | |
409 | <p style="margin-left: 40px"> | |
410 | <tt>#include "tiffio.h"<br> | |
411 | main(int argc, char* argv[])<br> | |
412 | {<br> | |
413 | TIFF* tif = TIFFOpen(argv[1], "r");<br> | |
414 | if (tif) {<br> | |
415 | TIFFRGBAImage img;<br> | |
416 | char emsg[1024];<br> | |
417 | <br> | |
418 | if (TIFFRGBAImageBegin(&img, tif, 0, emsg)) {<br> | |
419 | size_t npixels;<br> | |
420 | uint32* raster;<br> | |
421 | <br> | |
422 | npixels = img.width * img.height;<br> | |
423 | raster = (uint32*) _TIFFmalloc(npixels * sizeof (uint32));<br> | |
424 | if (raster != NULL) {<br> | |
425 | if (TIFFRGBAImageGet(&img, raster, img.width, img.height)) {<br> | |
426 | ...process raster data...<br> | |
427 | }<br> | |
428 | _TIFFfree(raster);<br> | |
429 | }<br> | |
430 | TIFFRGBAImageEnd(&img);<br> | |
431 | } else<br> | |
432 | TIFFError(argv[1], emsg);<br> | |
433 | TIFFClose(tif);<br> | |
434 | }<br> | |
435 | exit(0);<br> | |
436 | }</tt> | |
437 | </p> | |
438 | <p> | |
439 | However this usage does not take advantage of the more fine-grained | |
440 | control that's possible. That is, by using this interface it is | |
441 | possible to: | |
442 | </p> | |
443 | <ul> | |
444 | <li>repeatedly fetch (and manipulate) an image without opening | |
445 | and closing the file</li> | |
446 | <li>interpose a method for packing raster pixel data according to | |
447 | application-specific needs (or write the data at all)</li> | |
448 | <li>interpose methods that handle TIFF formats that are not already | |
449 | handled by the core library</li> | |
450 | </ul> | |
451 | <p> | |
452 | The first item means that, for example, image viewers that want to | |
453 | handle multiple files can cache decoding information in order to | |
454 | speedup the work required to display a TIFF image. | |
455 | </p> | |
456 | <p> | |
457 | The second item is the main reason for this interface. By interposing | |
458 | a "put method" (the routine that is called to pack pixel data in | |
459 | the raster) it is possible share the core logic that understands how | |
460 | to deal with TIFF while packing the resultant pixels in a format that | |
461 | is optimized for the application. This alternate format might be very | |
462 | different than the 8-bit per sample ABGR format the library writes by | |
463 | default. For example, if the application is going to display the image | |
464 | on an 8-bit colormap display the put routine might take the data and | |
465 | convert it on-the-fly to the best colormap indices for display. | |
466 | </p> | |
467 | <p> | |
468 | The last item permits an application to extend the library | |
469 | without modifying the core code. | |
470 | By overriding the code provided an application might add support | |
471 | for some esoteric flavor of TIFF that it needs, or it might | |
472 | substitute a packing routine that is able to do optimizations | |
473 | using application/environment-specific information. | |
474 | </p> | |
475 | <p> | |
476 | The TIFF image viewer found in <b>tools/sgigt.c</b> is an example | |
477 | of an application that makes use of the <tt>TIFFRGBAImage</tt> | |
478 | support. | |
479 | </p> | |
480 | <hr> | |
481 | <h2 id="scanlines">Scanline-based Image I/O</h2> | |
482 | <p> | |
483 | The simplest interface provided by <tt>libtiff</tt> is a | |
484 | scanline-oriented interface that can be used to read TIFF | |
485 | images that have their image data organized in strips | |
486 | (trying to use this interface to read data written in tiles | |
487 | will produce errors.) | |
488 | A scanline is a one pixel high row of image data whose width | |
489 | is the width of the image. | |
490 | Data is returned packed if the image data is stored with samples | |
491 | packed together, or as arrays of separate samples if the data | |
492 | is stored with samples separated. | |
493 | The major limitation of the scanline-oriented interface, other | |
494 | than the need to first identify an existing file as having a | |
495 | suitable organization, is that random access to individual | |
496 | scanlines can only be provided when data is not stored in a | |
497 | compressed format, or when the number of rows in a strip | |
498 | of image data is set to one (<tt>RowsPerStrip</tt> is one). | |
499 | </p> | |
500 | <p> | |
501 | Two routines are provided for scanline-based i/o: | |
502 | <tt>TIFFReadScanline</tt> | |
503 | and | |
504 | <tt>TIFFWriteScanline</tt>. | |
505 | For example, to read the contents of a file that | |
506 | is assumed to be organized in strips, the following might be used: | |
507 | </p> | |
508 | <p style="margin-left: 40px"> | |
509 | <tt>#include "tiffio.h"<br> | |
510 | main()<br> | |
511 | {<br> | |
512 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
513 | if (tif) {<br> | |
514 | uint32 imagelength;<br> | |
515 | tdata_t buf;<br> | |
516 | uint32 row;<br> | |
517 | <br> | |
518 | TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &imagelength);<br> | |
519 | buf = _TIFFmalloc(TIFFScanlineSize(tif));<br> | |
520 | for (row = 0; row < imagelength; row++)<br> | |
521 | tiffreadscanline(tif, buf, row);<br> | |
522 | _tifffree(buf);<br> | |
523 | tiffclose(tif);<br> | |
524 | }<br> | |
525 | }</tt> | |
526 | </p> | |
527 | <p> | |
528 | <tt>TIFFScanlineSize</tt> returns the number of bytes in | |
529 | a decoded scanline, as returned by <tt>TIFFReadScanline</tt>. | |
530 | Note however that if the file had been create with samples | |
531 | written in separate planes, then the above code would only | |
532 | read data that contained the first sample of each pixel; | |
533 | to handle either case one might use the following instead: | |
534 | </p> | |
535 | <p style="margin-left: 40px"> | |
536 | <tt>#include "tiffio.h"<br> | |
537 | main()<br> | |
538 | {<br> | |
539 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
540 | if (tif) {<br> | |
541 | uint32 imagelength;<br> | |
542 | tdata_t buf;<br> | |
543 | uint32 row;<br> | |
544 | <br> | |
545 | TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &imagelength);<br> | |
546 | TIFFGetField(tif, TIFFTAG_PLANARCONFIG, &config);<br> | |
547 | buf = _TIFFmalloc(TIFFScanlineSize(tif));<br> | |
548 | if (config == PLANARCONFIG_CONTIG) {<br> | |
549 | for (row = 0; row < imagelength; row++)<br> | |
550 | tiffreadscanline(tif, buf, row);<br> | |
551 | } else if (config == planarconfig_separate) {<br> | |
552 | uint16 s, nsamples;<br> | |
553 | <br> | |
554 | tiffgetfield(tif, tifftag_samplesperpixel, &nsamples);<br> | |
555 | for (s = 0; s < nsamples; s++)<br> | |
556 | for (row = 0; row < imagelength; row++)<br> | |
557 | tiffreadscanline(tif, buf, row, s);<br> | |
558 | }<br> | |
559 | _tifffree(buf);<br> | |
560 | tiffclose(tif);<br> | |
561 | }<br> | |
562 | }</tt> | |
563 | </p> | |
564 | <p> | |
565 | Beware however that if the following code were used instead to | |
566 | read data in the case <tt>PLANARCONFIG_SEPARATE</tt>,... | |
567 | </p> | |
568 | <p style="margin-left: 40px"> | |
569 | <tt> for (row = 0; row < imagelength; row++)<br> | |
570 | for (s = 0; s < nsamples; s++)<br> | |
571 | tiffreadscanline(tif, buf, row, s);</tt> | |
572 | </p> | |
573 | <p> | |
574 | ...then problems would arise if <tt>RowsPerStrip</tt> was not one | |
575 | because the order in which scanlines are requested would require | |
576 | random access to data within strips (something that is not supported | |
577 | by the library when strips are compressed). | |
578 | </p> | |
579 | <hr> | |
580 | <h2 id="strips">Strip-oriented Image I/O</h2> | |
581 | <p> | |
582 | The strip-oriented interfaces provided by the library provide | |
583 | access to entire strips of data. Unlike the scanline-oriented | |
584 | calls, data can be read or written compressed or uncompressed. | |
585 | Accessing data at a strip (or tile) level is often desirable | |
586 | because there are no complications with regard to random access | |
587 | to data within strips. | |
588 | </p> | |
589 | <p> | |
590 | A simple example of reading an image by strips is: | |
591 | </p> | |
592 | <p style="margin-left: 40px"> | |
593 | <tt>#include "tiffio.h"<br> | |
594 | main()<br> | |
595 | {<br> | |
596 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
597 | if (tif) {<br> | |
598 | tdata_t buf;<br> | |
599 | tstrip_t strip;<br> | |
600 | <br> | |
601 | buf = _TIFFmalloc(TIFFStripSize(tif));<br> | |
602 | for (strip = 0; strip < tiffnumberofstrips(tif); strip++)<br> | |
603 | tiffreadencodedstrip(tif, strip, buf, (tsize_t) -1);<br> | |
604 | _tifffree(buf);<br> | |
605 | tiffclose(tif);<br> | |
606 | }<br> | |
607 | }</tt> | |
608 | </p> | |
609 | <p> | |
610 | Notice how a strip size of <tt>-1</tt> is used; <tt>TIFFReadEncodedStrip</tt> | |
611 | will calculate the appropriate size in this case. | |
612 | </p> | |
613 | <p> | |
614 | The above code reads strips in the order in which the | |
615 | data is physically stored in the file. If multiple samples | |
616 | are present and data is stored with <tt>PLANARCONFIG_SEPARATE</tt> | |
617 | then all the strips of data holding the first sample will be | |
618 | read, followed by strips for the second sample, etc. | |
619 | </p> | |
620 | <p> | |
621 | Finally, note that the last strip of data in an image may have fewer | |
622 | rows in it than specified by the <tt>RowsPerStrip</tt> tag. A | |
623 | reader should not assume that each decoded strip contains a full | |
624 | set of rows in it. | |
625 | </p> | |
626 | <p> | |
627 | The following is an example of how to read raw strips of data from | |
628 | a file: | |
629 | </p> | |
630 | <p style="margin-left: 40px"> | |
631 | <tt>#include "tiffio.h"<br> | |
632 | main()<br> | |
633 | {<br> | |
634 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
635 | if (tif) {<br> | |
636 | tdata_t buf;<br> | |
637 | tstrip_t strip;<br> | |
638 | uint32* bc;<br> | |
639 | uint32 stripsize;<br> | |
640 | <br> | |
641 | TIFFGetField(tif, TIFFTAG_STRIPBYTECOUNTS, &bc);<br> | |
642 | stripsize = bc[0];<br> | |
643 | buf = _TIFFmalloc(stripsize);<br> | |
644 | for (strip = 0; strip < tiffnumberofstrips(tif); strip++) {<br> | |
645 | if (bc[strip] > stripsize) {<br> | |
646 | buf = _TIFFrealloc(buf, bc[strip]);<br> | |
647 | stripsize = bc[strip];<br> | |
648 | }<br> | |
649 | TIFFReadRawStrip(tif, strip, buf, bc[strip]);<br> | |
650 | }<br> | |
651 | _TIFFfree(buf);<br> | |
652 | TIFFClose(tif);<br> | |
653 | }<br> | |
654 | }</tt> | |
655 | </p> | |
656 | <p> | |
657 | As above the strips are read in the order in which they are | |
658 | physically stored in the file; this may be different from the | |
659 | logical ordering expected by an application. | |
660 | </p> | |
661 | <hr> | |
662 | <h2 id="tiles">Tile-oriented Image I/O</h2> | |
663 | <p> | |
664 | Tiles of data may be read and written in a manner similar to strips. | |
665 | With this interface, an image is | |
666 | broken up into a set of rectangular areas that may have dimensions | |
667 | less than the image width and height. All the tiles | |
668 | in an image have the same size, and the tile width and length must each | |
669 | be a multiple of 16 pixels. Tiles are ordered left-to-right and | |
670 | top-to-bottom in an image. As for scanlines, samples can be packed | |
671 | contiguously or separately. When separated, all the tiles for a sample | |
672 | are colocated in the file. That is, all the tiles for sample 0 appear | |
673 | before the tiles for sample 1, etc. | |
674 | </p> | |
675 | <p> | |
676 | Tiles and strips may also be extended in a z dimension to form | |
677 | volumes. Data volumes are organized as "slices". That is, all the | |
678 | data for a slice is colocated. Volumes whose data is organized in | |
679 | tiles can also have a tile depth so that data can be organized in | |
680 | cubes. | |
681 | </p> | |
682 | <p> | |
683 | There are actually two interfaces for tiles. | |
684 | One interface is similar to scanlines, to read a tiled image, | |
685 | code of the following sort might be used: | |
686 | </p> | |
687 | <p style="margin-left: 40px"> | |
688 | <tt>main()<br> | |
689 | {<br> | |
690 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
691 | if (tif) {<br> | |
692 | uint32 imageWidth, imageLength;<br> | |
693 | uint32 tileWidth, tileLength;<br> | |
694 | uint32 x, y;<br> | |
695 | tdata_t buf;<br> | |
696 | <br> | |
697 | TIFFGetField(tif, TIFFTAG_IMAGEWIDTH, &imageWidth);<br> | |
698 | TIFFGetField(tif, TIFFTAG_IMAGELENGTH, &imageLength);<br> | |
699 | TIFFGetField(tif, TIFFTAG_TILEWIDTH, &tileWidth);<br> | |
700 | TIFFGetField(tif, TIFFTAG_TILELENGTH, &tileLength);<br> | |
701 | buf = _TIFFmalloc(TIFFTileSize(tif));<br> | |
702 | for (y = 0; y < imagelength; y += tilelength)<br> | |
703 | for (x = 0; x < imagewidth; x += tilewidth)<br> | |
704 | tiffreadtile(tif, buf, x, y, 0);<br> | |
705 | _tifffree(buf);<br> | |
706 | tiffclose(tif);<br> | |
707 | }<br> | |
708 | }</tt> | |
709 | </p> | |
710 | <p> | |
711 | (once again, we assume samples are packed contiguously.) | |
712 | </p> | |
713 | <p> | |
714 | Alternatively a direct interface to the low-level data is provided | |
715 | a la strips. Tiles can be read with | |
716 | <tt>TIFFReadEncodedTile</tt> or <tt>TIFFReadRawTile</tt>, | |
717 | and written with <tt>TIFFWriteEncodedTile</tt> or | |
718 | <tt>TIFFWriteRawTile</tt>. For example, to read all the tiles in an image: | |
719 | </p> | |
720 | <p style="margin-left: 40px"> | |
721 | <tt>#include "tiffio.h"<br> | |
722 | main()<br> | |
723 | {<br> | |
724 | TIFF* tif = TIFFOpen("myfile.tif", "r");<br> | |
725 | if (tif) {<br> | |
726 | tdata_t buf;<br> | |
727 | ttile_t tile;<br> | |
728 | <br> | |
729 | buf = _TIFFmalloc(TIFFTileSize(tif));<br> | |
730 | for (tile = 0; tile < tiffnumberoftiles(tif); tile++)<br> | |
731 | tiffreadencodedtile(tif, tile, buf, (tsize_t) -1);<br> | |
732 | _tifffree(buf);<br> | |
733 | tiffclose(tif);<br> | |
734 | }<br> | |
735 | }</tt> | |
736 | </p> | |
737 | <hr> | |
738 | <h2 id="other">Other Stuff</h2> | |
739 | <p> | |
740 | Some other stuff will almost certainly go here... | |
741 | </p> | |
742 | <hr> | |
743 | <p> | |
744 | Last updated: $Date: 2005/12/28 06:53:18 $ | |
745 | </p> | |
746 | </body> | |
747 | </html> |