Alright, at the risk of sounding like a broken record and drawing the
ire of the community, would someone be willing to look at a couple of
files that I have and please explain what is occurring? I'm using 3
programs to check the information: 1) SAOImage DS9 2) FV 3) Graphic
Converter. All 3 programs display clearly visible images. . .some
pictures of stars, others of the moon, and others of what I'm guessing
are "gas" clouds.

As per LCNoSpam's post, I'm pretty sure it is a matter of Case "a".
I've got my program parsing out the header data just fine. But the
raw image data is useless to me unless I know how to interpret it.
The required header values are present (e.g. BITPIX, NAXIS, etc.), but
I still don't fully understand the interpretation.

Again, my apologies for the repeated post, but I'm absolutely in need
of help. I've read more documentation than I care to recount, but my
head is still not wrapping around the handling of the actual images
aspect of this project.

Best Regards,
Michael


On Aug 27, 5:48 am, LC's NoSpam Newsreading account
wrote:
On Fri, 24 Aug 2007, Michael Williams wrote:
valid FITS files all formatted completely differently. [...] the most
common "formats". Can someone send me (offline or otherwise) some
sample data with accompanying comments/markup regarding what each
piece of data means?

You can do this better by yourself. On one hand grab a copy of the FITS
standard fromhttp://fits.gsfc.nasa.gov/fits_home.html(there is even a
draft of the most recent revision, which does not change really the
format, but has maybe clearer explanation), on the other way consult the
archives of the major ground observatories (ESO, NOAO, NRAO) and of the
major space missions (NASA and ESA).

FITS compliant header followed by. . .

All headers I know are "compliant" ... what you should get from the FITS
standard is the list of : mandatory keywords which appear in ANY header
of a given sub-type (*) ; reserved keywords which, when they appear,
must be used as prescribed in the standard ; other keywords which
essentially can be considered of commentary or specific nature (cfr.
e.g. the convention registryhttp://fits.gsfc.nasa.gov/fits_conventions.html)

I am not sure what you intend to do. I suppose some sort of new general
purpose tool. Probably you should concentrate on interpreting the
mandatory keywords, and some of the reserved keywords, and ignore all
the rest (even if not of commentary nature, might be useful only for
some project specific piece of software).

(*) by sub-type I mean here the various kinds of extensions :

a) primary HDU with image data and IMAGE extensions
b) binary table extensions
c) ascii table extensions
d) primary HDU with random groups
e) anything else

Let me first say that (e) is extremely unfrequent (that would mean
conforming extensions not part of the standard, which at present is only
the FOREIGN extension, which is a way of wrapping non-FITS stuff in a
FITS file used at some places), so you'd just ignore it.

I'll then add that (d) is an old format, now deprecated, and used
essentially only by radio astronomers. I guess it is unlikely you'd
encounter it unless you look in the archives of radio observatories.

Now for your classification

1) binary data
3) array's of numbers

I'm not really sure where you draw the difference here. I suppose one
case may be my "a" and another my "b", or perhaps "c". See further
below.

2) non-compliant header-like text

I am not sure what you mean by this too. Whether you mean "c" (ASCII
tables ... look printable text but not in header format), or whether you
mean some kind of headers (ESO HIERARCH convention perhaps ? looks odd
but is compliant !).

Essentially what I say is that it is my a/b/c classification which makes
sense (and unfortunately is not enough).

(a) the case of images is possibly the simplest. It may occur in the
primary HDU, or in XTENSION='IMAGE' extensions. The data which
follows is a binary n-dimensional array A(i,j,...). In most cases
a 2-d image A(i,j), in some cases a 1-d array A(i), in some other a
datacube etc.

In most cases of the 2-d images they are sky images (and data cubes
are stacks of sky images), but can be anything (also in some cases
they are actual detector images, they may be something different,
consider e.g. a multi-object spectrometer).

The default action here is to display a 2-d image with some false
colour mapping. On the X and Y axes just put "pixels".

If the header has WCS keywords, these would allow to map pixel
coordinates to sky coordinates OR OTHER "world" (physical)
coordinates. Rather complex to handle.

Example handling program is ds9.

(b) the case of binary tables is nowadays probably the next most diffuse
but comes in a large number of varieties. First of all it always
comes as an extension, so you have a dataless PHDU and an extension
header.

The data are a binary array with a number of rows, and a number of
columns of DIFFERENT data types. To further complicate things,
a column may have a depth (see the TFORMn keywords). To further
complicate things, this depth way be constant, or variable (in
which case the cell contains pointers to data in the HEAP, see
the P and Q TFORMn)

Here I'd say that the typical "generic" action (example handling
program is fv) is to produce a tabular printout of the content
(optionally a plot of one column vs another ... but this can be
chosen only interactively). With some special action for large
or variable depth cells.

Some reserved optional kwds can be used to annotate the column
with a title or plot label, with physical units, with a recommended
display format ...

This format is widely used for lots of different things : a
catalogue of sources, or any database ; a spectrum (but sometimes
spectra are formatted as 1-d images) ; a time series ; a photon
list or even more complex things like the RMF (Response Matrix
Function) of an high energy detector.

... and of course a file may contain many different extensions.
You should consider each one as independent.

(c) the case of ascii tables is nowadays encountered mainly in older
(or old-style) archives, typically of catalogues. The data is
written in fixed-length ASCII record (so it appears printable).

It is simpler than binary tables (columns have always depth one)
but for the rest it shall be displayed similarly.

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.