[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fits Header Fix Progress
I have been working on the fits header.
At 01:58 PM 4/7/01 -0400, you (Michael Richmond) wrote:
> I'm trying the reduce the images on Disk 17. Here's what I've found
>concerning the FITS headers:
>
> 1. some keywords have changed (relative to old Mark IV keywords)
>
> CRVAL1 is now RA
> CRVAL2 is now DEC
> UT is now UTSTART
The plan is to put the same thing I am putting in RA into CRVAL1. Ditto
goes for the other items, just duplicate them so programs find things
wherever they look.
> Warnings for others who are using Disk 17:
>
> a. the RA value is in sexigesmial notation, formatted as a string:
> '13:03:43.4'
>
> b. the Dec value is NOT in sexigesimal notation, but is formatted
> as a string:
> '1 '
This has been fixed.
> c. the EXPTIME values have a significant scatter. What I mean
> is that the values in the FITS headers are (for example)
>
> 101.8, 101.4, 100.7, 101.6, 99.4, 100.2, etc.
>
> when one might have expected identical values of "100" in
> each case. This causes problems for me when I try to
> create master dark frames. I'd like to combine dark images
> with the same exposure times ... but no two images have
> (exactly) the same exposure time. Moreover, I'd like to
> use the 100-second darks to subtract from the 100-second
> object frames ... but again, the exposure times aren't
> all 100 seconds.
>
> I'm dealing with this by binning all exposure times to
> the nearest 10 seconds before I try to group frames together.
> It's a minor pain.
OK, I have rewritten the program to use the ON TIMER(t) feature of
QBasic. Once turned on it jumps to a subroutine every t
seconds. Unfortunately it can only be set to a minimum of one
second. Every second, I check to see how long the shutters have been
opened, and compare this to the desired value. This somewhat reduces the
uncertainty. It is not great.
1 69.98
2 69.47
3 69.53
4 69.53
5 69.64
6 70.40
7 70.08
8 71.46
The commanded exposure was 70 seconds. Note that #8 was a dark frame which
has slightly different code. This may or may not be significant. In any
case there is a minor improvement.
> Do we know if the variations are real? That is, was the
> exposure time for a frame which says "100.4" in the FITS
> header really 100.4 seconds?
We still have no way of knowing the real exposure. I think that what you
command is just as good a thing to use as what the program puts in the header.
> d. the IMAGETYP values are often incorrect. I found that
> the dark frames are misidentified:
>
> frame has IMAGETYP but is really
> -------------------------------------------------------
> 2747 dark object
> 2749 object dark
>
> 2763 dark object
> 2765 object dark
>
> 2779 dark object
> 2781 object dark
>
> 2795 dark object
> 2797 object dark
>
> 2810 dark object
> 2812 object dark
>
> Apparently, there's an "off-by-two" error in the assignment
> of IMAGETYP keyword.
This is now fixed. An initialization problem.
Tom Droege
> On another note, the V-band master flatfield (made from 34 object
>frames) shows small-scale features: blurry spots (perhaps due to
>spots on the lens?) and vague dark shapes near two of the edges
>(tree branches?).
>
> I'll continue to work on the data over the weekend.
>
> Michael Richmond
>
>
>
>
>