[fitsbits] exposure time - resolution

Tom Kuiper kuiper at dsnra.jpl.nasa.gov
Mon Jun 5 18:09:02 EDT 2000


> Date: Mon, 5 Jun 2000 13:42:40 -0700
> From: Steve Allen <sla at ucolick.org>
...
> On Mon 2000-06-05T12:01:36 -0700, Tom Kuiper hath writ:
> > looking for a keyword that apparently doesn't exist, but could be named
> > something like CRESLx, which would be the full width at half maximum
> > of the instrumetal response along the coordinate x.
> 
> What meaning should be used if the resolution of the instrument is
> much smaller than one pixel; i.e., the pixels are huge?

I don't think the size, per se, of the pixel is an issue.  Undersampling
is a good strategy if the instrumental response is well known and you
want to extract more resolution from the data.

> This could be relevant in situations of low S/N where binning of
> a CCD is done on the chip during readout.

In this case, the response becomes increasingly rectangular as the number of
bins increases, and the pixel size is easy to define.
> 
> In such a case the resolution in the FITS file has a bin-like profile
> that doesn't match the Gaussian-like FWHM notion.

Which raises the issue that, in addition to specifying the pixel size, the
response function shape needs to be specified.  I can see where this is
heading towards a tar pit.  That should not discourage us from settling the
simpler cases.
> 
> In the more general case of binning during data processing, how
> should such a keyword be redefined if the binning is done
>       by averaging pixels?

In this case, the instrumental response is modified in a way that is
computable, because one convolves the original response with a smoothing
function.  Thus, the half-power full-width is still defined.

>       by sampling pixels?

In this case, if I understand you correctly, the response function is not
changed.  Data are simply thrown away. (Why would you do that?)

The worst case imaginable is one where the instrumental responses on two
or more axes are not independent, and different from pixel to pixel.
In that case, one would have to provide an additional data cube to
provide these data.  I think IRAS had something like that.  Fortunately,
I don't have to deal with that.

So to stick with simple cases, let me modify my original suggestion that
there be a keyword CRESLx and another one CRESFNx where the latter would
have such values as "gaussian", "sinx/x", "rectangle", "triangle". etc.
or else a pointer to array giving the response data, assuming it to be the
same for all pixels.

Cheers

Tom
--
Internet:       kuiper at DSNra.JPL.NASA.gov (137.79.89.31)
SnailMail:      Jet Propulsion Lab 169-506, Pasadena, CA 91109
Phone/fax:      (818) 354-5623/8895
WWW:            http://DSNra.JPL.NASA.gov/~kuiper/



More information about the fitsbits mailing list