Jump to content

Canada's top-tier Telescopes & Accessories
Be as specific as possible when reporting issues and *ALWAYS* include the full version number of the application you are using and your exact *CAMERA MODEL*
NEVER POST YOUR KEY IN ANY PUBLIC FORUM, INCLUDING THE O'TELESCOPE SUPPORT FORUM ::: IF YOU DO YOUR KEY WILL BE DEACTIVATED WITHOUT NOTICE!
  • 0

Timestanp interpretation- image meta or file title?


Coop

Question

I ran a sequence for the Lunar Eclipse on 1/20 just as an experiment to build a time lapse video of the event. It turns out that there was a confirmed meteor impact at 22:41:38 CST which was during my capture program. I have having real challenges location the images due to discrepancies on the actual image file info (re: created 10:41 pm CST) v what the file name indicates (re: 22hr 41mn 38sec). They don't align and are off by at least 10 or  more minutes.

To help in my search for the range of photos, which time is the actual time for a baseline. I'm not concerned if there a few second delay but a 10-15 minute range presents a much great challenge in searching for any sign of impact, even I even was lucky enough to capture it.

Link to comment
Share on other sites

5 answers to this question

Recommended Posts

  • 0

My camera clock WAS off by 90 minutes- weird number and no idea how that happened. But that is easy to control for by doing the simple math to get it to the time I started the program. I have attached a screen that shows the file info from the image itself (I am assuming that this reflects camera time since it does when I'm offloading images outside of Backyard EOS); in the top file index info there is another time in hr/min/sc/ms which I presume matches my computer clock. My computer clock is accurate

This image shows file info of 11:31 pm

The index info shows 22hr11m32s392ms or ~10:11 pm

The more I look at this the more the file index info appears to be correct. It also corresponds with how the Moon should have appeared at that time. So I think I've solved the problem and I thank everyone for the input. 

Now my challenge is the way WIndows is sorting the images. There is no rhyme or reason and it is not by time but instead by variations in the file index info that does not correspond to a chronological order. So I can narrow my search but I'll be jumping around a bit.

Thanks again for the input

Moon Screen.jpg

Link to comment
Share on other sites

  • 0

I'll wait for Guylain to comment on the internal workings of BYE.

But, the first thing to suggest: 

Check the Camera's Internal Clock.  Is it perhaps the source of your 10-15min discrepancy??

And:  Did you mean to describe a discrepancy in your example - which actually had equivalent time values??

Quote

discrepancies on the actual image file info (re: created 10:41 pm CST) v what the file name indicates (re: 22hr 41mn 38sec)

 

Link to comment
Share on other sites

  • 0

There's no real magic here... BYE uses the PC date/time at the start of the image capture, not the end and not the image file creation time.  There is really no other alteration to that date.  Is your computer date/time correct?

What do you mean by file info?  From right click / properties in Windows?  This is the computer date and set by Windows when the file is created.  If this matches the date/time that BYE's puts into the file name then that confirms that the date BYE put in the file name comes from your computer and if that date is off than your computer date is off.

Hope this makes sense.

Regards,

Link to comment
Share on other sites

  • 0

So the first thing to realize is that times that are added to the image metadata by the camera use the camera's clock time which may not be very accurate. Most of those times in the metadata that are put there by the camera represent the start time of the image. FileModifyDate is for the end of the image. If the camera's time was accurate you should be able to use them to see if caught the meteor.

The Backyard... metadata entries are added by BYE after the image has been downloaded to the PC, so BackyardCaptureDate represents the PC time when that occurred.

The timestamp field in the image file name is the PC time when the image capture of that file started.

I did not know this, but got it after taking a single long exposure and looking at the times.

Link to comment
Share on other sites

  • 0
2 hours ago, Coop said:

My camera clock WAS off by 90 minutes- weird number and no idea how that happened. But that is easy to control for by doing the simple math to get it to the time I started the program. I have attached a screen that shows the file info from the image itself (I am assuming that this reflects camera time since it does when I'm offloading images outside of Backyard EOS); in the top file index info there is another time in hr/min/sc/ms which I presume matches my computer clock. My computer clock is accurate

This image shows file info of 11:31 pm

The index info shows 22hr11m32s392ms or ~10:11 pm

The more I look at this the more the file index info appears to be correct. It also corresponds with how the Moon should have appeared at that time. So I think I've solved the problem and I thank everyone for the input. 

Now my challenge is the way WIndows is sorting the images. There is no rhyme or reason and it is not by time but instead by variations in the file index info that does not correspond to a chronological order. So I can narrow my search but I'll be jumping around a bit.

Thanks again for the input

Moon Screen.jpg

Glad you got it figured out.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

This site uses cookies to offer your a better browsing experience. You can adjust your cookie settings. By closing this banner, scrolling this page, clicking a link or continuing to browse otherwise, you agree to the use of cookies, our Privacy Policy, and our Terms of Use