[Aavso-photometry] RE: Urgent Depth Question

[Kevin Kessler]

Oh, I can see how that is non-trival.  How do the pros handle this
situation, some sort of weighting depending on the percent of pixels
used in each image?

On Thu, 30 Dec 2004 09:31:48 -0700, Arne Henden <aah at nofs.navy.mil> wrote:
> Depends on how you combine the images.  Straight average would use
> the starting time of the first image and the ending time of the last
> image to calculate midpoint.  Any rejection algorithm, though, for
> removing bad pixels, cosmic rays, etc. influences the calculation.
> Say for example you combine three images, but the first one gets
> rejected consistently.  The midpoint is actually then between images
> number 2 and number 3.  In the normal case, each pixel can have
> a different midpoint time, depending on which image was rejected
> for that specific pixel.
> Arne
> 
> Kevin Kessler wrote:
> > What makes this non-trivial?  In CCDSoft, I combine all the files in a
> > directory.  I wrote a script for CCDSoft which then scans through the
> > FITs headers of the files in  this directory,  and finds the first and
> > last image, adds the exposure time to the last image, and finds the
> > mid-point between that time and the start of the first image.  Is
> > there something I'm missing?
> >
> > Is there some standard FITs header that the mid-point time should be
> > stored to?  According to an article I read
> > (http://www.cv.nrao.edu/fits/documents/standards/year2000.txt) , the
> > IAU stipulates that DATE-OBS is the time of the start of the
> > observation, which is what CCDSoft does, and why I had to write the
> > script.
> >
> >
> > On Thu, 30 Dec 2004 08:24:48 -0700, Arne Henden <aah at nofs.navy.mil> wrote:
> >
> >>Brad, be sure to tell Maxim/cyanogen about the error.
> >>Obtaining accurate midpoint time for stacked images is actually
> >>non-trivial.  If you have any kind of rejection algorithm, that
> >>modifies the center time.
> >>Arne
> >>
> >>Brad Walter wrote:
> >>
> >>>Bill you have hit on a point that causes me some embarrassment. There is
> >>>a problem with the times reported by Maxim/DL for the combined images.
> >>>I discovered that, when combining a series of images in Maxim/DL, the
> >>>program sets a time for the combined image equal to the time of the
> >>>series member selected as the reference for the combination, rather than
> >>>the earliest member. It also sets the exposure duration as the sum of
> >>>the exposure durations of the images being combined. Then the photometry
> >>>tool in Maxim/DL  sets the observation time for the corresponding
> >>>photometry data table record as the arbitrarily selected image time plus
> >>>half the summed exposure time saved in the header for that combined
> >>>image file. In my case there were 11 x 40 second exposures so the
> >>>exposure duration in the fits header of the combined file was 440
> >>>seconds, and the exposure time was shown as the time of the reference
> >>>image for the combination plus 220 seconds.  This is the same procedure
> >>>that maxim/DL photometry uses when reporting an un-combined image, and
> >>>it is correct for an uncombined image.
> >>>
> >>
> >>_______________________________________________
> >>Aavso-photometry mailing list
> >>Aavso-photometry at mira.aavso.org
> >>http://www.aavso.org/mailman/listinfo/aavso-photometry
> >>
> >
> >
> >
> 
> 


-- 
Kevin Kessler
www.sleepisoverrated.com