1FITS(3)               User Contributed Perl Documentation              FITS(3)
2
3
4

NAME

6       PDL::IO::FITS -- Simple FITS support for PDL
7

SYNOPSIS

9        use PDL;
10        use PDL::IO::FITS;
11
12        $a = rfits('foo.fits');          # read a FITS file
13        $a->wfits('bar.fits');           # write a FITS file
14

DESCRIPTION

16       This module provides basic FITS support for PDL, in the sense of read‐
17       ing and writing whole FITS files.  (For more complex operations, such
18       as prefiltering rows out of tables or performing operations on the FITS
19       file in-place on disk), you can use the Astro::FITS::CFITSIO module
20       that is available on CPAN.
21
22       Basic FITS image files are supported, along with BINTABLE and IMAGE
23       extensions.  ASCII Table support is planned, as are the HEASARC
24       bintable extensions that are recommended in the 1999 FITS standard.
25
26       Table support is based on hashes and named columns, rather than the
27       less convenient (but slightly more congruent) technique of perl lists
28       of numbered columns.
29
30       The principle interface routines are "rfits" and "wfits", for reading
31       and writing respectively.  FITS headers are returned as perl hashes or
32       (if the module is present) Astro::FITS::Header objects that are tied to
33       perl hashes.  Astro::FITS::Header objects provide convenient access
34       through the tied hash interface, but also allow you to control the card
35       structure in more detail using a separate method interface; see the
36       Astro::FITS::Header documentation for details.
37

AUTHOR

39       Copyright (C) Karl Glazebrook, Craig DeForest, and Doug Burke,
40       1997-2004.  There is no warranty.  You are allowed to redistribute
41       and/or modify this software under certain conditions.  For details, see
42       the file COPYING in the PDL distribution.  If this file is separated
43       from the PDL distribution, the copyright notice should be pasted into
44       in this file.
45

FUNCTIONS

47       rfits()
48
49       Simple piddle FITS reader.
50
51         $pdl = rfits('file.fits');   # Read a simple FITS image
52
53       Suffix magic:
54
55         $pdl = rfits('file.fits.gz'); # Read a file with gunzip(1)
56         $pdl = rfits('file.fits.Z');  # Read a file with uncompress(1)
57
58         $pdl = rfits('file.fits[2]');    # Read 2nd extension
59         $pdl = rfits('file.fits.gz[3]'); # Read 3rd extension
60         @pdls = rfits('file.fits');      # Read primary data and extensions
61
62         $hdr = rfits('file.fits',{data=>0});  # Options hash changes behavior
63
64       In list context, "rfits" reads the primary image and all possible
65       extensions, returning them in the same order that they occurred in the
66       file.  In scalar context, the default is to read the primary HDU. One
67       can read other HDU's by using the [n] syntax, the second one is [1].
68       Currently recognized extensions are IMAGE and BINTABLE.  (See the
69       addendum on EXTENSIONS for details).
70
71       "rfits" accepts several options that may be passed in as a hash ref if
72       desired:
73
74       bscale (default=1)
75          Determines whether the data are linearly scaled using the
76          BSCALE/BZERO keywords in the FITS header.  To read in the exact data
77          values in the file, set this to 0.
78
79       data (default=1)
80          Determines whether to read the data, or just the header.  If you set
81          this to 0, you will get back the FITS header rather than the data
82          themselves.  (Note that the header is normally returned as the "hdr"
83          field of the returned PDL; this causes it to be returned as a hash
84          ref directly.)
85
86       hdrcpy (default=0)
87          Determines whether the hdrcpy flag is set in the returned PDL.  Set‐
88          ting the flag will cause an explicit deep copy of the header when‐
89          ever you use the returned PDL in an arithmetic or slicing operation.
90          That is useful in many circumstances but also causes a hit in speed.
91
92       FITS image headers are stored in the output PDL and can be retrieved
93       with hdr or gethdr.  The hdrcpy flag of the PDL is set so that the
94       header is copied to derived piddles by default.  (This is inefficient
95       if you are planning to do lots of small operations on the data; clear
96       the flag with "->hcpy(0)" or via the options hash if that's the case.)
97
98       The header is a hash whose keys are the keywords in the FITS header.
99       If you have the "Astro::FITS::Header" module installed, the header is
100       actually a tied hash to a FITS header object, which can give you more
101       control over card order, comment fields, and variable types.  (see
102       Astro::FITS::Header for details).
103
104       The header keywords are converted to uppercase per the FITS standard.
105       Access is case-insensitive on the perl side, provided that
106       Astro::FITS::Header is installed.
107
108       If Astro::FITS::Header is not installed, then a built-in legacy parser
109       is used to generate the header hash.  Keyword-associated comments in
110       the headers are stored under the hash key "<keyword>_COMMENT>".  All
111       HISTORY cards in the header are collected into a single multiline
112       string stored in the "HISTORY" key.  All COMMENT cards are similarly
113       collected under the "COMMENT" key.
114
115       BSCALE/BZERO
116
117       If the BSCALE and/or BZERO keywords are set, they are applied to the
118       image before it is returned.  The returned PDL is promoted as necessary
119       to contain the multiplied values, and the BSCALE and BZERO keywords are
120       deleted from the header for clarity.  If you don't want this type of
121       processing, set 'bscale=>0' in the options hash.
122
123       EXTENSIONS
124
125       Sometimes a FITS file contains only extensions and a stub header in the
126       first header/data unit ("primary HDU").  In scalar context, you nor‐
127       mally only get back the primary HDU -- but in this special case, you
128       get back the first extension HDU.  You can force a read of the primary
129       HDU by adding a '[0]' suffix to the file name.
130
131       BINTABLE EXTENSIONS
132
133       Binary tables are handled. Currently only the following PDL datatypes
134       are supported: byte, short, ushort, long, float, and double. At present
135       ushort() data is written as a long rather than as a short with
136       TSCAL/ZERO; this may change.
137
138       The return value for a binary table is a hash ref containing the names
139       of the columns in the table (in UPPER CASE as per the FITS standard).
140       Each element of the hash contains a PDL (for numerical values) or a
141       perl list (for string values).  The PDL's 0th dimension runs across
142       rows; the 1st dimension runs across the repeat index within the row
143       (for rows with more than one value).
144
145       Thus, if your table contains a column named "FOO" with type "5D", the
146       expression
147
148         $a->{FOO}->((2))
149
150       returns a 5-element double-precision PDL containing the values of FOO
151       from the third row of the table.
152
153       The header of the table itself is parsed as with a normal FITS HDU, and
154       is returned in the element 'hdr' of the returned hash.  You can use
155       that to preserve the original column order or access the table at a low
156       level, if you like.
157
158       Scaling and zero-point adjustment are performed as with BSCALE/BZERO:
159       the appropriate keywords are deleted from the as-returned header.  To
160       avoid this behavior, set 'bscale=>0' in the options hash.
161
162       As appropriate, TSCAL/ZERO and TUNIT are copied into each column-PDL's
163       header as BSCALE/BZERO and BUNIT.
164
165       The main hash also contains the element 'tbl', which is set to 'binary'
166       to distinguish it from an ASCII table.
167
168       Because different columns in the table might have identical names in a
169       FITS file, the binary table reader practices collision avoidance.  If
170       you have multiple columns named "FOO", then the first one encountered
171       (numerically) gets the name "FOO", the next one gets "FOO_1", and the
172       next "FOO_2", etc.  The appropriate TTYPEn fields in the header are
173       changed to match the renamed column fields.
174
175       Columns with no name are assigned the name "COL_<n>", where <n> starts
176       at 1 and increments for each no-name column found.
177
178       If a FITS file contains the "BLANK" keyword (and has "BITPIX > 0"), the
179       piddle will have its bad flag set, and those elements which equal the
180       "BLANK" value will be set bad.  For "BITPIX < 0", any NaN's are con‐
181       verted to bad (if necessary).
182
183       rfitshdr()
184
185       Read only the header of a FITS file or an extension within it.
186
187       This is syntactic sugar for the "data=>0" option to rfits.
188
189       See rfits for details on header handling.  rfitshdr() runs the same
190       code to read the header, but returns it rather than reading in a data
191       structure as well.
192
193       wfits()
194
195       Simple PDL FITS writer
196
197         wfits $pdl, 'filename.fits', [$BITPIX];
198         wfits $hash, 'filename.fits', [$OPTIONS];
199         $pdl->wfits('foo.fits',-32);
200
201       Suffix magic:
202
203         # Automatically compress through pipe to gzip
204         wfits $pdl, 'filename.fits.gz';
205         # Automatically compress through pipe to compress
206         wfits $pdl, 'filename.fits.Z';
207
208       * Ordinary (PDL) data handling:
209          If the first argument is a PDL, then the PDL is written out as an
210          ordinary FITS file with a single Header/Data Unit of data.
211
212          $BITPIX is then optional and coerces the output data type according
213          to the standard FITS convention for the BITPIX field (with positive
214          values representing integer types and negative values representing
215          floating-point types).
216
217          If $pdl has a FITS header attached to it (actually, any hash that
218          contains a "SIMPLE=>T" keyword), then that FITS header is written
219          out to the file.  The image dimension tags are adjusted to the
220          actual dataset.  If there's a mismatch between the dimensions of the
221          data and the dimensions in the FITS header, then the header gets
222          corrected and a warning is printed.
223
224       * Table handling:
225          If you feed in a hash ref instead of a PDL, then the hash ref is
226          written out as a binary table extension.  The hash ref keys are
227          treated as column names, and their values are treated as the data to
228          be put in each column.
229
230          For numeric information, the hash values should contain PDLs.  The
231          0th dim of the PDL runs across rows, and higher dims are written as
232          multi-value entries in the table (e.g. a 7x5 PDL will yield a single
233          named column with 7 rows and 5 numerical entries per row, in a
234          binary table).  ASCII tables only allow one entry per column in each
235          row, so if you plan to write an ASCII table then all of the values
236          of $hash should have at most one dim.
237
238          All of the column dims must agree in the threading sense. That is to
239          say, the 0th dimension of all of the values of $hash should be the
240          same (indicating that all columns have the same number of rows).  As
241          an exception, if the 0th dim of any of the values is 1, or if that
242          value is a PDL scalar (with 0 dims), then that value is "threaded"
243          over -- copied into all rows.
244
245          Data dimensions higher than 2 are not possible in ordinary FITS
246          tables, so dims higher than 1 are clumped.  (e.g. a 7x5x3 PDL will
247          yield a single named column with 7 rows and 15 numerical entries per
248          row).  If $PDL::Verbose is set, this condition causes a warning mes‐
249          sage to be printed.  [There is a multidim extension that is not yet
250          implemented but should be].
251
252          Non-PDL Perl scalars are treated as strings, even if they contain
253          numerical values.  For example, a list ref containing 7 values is
254          treated as 7 rows containing one string each.  There is no such
255          thing as a multi-string column in FITS tables, so any nonscalar val‐
256          ues in the list are stringified before being written.  For example,
257          if you pass in a perl list of 7 PDLs, each PDL will be stringified
258          before being written, just as if you printed it to the screen.  This
259          is probably not what you want -- you should use glue to connect the
260          separate PDLs into a single one.  (e.g.
261          "$a->glue(1,$b,$c)->mv(1,0)")
262
263          The column names are case-insensitive, but by convention the keys of
264          $hash should normally be ALL CAPS, containing only digits, capital
265          letters, hyphens, and underscores.  If you include other characters,
266          then case is smashed to ALL CAPS, whitespace is converted to under‐
267          scores, and unrecognized characters are ignored -- so if you include
268          the key "Au Purity (%)", it will be written to the file as a column
269          that is named "AU_PURITY".  Since this is not guaranteed to produce
270          unique column names, subsequent columns by the same name are disam‐
271          biguated by the addition of numbers.
272
273          Two special keys, 'hdr' and 'tbl', can contain meta-information
274          about the type of table you want to write.  You may override them by
275          including an $OPTIONS hash with a 'hdr' and/or 'tbl' key.
276
277          The 'tbl' key, if it exists, must contain either 'ASCII' or 'binary'
278          (case-insensitive), indicating whether to write an ascii or binary
279          table.  The default is binary. [ASCII table writing is planned but
280          does not yet exist].
281
282          You can specify the format of the table quite specifically with the
283          'hdr' key or option field.  If it exists, then the 'hdr' key should
284          contain fields appropriate to the table extension being used.  Any
285          field information that you don't specify will be filled in automati‐
286          cally, so (for example) you can specify that a particular column
287          name goes in a particular position, but allow "wfits" to arrange the
288          other columns in the usual alphabetical order into any unused slots
289          that you leave behind.  The "TFORMn", "TFIELDS", "PCOUNT", "GCOUNT",
290          "NAXIS", and "NAXISn" keywords are ignored: their values are calcu‐
291          lated based on the hash that you supply.  Any other fields are
292          passed into the final FITS header verbatim.
293
294          As an example, the following
295
296            $a = long(1,2,4);
297            $b = double(1,2,4);
298            wfits { 'COLA'=>$a, 'COLB'=>$b }, "table1.fits";
299
300          will create a binary FITS table called table1.fits which contains
301          two columns called "COLA" and "COLB". The order of the columns is
302          controlled by setting the "TTYPEn" keywords in the header array, so
303
304            $h = { 'TTYPE1'=>'Y', 'TTYPE2'=>'X' };
305            wfits { 'X'=>$a, 'Y'=>$b, hdr=>$h }, "table2.fits";
306
307          creates table2.fits where the first column is called "Y" and the
308          second column is "X".
309
310       * multi-value handling
311          If you feed in a perl list rather than a PDL or a hash, then each
312          element is written out as a separate HDU in the FITS file.  Each
313          element of the list must be a PDL or a hash. [This is not imple‐
314          mented yet but should be soon!]
315
316       * DEVEL NOTES
317          ASCII tables are not yet handled but should be.
318
319          Binary tables currently only handle one vector (up to 1-D array) per
320          table entry; the standard allows more, and should be fully imple‐
321          mented.  This means that PDL::Complex piddles currently can not be
322          written to disk.
323
324          Handling multidim arrays implies that perl multidim lists should
325          also be handled.
326
327       For integer types (ie "BITPIX > 0"), the "BLANK" keyword is set to the
328       bad value.  For floating-point types, the bad value is converted to NaN
329       (if necessary) before writing.
330
331       fits_field_cmp
332
333       fits_field_cmp
334
335       Sorting comparison routine that makes proper sense of the digits at the
336       end of some FITS header fields.  Sort your hash keys using
337       "fits_field_cmp" and you will get (e.g.) your "TTYPE" fields in the
338       correct order even if there are 140 of them.
339
340       This is a standard kludgey perl comparison sub -- it uses the magical
341       $a and $b variables, rather than normal argument passing.
342
343       _rows()
344
345       Return the number of rows in a variable for table entry
346
347       You feed in a PDL or a list ref, and you get back the 0th dimension.
348
349       _prep_table()
350
351       Accept a hash ref containing a table, and return a header describing
352       the table and a string to be written out as the table, or barf.
353
354       You can indicate whether the table should be binary or ascii.  The
355       default is binary; it can be overridden by the "tbl" field of the hash
356       (if present) or by parameter.
357
358
359
360perl v5.8.8                       2006-08-19                           FITS(3)
Impressum