On Thu, 23 Oct 2008, David Berry wrote:
> 2008/10/22 Peter W. Draper <[log in to unmask]>:
>> On Tue, 21 Oct 2008, Brad Cavanagh wrote:
>>
>>> On Oct 21, 2008, at 6:36 PM, Tim Jenness wrote:
>>>
>>>>> Now for the header overwriting problem: If I use the Image
>>>>> analysis->Astrometry calibrations->Fit to star positions with a DSS2
>>>>> reference image to perform a astrometric calibration of my image
>>>>> (which works fine) and then write the image out under a new name, the
>>>>> DATEOBS keyword is rewritten with a new date/time (diffing the before
>>>>> and after header dumps, original first): < 14 | DATE-OBS=
>>>>> '2008-10-21T08:58:10.216' / [UTC] The start time of the observation
>>>>> ---
>>>>>> 14 | DATE-OBS= '2000-01-01T11:58:55.816'/ Date of observation
>>>>
>>>> I agree that changing the value of DATE-OBS is very naughty and
>>>> should not happen simply by updating the star positions. I assume
>>>> this is because the frameset created by the astrometric fit does not
>>>> explicitly have the date stored as an attribute so AST inserts the
>>>> current value. Not sure if this is a gaia thing or an autoastrom
>>>> thing but the frameset needs to be given the real dateobs either
>>>> during the calibration or just before the new header is created.
>>>
>>> I'll have to look closely at what autoastrom is doing here. It looks
>>> like ASTROM can take an observation time, and I'm not sure if a) this
>>> observation time is obtained from DATE-OBS when going through
>>> autoastrom, or b) the resulting FrameSet from ASTROM has the current
>>> date in it regardless of the result of a).
>>
>> Brad,
>>
>> don't think TimL is taking about autoastrom here, just the old-style
>> astrometry fitting toolbox in GAIA. That does show this behaviour, but
>> after a look I think this is an AST issue.
>>
>> David,
>>
>> when I feed the following headers through a FITS channel:
>>
>> WCSAXES = 2 / Number of WCS axes
>> CRPIX1 = 297.0 / Reference pixel on axis 1
>> CRPIX2 = 297.0 / Reference pixel on axis 2
>> CRVAL1 = 187.704557 / Value at ref. pixel on axis 1
>> CRVAL2 = 12.390742 / Value at ref. pixel on axis 2
>> CTYPE1 = 'RA---TAN' / Type of co-ordinate on axis 1
>> CTYPE2 = 'DEC--TAN' / Type of co-ordinate on axis 2
>> CDELT1 = -2.8E-4 / Pixel size on axis 1
>> CDELT2 = 0.00028 / Pixel size on axis 2
>> DATE-OBS= '1992/02/03' / Date of observation
>>
>> and extract the frameset (simple ATOOLS:ASTCOPY), all the epoch values are
>> set to 2000.0 (which is the DATE-OBS value seen above), not 1992.xxx. In
>> the absence of an MJD-OBS, I thought DATE-OBS would be used as the epoch?
>> The "Paper II - Celestial Coordinates" section of SUN/211 implies this (in
>> the MJD-OBS section).
>
> It can. The problem here is that the DATE-OBS value uses "/" as a
> field separator, which indicates that the "old" format is being used
> in which the the first field is day, second field is month, and third
> field is year. The new format, in which the fields are in "year,
> month, day" order is indicated by using a "-" instead of a "/" as the
> separator. See
>
> http://www.cv.nrao.edu/fits/documents/standards/year2000.txt
>
> In this particular case, the four digits in the first field is a bit
> of a give-away, but the answer is presumably to fix the headers,
> rather than add more leniency to AST.
Thanks, yes that explains it. Since there is a standard I agree we should
stick to it, that's unless this practice is in wide use. In that case we
should try to take the pain, not our users.
TimL, so the answer to this part has two elements.
- The FITS headers are non-standard, so will not be processed anyway.
- however, I've also uncovered a bit of misbehaviour in GAIA, so even if
they were correct you'd have still seen this problem!
The latter issue is now fixed.
Thanks,
Peter.
|