Register
Login
Resources
Docs Blog Datasets Glossary Case Studies Tutorials & Webinars
Product
Data Engine LLMs Platform Enterprise
Pricing Explore
Connect to our Discord channel

file-formats.rst 25 KB

You have to be logged in to leave a comment. Sign In
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
  1. .. _GMT File Formats:
  2. GMT File Formats
  3. ================
  4. Table data
  5. ----------
  6. These files have *N* records which have *M* fields each. All programs
  7. that handle tables can read multicolumn files. GMT can read both
  8. ASCII, native binary, netCDF table data, and ESRI shapefiles (which
  9. we convert to GMT/OGR format via GDAL's ogr2ogr tool under the hood).
  10. ASCII tables
  11. ~~~~~~~~~~~~
  12. Optional file header records
  13. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  14. The first data record may be preceded by one or more header records. Any
  15. records that begins with '#' is considered a header or comment line and
  16. are always processed correctly. If your data file has leading header
  17. records that do *not* start with '#' then you must make sure to use the
  18. **-h** option and set the parameter :term:`IO_N_HEADER_RECS` in the :doc:`/gmt.conf` file
  19. (GMT default is one header record if **-h** is given; you may also use
  20. **-h**\ *nrecs* directly). Alternatively, you can override the header record marker '#'
  21. by modifying the :term:`IO_HEADER_MARKER` default setting.
  22. Fields within a record must be separated by
  23. spaces, tabs, commas, or semi-colons. Each field can be an integer or floating-point
  24. number or a geographic coordinate string using the
  25. [±]\ *dd*\ [:*mm*\ [:*ss*\ [.\ *xx...*]]][**W**\|\ **E**\|\ **S**\|\ **N**\|\ **w**\|\ **e**\|\ **s**\|\ **n**]
  26. format. Thus, 12:30:44.5W, 17.5S, 1:00:05, and 200:45E are all valid
  27. input strings. GMT is expected to handle most CVS (Comma-Separated Values)
  28. files, including numbers given in double quotes. On output, fields will be separated by the character
  29. given by the parameter :term:`IO_COL_SEPARATOR`, which by default is a TAB.
  30. Optional segment header records
  31. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  32. When dealing with time- or (*x,y*)-series it is usually convenient to
  33. have each profile in separate files. However, this may sometimes prove
  34. impractical due to large numbers of profiles. An example is files of
  35. digitized lineations where the number of individual features may range
  36. into the thousands. One file per feature would in this case be
  37. unreasonable and furthermore clog up the directory. GMT provides a
  38. mechanism for keeping more than one profile in a file. Such files are
  39. called *multiple segment files* and are identical to the ones just
  40. outlined except that they have segment headers interspersed with data
  41. records that signal the start of a new segment. The segment headers may
  42. be of any format, but all must have the same character in the first
  43. column. The unique character is by default '\ >\ ', but you can
  44. override that by modifying the :term:`IO_SEGMENT_MARKER` default setting.
  45. Programs can examine the segment headers to see if they contain **-D**
  46. for a distance value, **-W** and **-G** options for specifying pen and
  47. fill attributes for individual segments, **-Z** to change color via a
  48. CPT, **-L** for label specifications, or **-T** for general-purpose
  49. text descriptions. These settings (and occasionally others) will
  50. override the corresponding command line options. GMT also provides for
  51. two special values for :term:`IO_SEGMENT_MARKER` that can make
  52. interoperability with other software packages easier. Choose the marker
  53. **B** to have blank lines recognized as segment breaks, or use **N** to
  54. have data records whose fields equal NaN mean segment breaks (e.g., as
  55. used by Matlab or Octave). When these markers are used then no other
  56. segment header will be considered. Note that :term:`IO_SEGMENT_MARKER` can
  57. be set differently for input and output. Finally, if a segment represents
  58. a closed polygon that is a hole inside another polygon you indicate this
  59. by including **-Ph** in the segment header. This setting will be read
  60. and processed if converting a file to the OGR format.
  61. Binary tables
  62. ~~~~~~~~~~~~~
  63. GMT programs also support native binary tables to speed up
  64. input-output for i/o-intensive tasks like gridding and preprocessing.
  65. This is discussed in more detail in section :ref:`option_-b`.
  66. NetCDF tables
  67. ~~~~~~~~~~~~~
  68. More and more programs are now producing binary data in the netCDF
  69. format, and so GMT programs started to support tabular netCDF data
  70. (files containing one or more 1-dimensional arrays) starting with
  71. GMT version 4.3.0. Because of the meta data contained in those files,
  72. reading them is much less complex than reading native binary tables, and
  73. even than ASCII tables. GMT programs will read as many 1-dimensional
  74. columns as are needed by the program, starting with the first
  75. 1-dimensional it can find in the file. To specifically specify which
  76. variables are to be read, append the suffix
  77. **?**\ *var1*\ **/**\ *var2*\ **/**\ *...* to the netCDF file name or
  78. add the option **-bic**\ *var1*\ **/**\ *var2*\ **/**\ *...*, where
  79. *var1*, *var2*, etc.are the names of the variables to be processed. The
  80. latter option is particularly practical when more than one file is read:
  81. the **-bic** option will apply to all files. Currently, GMT only
  82. reads, but does not write, netCDF tabular data.
  83. Shapefiles
  84. ~~~~~~~~~~
  85. GMT programs that read tables also support ESRI shapefiles, provided GMT was compiled
  86. with GDAL support. By default, only the geographic coordinates are read. To select
  87. some or all aspatial fields, see the :ref:`-a option <-aspatial_full>`.
  88. Grid files
  89. ----------
  90. GMT allows numerous grid formats to be read. In addition to the default
  91. netCDF format it can use binary floating points, short integers, bytes, and
  92. bits, as well as 8-bit Sun raster files (colormap ignored). Additional
  93. formats may be used by supplying read/write functions and linking these with
  94. the GMT libraries. The source file ``gmt_customio.c`` has the information
  95. that programmers will need to augment GMT to read custom grid files. See
  96. Section :ref:`grid-file-format` for more information.
  97. NetCDF files
  98. ~~~~~~~~~~~~
  99. By default, GMT stores 2-D grids as COARDS-compliant netCDF files.
  100. COARDS (which stands for Cooperative Ocean/Atmosphere Research Data
  101. Service) is a convention used by many agencies distributing gridded data
  102. for ocean and atmosphere research. Sticking to this convention allows
  103. GMT to read gridded data provided by other institutes and other
  104. programs. Conversely, other general domain programs will be able to read
  105. grids created by GMT. COARDS is a subset of a more extensive
  106. convention for netCDF data called CF-1.5 (Climate and Forecast, version
  107. 1.5). Hence, GMT grids are also automatically CF-1.5-compliant.
  108. However, since CF-1.5 has more general application than COARDS, not all
  109. CF-1.5 compliant netCDF files can be read by GMT.
  110. The netCDF grid file in GMT has several attributes (See Table
  111. :ref:`netcdf-format <tbl-netcdf-format>`) to describe the content. The routine
  112. that deals with netCDF grid files is sufficiently flexible so that grid files
  113. slightly deviating from the standards used by GMT can also be read.
  114. .. _tbl-netcdf-format:
  115. +----------------------+--------------------------------------------------------------------+
  116. | **Attribute** | **Description** |
  117. +======================+====================================================================+
  118. | | *Global attributes* |
  119. +----------------------+--------------------------------------------------------------------+
  120. | Conventions | COARDS, CF-1.5 (optional) |
  121. +----------------------+--------------------------------------------------------------------+
  122. | title | Title (optional) |
  123. +----------------------+--------------------------------------------------------------------+
  124. | source | How file was created (optional) |
  125. +----------------------+--------------------------------------------------------------------+
  126. | node_offset | 0 for gridline node registration (default), |
  127. | | 1 for pixel registration |
  128. +----------------------+--------------------------------------------------------------------+
  129. | | *x- and y-variable attributes* |
  130. +----------------------+--------------------------------------------------------------------+
  131. | long_name | Coordinate name (e.g., "Longitude" and "Latitude") |
  132. +----------------------+--------------------------------------------------------------------+
  133. | units | Unit of the coordinate (e.g., "degrees_east" and "degrees_north") |
  134. +----------------------+--------------------------------------------------------------------+
  135. | actual range | Minimum and maximum *x* and *y* of region; if absent the |
  136. | (or valid range) | first and last *x*- and *y*-values are queried |
  137. +----------------------+--------------------------------------------------------------------+
  138. | | *z-variable attributes* |
  139. +----------------------+--------------------------------------------------------------------+
  140. | long_name | Name of the variable (default: "z") |
  141. +----------------------+--------------------------------------------------------------------+
  142. | units | Unit of the variable |
  143. +----------------------+--------------------------------------------------------------------+
  144. | scale_factor | Factor to multiply *z* with (default: 1) |
  145. +----------------------+--------------------------------------------------------------------+
  146. | add_offset | Offset to add to scaled *z* (default: 0) |
  147. +----------------------+--------------------------------------------------------------------+
  148. | actual_range | Minimum and maximum *z* (in unpacked units, optional) and *z* |
  149. +----------------------+--------------------------------------------------------------------+
  150. | \_FillValue | Value associated with missing or invalid data points; if absent an |
  151. | (or missing_value) | appropriate default value is assumed, depending on data type. |
  152. +----------------------+--------------------------------------------------------------------+
  153. By default, the first 2-dimensional variable in a netCDF file will be read as
  154. the *z* variable and the coordinate axes *x* and *y* will be determined from
  155. the dimensions of the *z* variable. GMT will recognize whether the *y*
  156. (latitude) variable increases or decreases. Both forms of data storage are
  157. handled appropriately.
  158. For more information on the use of COARDS-compliant netCDF files, and on how
  159. to load multi-dimensional grids, read Section :ref:`modifiers-for-CF`.
  160. Chunking and compression with netCDF
  161. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  162. GMT supports reading and writing of netCDF-4 files since release 5.0. For
  163. performance reasons with ever-increasing grid sizes, the default output format
  164. of GMT is netCDF-4 with chunking enabled for grids with more than 16384 cells.
  165. Chunking means that the data are not stored sequentially in rows along latitude
  166. but rather split up into tiles. Figure :ref:`netcdf_chunking` illustrates
  167. the layout in a chunked netCDF file. To access a subset of the data (e.g.,
  168. the four blue tiles in the lower left), netCDF only reads those tiles
  169. ("chunks") instead of extracting data from long rows.
  170. .. _netcdf_chunking:
  171. .. figure:: /_images/GMT_chunking.*
  172. :align: center
  173. Grid split into 3 by 3 chunks
  174. Gridded datasets in the earth sciences usually exhibit a strong spatial
  175. dependence (e.g. topography, potential fields, illustrated by blue and white
  176. cells in Figure :ref:`netcdf_chunking`) and deflation can greatly reduce the
  177. file size and hence the file access time (deflating/inflating is faster than
  178. hard disk I/O). It is therefore convenient to deflate grids with spatial
  179. dependence (levels 1–3 give the best speed/size-tradeoff).
  180. You may control the size of the chunks of data and compression with the
  181. configuration parameters :term:`IO_NC4_CHUNK_SIZE`
  182. and :term:`IO_NC4_DEFLATION_LEVEL` as specified in
  183. :doc:`/gmt.conf` and you can check the netCDF format with :doc:`/grdinfo`.
  184. Classic netCDF files were the *de facto* standard until netCDF 4.0 was released
  185. in 2008. Most programs supporting netCDF by now are using the netCDF-4
  186. library and are thus capable of reading netCDF files generated with GMT 5,
  187. this includes official GMT releases since revision 4.5.8. In rare occasions,
  188. when you have to load netCDF files with old software, you may be forced to
  189. export your grids in the old classic format. This can be achieved by setting
  190. :term:`IO_NC4_CHUNK_SIZE` to **c**\ lassic.
  191. Further reading:
  192. - `Unidata NetCDF Workshop: NetCDF Formats and Performance <http://www.unidata.ucar.edu/software/netcdf/workshops/most-recent/performance/index.html>`_
  193. - `Unidata NetCDF Workshop: What is Chunking? <http://www.unidata.ucar.edu/software/netcdf/workshops/most-recent/nc4chunking/WhatIsChunking.html>`_
  194. - `HDF NetCDF-4 Performance Report <http://www.hdfgroup.org/pubs/papers/2008-06_netcdf4_perf_report.pdf>`_
  195. Gridline and Pixel node registration
  196. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  197. Scanline format means that the data are stored in rows (*y* = constant)
  198. going from the "top" (:math:`y = y_{max}` (north)) to the "bottom"
  199. (:math:`y = y_{min}` (south)). Data within each row are ordered from
  200. "left" (:math:`x = x_{min}` (west)) to "right" (:math:`x = x_{max}`
  201. (east)). The *registration* signals how the nodes are laid out. The grid
  202. is always defined as the intersections of all
  203. *x* ( :math:`x = x_{min}, x_{min} + x_{inc}, x_{min} + 2 \cdot x_{inc}, \ldots, x_{max}` )
  204. and *y* ( :math:`y = y_{min}, y_{min} + y_{inc}, y_{min} + 2 \cdot y_{inc}, \ldots, y_{max}` )
  205. lines. The two scenarios differ as to which area each data point
  206. represents. The default node registration in GMT is gridline node
  207. registration. Most programs can handle both types, and for some programs
  208. like :doc:`/grdimage` a pixel registered file
  209. makes more sense. Utility programs like
  210. :doc:`/grdsample` and
  211. :doc:`/grdproject` will allow you to
  212. convert from one format to the other;
  213. :doc:`/grdedit` can make changes to the grid
  214. header and convert a pixel- to a gridline-registered grid, or *vice
  215. versa*. The grid registration is determined by the common GMT **-r**
  216. option (see Section :ref:`option_nodereg`).
  217. Boundary Conditions for operations on grids
  218. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  219. GMT has the option to specify boundary conditions in some programs
  220. that operate on grids (e.g.,
  221. :doc:`/grdsample`, :doc:`/grdgradient`,
  222. :doc:`/grdtrack`, :doc:`/nearneighbor`, and
  223. :doc:`/grdview`, to name a few. The desired
  224. condition can be set with the common GMT option **-n**; see Section
  225. :ref:`option_-n`. The boundary conditions come into play when
  226. interpolating or computing derivatives near the limits of the region
  227. covered by the grid. The *default* boundary conditions used are those
  228. which are "natural" for the boundary of a minimum curvature
  229. interpolating surface. If the user knows that the data are periodic in
  230. *x* (and/or *y*), or that the data cover a sphere with *x*,\ *y*
  231. representing *longitude*,\ *latitude*, then there are better choices for
  232. the boundary conditions. Periodic conditions on *x* (and/or *y*) are
  233. chosen by specifying *x* (and/or *y*) as the boundary condition flags;
  234. global spherical cases are specified using the *g* (geographical) flag.
  235. Behavior of these conditions is as follows:
  236. Periodic
  237. conditions on *x* indicate that the data are periodic in the
  238. distance (:math:`x_{max} - x_{min}`) and thus repeat values after
  239. every :math:`N = (x_{max} - x_{min})/x_{inc}`. Note that this
  240. implies that in a grid-registered file the values in the first and
  241. last columns are equal, since these are located at
  242. :math:`x = x_{min}` and :math:`x = x_{max}`, and there are
  243. *N + 1* columns in the file. This is not the case in a
  244. pixel-registered file, where there are only *N* and the first
  245. and last columns are located at :math:`x_{min} + x_{inc}/2` and
  246. :math:`x_{max} - x_{inc}/2`. If *y* is periodic all the same
  247. holds for *y*.
  248. Geographical
  249. conditions indicate the following:
  250. #. If :math:`(x_{max} - x_{min}) \geq 360` and also 180 modulo
  251. :math:`x_{inc} = 0` then a periodic condition is used on
  252. *x* with a period of 360; else a default condition is used
  253. on the *x* boundaries.
  254. #. If condition 1 is true and also :math:`y_{max} = 90` then a
  255. "north pole condition" is used at :math:`y_{max}`, else a default
  256. condition is used there.
  257. #. If condition 1 is true and also :math:`y_{min} = -90` then a
  258. "south pole condition" is used at :math:`y_{min}`, else a default
  259. condition is used there.
  260. "Pole conditions" use a 180° phase-shift of the data, requiring 180
  261. modulo :math:`x_{inc} = 0`.
  262. Default
  263. boundary conditions are
  264. .. math:: \nabla^2 f = \frac{\partial}{\partial n} \nabla^2 f = 0
  265. on the boundary, where :math:`f(x, y)` is represented by the values
  266. in the grid file, and :math:`\partial/\partial n` is the derivative
  267. in the direction normal to a boundary, and
  268. .. math:: \nabla^2 = \left(\frac{\partial^2}{\partial x^2} + \frac{\partial^2}{\partial y^2}\right)
  269. is the two-dimensional Laplacian operator.
  270. Native binary grid files
  271. ~~~~~~~~~~~~~~~~~~~~~~~~
  272. The old-style native grid file format that was common in earlier version
  273. of GMT is still supported, although the use of netCDF files is
  274. strongly recommended. The file starts with a header of 892 bytes
  275. containing a number of attributes defining the content. The
  276. :doc:`/grdedit` utility program will allow you
  277. to edit parts of the header of an existing grid file. The attributes
  278. listed in Table :ref:`grdheader <tbl-grdheader>` are contained within the header record
  279. in the order given (except the *z*-array which is not part of the
  280. header structure, but makes up the rest of the file). As this header was
  281. designed long before 64-bit architectures became available, the jump
  282. from the first three integers to the subsequent doubles in the structure
  283. does not occur on a 16-byte alignment. While GMT handles the reading
  284. of these structures correctly, enterprising programmers must take care
  285. to read this header correctly (see our code for details).
  286. .. _tbl-grdheader:
  287. +-----------------------------------+--------------------------------------------------------+
  288. | **Parameter** | **Description** |
  289. +===================================+========================================================+
  290. | **int** *n_columns* | Number of nodes in the *x*-dimension |
  291. +-----------------------------------+--------------------------------------------------------+
  292. | **int** *n_rows* | Number of nodes in the *y*-dimension |
  293. +-----------------------------------+--------------------------------------------------------+
  294. | **int** *registration* | 0 for grid line registration, 1 for pixel registration |
  295. +-----------------------------------+--------------------------------------------------------+
  296. | **double** *x_min* | Minimum *x*-value of region |
  297. +-----------------------------------+--------------------------------------------------------+
  298. | **double** *x_max* | Maximum *x*-value of region |
  299. +-----------------------------------+--------------------------------------------------------+
  300. | **double** *y_min* | Minimum *y*-value of region |
  301. +-----------------------------------+--------------------------------------------------------+
  302. | **double** *y_max* | Maximum *y*-value of region |
  303. +-----------------------------------+--------------------------------------------------------+
  304. | **double** *z_min* | Minimum *z*-value in data set |
  305. +-----------------------------------+--------------------------------------------------------+
  306. | **double** *z_max* | Maximum *z*-value in data set |
  307. +-----------------------------------+--------------------------------------------------------+
  308. | **double** *x_inc* | Node spacing in *x*-dimension |
  309. +-----------------------------------+--------------------------------------------------------+
  310. | **double** *y_inc* | Node spacing in *y*-dimension |
  311. +-----------------------------------+--------------------------------------------------------+
  312. | **double** *z_scale_factor* | Factor to multiply *z*-values after read |
  313. +-----------------------------------+--------------------------------------------------------+
  314. | **double** *z_add_offset* | Offset to add to scaled *z*-values |
  315. +-----------------------------------+--------------------------------------------------------+
  316. | **char** *x_units*\ [80] | Units of the *x*-dimension |
  317. +-----------------------------------+--------------------------------------------------------+
  318. | **char** *y_units*\ [80] | Units of the *y*-dimension |
  319. +-----------------------------------+--------------------------------------------------------+
  320. | **char** *z_units*\ [80] | Units of the *z*-dimension |
  321. +-----------------------------------+--------------------------------------------------------+
  322. | **char** *title*\ [80] | Descriptive title of the data set |
  323. +-----------------------------------+--------------------------------------------------------+
  324. | **char** *command*\ [320] | Command line that produced the grid file |
  325. +-----------------------------------+--------------------------------------------------------+
  326. | **char** *remark*\ [160] | Any additional comments |
  327. +-----------------------------------+--------------------------------------------------------+
  328. | **TYPE** *z*\ [n_columns\*n_rows] | 1-D array with *z*-values in scanline format |
  329. +-----------------------------------+--------------------------------------------------------+
  330. Sun raster files
  331. ----------------
  332. The Sun raster file format consists of a header followed by a series of
  333. unsigned 1-byte integers that represents the bit-pattern. Bits are
  334. scanline oriented, and each row must contain an even number of bytes.
  335. The predefined 1-bit patterns in GMT have dimensions of 64 by 64, but
  336. other sizes will be accepted when using the **-Gp|P** option. The Sun
  337. header structure is outline in Table :ref:`sunheader <tbl-sunheader>`.
  338. .. _tbl-sunheader:
  339. +---------------------------+-------------------------------------+
  340. | **Parameter** | **Description** |
  341. +===========================+=====================================+
  342. | **int** *ras_magic* | Magic number |
  343. +---------------------------+-------------------------------------+
  344. | **int** *ras_width* | Width (pixels) of image |
  345. +---------------------------+-------------------------------------+
  346. | **int** *ras_height* | Height (pixels) of image |
  347. +---------------------------+-------------------------------------+
  348. | **int** *ras_depth* | Depth (1, 8, 24, 32 bits) of pixel |
  349. +---------------------------+-------------------------------------+
  350. | **int** *ras_length* | Length (bytes) of image |
  351. +---------------------------+-------------------------------------+
  352. | **int** *ras_type* | Type of file; see RT\_ below |
  353. +---------------------------+-------------------------------------+
  354. | **int** *ras_maptype* | Type of colormap; see RMT\_ below |
  355. +---------------------------+-------------------------------------+
  356. | **int** *ras_maplength* | Length (bytes) of following map |
  357. +---------------------------+-------------------------------------+
  358. After the header, the color map (if *ras_maptype* is not RMT_NONE)
  359. follows for *ras_maplength* bytes, followed by an image of
  360. *ras_length* bytes. Some related definitions are given in
  361. Table :ref:`sundef <tbl-sundef>`.
  362. .. _tbl-sundef:
  363. +---------------------+-------------------------------------------+
  364. | **Macro name** | **Description** |
  365. +=====================+===========================================+
  366. | RAS_MAGIC | 0x59a66a95 |
  367. +---------------------+-------------------------------------------+
  368. | RT_STANDARD | 1 (Raw pixrect image in 68000 byte order) |
  369. +---------------------+-------------------------------------------+
  370. | RT_BYTE_ENCODED | 2 (Run-length compression of bytes) |
  371. +---------------------+-------------------------------------------+
  372. | RT_FORMAT_RGB | 3 ([X]RGB instead of [X]BGR) |
  373. +---------------------+-------------------------------------------+
  374. | RMT_NONE | 0 (ras_maplength is expected to be 0) |
  375. +---------------------+-------------------------------------------+
  376. | RMT_EQUAL_RGB | 1 (red[ras_maplength/3],green[],blue[]) |
  377. +---------------------+-------------------------------------------+
  378. Numerous public-domain programs exist, such as **xv** and
  379. **convert** (in the GraphicsMagick or ImageMagick package), that will translate between
  380. various raster file formats such as tiff, gif, jpeg, and Sun raster.
  381. Raster patterns may be created with GMT plotting tools by generating
  382. PostScript plots that can be rasterized by ghostscript and
  383. translated into the right raster format.
Tip!

Press p or to see the previous file or, n or to see the next file

Comments

Loading...