[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Database error estimates



I am working hard to take some good data where I track the sky for 2+
hours.  This will get about 50-60 images.  I know from past experience
that this will greatly reduce the relative error.  I don't see why it
makes any improvement in the absolute error.

However, I plan to bow to the requests of users and take data this way for
the "Official" run.  Everyone will like it better.

Rob's program looks like it will allow me to always take fixed tiles in
the sky.  I tried to do this before but it was just beyond my coding
abilities.  I am close to being able to measure how well I can do this.

>
>>>   The values stored in the database are calculated for
>>> each instrumental magnitude extracted from each image.
>>> They are based on simple photon statistics: an aperture
>>> of radius N pixels contains a total signal of E counts
>
>   Chris asked:
>
>> Is the aperture fixed at N pixels?
>
>   Yes.
>
>> Wouldn't it be better
>> if it were fixed at a constant angular diameter?
>
>   No, I don't think so.  A constant angular diameter
> would mean a radius which gets _smaller_ (in pixels) towards
> the corners.  The FWHM tends to get larger (in pixels)
> towards the corners.  So an aperture of fixed
> angular size would give the same number of
> electrons in the background for all stars (good)
> but provide a smaller fraction of the total stellar
> signal for stars near the edge (bad).
>
>   The constant-pixel-size aperture gives a larger
> background contribution for stars near the edge,
> but also contains a less-variable-fraction of the
> stellar signal across the frame.  I think, on the
> whole, that's better.
>
>   Tech Notes 51, 52, 59 and 63 show in various ways
> how the PSF shape and size change across a Mark IV
> frame, and some effects on the photometry through
> a fixed aperture.
>
>> If someone would send me the terms of an X,Y to RA,.DEC
>> Nth order transform I'll work out the size of the error
>> I'm sure this transform must be a byproduct of the pipeline
>> and the numbers are available.
>
>   I do not have these transformation values handy;
> all my old Mark IV analysis data was lost when some
> disk drives died a while back.
>
>
>                                  Michael
>
>
> =====
> Chris Albertson
>   Home:   310-376-1029  chrisalbertson90278@yahoo.com
>   Cell:   310-990-7550
>   Office: 310-336-5189  Christopher.J.Albertson@aero.org
>   KG6OMK
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
>
>
>