Average date time of integration frame

[pk825]

In the integration frame Pixinsight puts in the header the average time of the integrated frames. But, if I correctly analyzed it, it puts the average between the start data time of the first frame and the start data time of the last frame. For my astrometry analysis is correct, instead, to use the average of the start data time of the first frame and the end data time of the last frame.
Is it possible to have this information in the header?

[ngc1535]

I just want to point out that if you have a single frame- what would you choose as the "average date time?"
Wouldn't you take the average of the start and end times? This would be the Midpoint. So... perhaps you should go from the midpoint of exposures in general?
In any case, you could read the times from a list of files into an array and do the appropriate math such as what you mentioned. In python for example
astropy has a set of methods to manage FIT files and do this kind of thing easily (read the headers).
-adam

[Juan Conejero]

In the integration frame Pixinsight puts in the header the average time of the integrated frames. But, if I correctly analyzed it, it puts the average between the start data time of the first frame and the start data time of the last frame. For my astrometry analysis is correct, instead, to use the average of the start data time of the first frame and the end data time of the last frame.
Is it possible to have this information in the header?

Your analysis is correct, ImageIntegration computes the average acquisition time from exposure start times, ignoring exposure durations. A difference of a few minutes (at most, usually much smaller) is completely irrelevant for calculation of star proper motions, so this cannot have any impact on astrometric solutions computed for the integrated image.

However, for ephemeris calculations the difference can be significant at the arcsecond level, which may be important for measuring object positions on the integrated image. I'll change the way this metadata is generated in the next version of the ImageIntegration tool, by computing the midpoint between the first starting time and the last starting time plus its corresponding exposure time—or if the DATE-END keyword is present, which unfortunately happens rarely, its value will be used instead.

Thank you for pointing out this issue. I'll try to release an update to the ImageIntegration module with these changes implemented as soon as possible.

[Geoff]

Doesn’t the reference frame used for star alignment play a role here? If, for example, everything is aligned to the first frame shouldn’t the time of that frame be the most important?

[Juan Conejero]

Suppose you have recorded an asteroid in the data set, whose position with respect to the stars changes from frame to frame. Typically, it will be rendered as a small arc on the integrated image. The middle of this arc will represent the asteroid's position at the average acquisition time, calculated as we have described in the previous posts. The starting and ending points of the arc will correspond to the starting and ending acquisition times, which should be represented as the DATE-OBS and DATE-END FITS keywords in the integrated image, as well as the 'Observation:Time:Start' and 'Observation:Time:End' XISF properties. This is what I plan to do in the next version of the ImageIntegration tool. These changes should also imply new changes in some scripts, the AnnotateImage script in particular, which should use these keywords and properties to generate renditions of solar system objects.

[pk825]

In the integration frame Pixinsight puts in the header the average time of the integrated frames. But, if I correctly analyzed it, it puts the average between the start data time of the first frame and the start data time of the last frame. For my astrometry analysis is correct, instead, to use the average of the start data time of the first frame and the end data time of the last frame.
Is it possible to have this information in the header?

Your analysis is correct, ImageIntegration computes the average acquisition time from exposure start times, ignoring exposure durations. A difference of a few minutes (at most, usually much smaller) is completely irrelevant for calculation of star proper motions, so this cannot have any impact on astrometric solutions computed for the integrated image.

However, for ephemeris calculations the difference can be significant at the arcsecond level, which may be important for measuring object positions on the integrated image. I'll change the way this metadata is generated in the next version of the ImageIntegration tool, by computing the midpoint between the first starting time and the last starting time plus its corresponding exposure time—or if the DATE-END keyword is present, which unfortunately happens rarely, its value will be used instead.

Thank you for pointing out this issue. I'll try to release an update to the ImageIntegration module with these changes implemented as soon as possible.

Thank you very much, I need it for asteroid astrometry analysis and an automatic way to get this information will help me to avoid mistake.
Pixinsight is a great software and your job is great 

[pk825]

Any news about the ImageIntegration module average time issue?