Basic image processing tasks: I/O, display, image arithmetic, image statistics, image display (1D, 2D, 3D).
Astronomical image analysis: surface photometry, stellar photometry, image simulation, Fourier analysis, spectroscopic reduction and analysis.
Packages vs programming.
Issues: availability, cost, philosophy, data handling (disk vs. memory), speed, ease of use (e.g., keywords vs. parm files), language and access to existing code, ability to add new code, scripts/ procedures (internal control language).
Much astronomical data is in the form of 2D images. It is critical to understand how to display such data and be able to see all of the information it contains. This is complicated by the fact that the dynamic range of your eye and most computer displays is smaller than that of most astronomical detectors. Most image displays provide only 8-bits of display range, giving only 256 possible intensities. Any image with more dynamic range must somehow be compressed into 8-bits before it can be displayed. This can be done either by sampling the true image coarsely, which allows viewing of the whole dynamic range but can lead to the apparent loss of intensity detail, or by fully sampling only a part of the true image range, which leads to the loss of ability to view detail outside the chosen range. Beware of packages which make this choice automatically; note that this ``convenience'' can lead to loss of apparent information, and also that manual choice of scaling levels assures that the user knows values of numbers in his/her image: something you should know to make sure that values are somewhere around levels that you expect! Image scaling parameters are generally specified by a low and a high data value (or a low value and a range) which give the limits in the true data which will be scaled into 8-bits.
Note you can also use a nonlinear scaling to sample a larger (or smaller) range. Example: logarithmic or square root scaling.
Once an intensity subsection is chosen, it can be displayed with any choice of ``color map'', which specifies the colors to be assigned to each of the display levels. These can be various shades of grey (greyscale) or some other color, or some arbitrary color scheme (pseudo-color). Note that most packages allow the user to manipulate the color table, allowing users to change the contrast and brightness of a displayed subsection; for this reason, it is usually reasonable to chose a range with a significantly larger range than 256 data values.
Most packages will allow the user to inspect individual data values based on a cursor location. Beware, however, of packages which give data readout based on scaling parameter and 8-bit display number only: these are unable to give correct values outside of the scaled region of the image.
Other useful display tools include zoom, blink, interactive image analysis (peak, valley, fwhm, etc), marking of objects, etc.
There are a number of ways one might consider storing a 2-D image in a disk file. Generally, since these images may be large, we are interested in formats which minimize the amount of disk space used and the amount of I/O time needed to read/write the images into memory. For this reason, images are rarely saved as formatted numbers; since the dynamic range of most detectors is at least 16 bits (-32768 to 32767), this would require at least 5 bytes per pixel, for data which is intrisically only 2 bytes of information. Consequently, images are generally stored as unformatted numbers. The binary representation of numbers can differ between machine types. Generally, however, most machines use 2's complement for integer and an IEEE definitiion for floating point numbers; machines differ, however, on the byte-order of these representations, with some architechtures putting the least significant byte first, while others put the most significant byte first.
Once a representation for the numbers is chosen, the values of individual pixels are simply dumped sequentially to a file. However, some additional information is needed to reconstruct these numbers into a 2d image. In particular, one needs to know the number of rows and columns in an image in order to properly wrap a sequence of numbers back into a 2D format. In addition, there may be additional information one wants to convey with an image, e.g., values identifying the scales and values along each axis, auxiliary information about how the image was obtained (exposure time, telescope used), etc. etc.
The standard file format for astronomical images is the FITS format. This format is described in a series of papers (refs: A&AS 44, 363; A&AS 44,371; A&AS 73, 359). Basically, a FITS file in its simplest form consists of two sections: a header section and a data section. The header section gives the required information to interpret and unwrap the data and also includes any optional information about the frame. This information is formatted in an arbitrary number of 80-byte ASCII records, each of which associates a value (integer, floating point, or character) with a predefined keyword; keywords can be up to 8 characters in length. Required keywords for FITS format are 1) SIMPLE = T or F depending on whether special extensions to the FITS format are used, 2) BITPIX, which gives the number of bits/pixel, telling the computer what format the data is stored in (16-bit integer, 32-bit integer, or 32-bit floating point). Note that FITS data by definition uses 2's complement or IEEE floating point with msb first. 3) NAXIS, which gives the total dimensionality of the image (since FITS can be used for 1-D images (spectra), 2-D images (single images), 3-D images (image stacks), etc. For image reconstruction from the file, the order of FITS pixels is that columns vary first, then rows. 4) a series of NAXIS[1-N] cards given the dimension of each axis., 5) an end card, which signifies the end of the header section.
Optional header cards include: CRVAL[1-n], CRPIX[1-N], CDELT[1-N], CTYPE[1-N] OBJECT, DATE-OBS (dd/mm/yy), INSTRUME, TELESCOP, OBSERVER, RA, DEC, EPOCH, COMMENT, HISTORY, etc. For arbitrary coordinate systems (e.g. RA/DEC, wavelength, etc.):
or for rotated coordinate system:
Often, BZERO and BSCALE and used for data value scaling for images in integer format to increase dynamic range:
Both the FITS header and the data section are padded with blanks (header) or zeros (data) to fill a multiple of 2880 bytes (which was done to insure compatability with machine types of essentially all possible word lengths). Consequently, a FITS file contains a set of filled 80-card header records, a set of blank records after the END card to pad to the next larger multiple of 2880 bytes, then the raw data in a byte stream, padded with zero's to provide an even multiple of 2880 total bytes.
A variety of software packages read/write FITS images, and several subroutine libraries have been made publically available to make it easy for you to do I/O with FITS images in your own programs (FITSLIB, others?). IDL also contains FITS I/O routines.
In the past, IRAF used its own internally defined data format, providing capability for converting between FITS and IRAF format, but all IRAF calculations (which, remember, are disk based), were done in the internal format. IRAF developers do not tell users what exactly the format of the IRAF files is so that they may reserve the right to change it in the future (with back-compatability). In recent versions of IRAF, it has become possible to use the FITS data format for all calculations instead of the IRAF internal format; I highly recommend using this (it is not the default unless you add something in your login.cl file).
FITS has gotten some extensions in the last several years which allow storage of more than just image data, in particular, tabular data where the different entries in the table may have different data types. FITS table files now come in both ASCII and binary formats, and increasing numbers of datasets are now being stored/distributed as FITS tables. Another FITS extension is for group files, which allow for multiple images in one file, each with its own header records, along with some common header records for the whole group.