Store exact time stamp of exposure start

[hdiessner]

Hi Thomas,
Again, great piece of work! And I have an issue or feature request that might be of interest for all meteor & fireball chasers: is it possible to store somewhere the exact time stamp of the start (or end) of an exposure?
I measured the latency between a picture taken and when the file was stored on the SD card. My system has a lag of 8 seconds. Perhaps you can save the start exposure time in the EXIF header of the picture or, if that is too much of additional work just save it in a separate text file with the same filename of the png or jpg file?
The reason behind why I am asking is a really great one: After only 8 weeks of continuous operation of the allsky cam, I was lucky enough to record a big fireball. And the DLR - the german NASA - contacted me as they are interested in my pictures, but they need the exact timestamp to improve the calculations of the trajectory of the fireball!
I managed by taking some pictures of an atomic clock watch in front of my allsky lense. This way it was easy to find out the latency.
But if there was a source file with the exact time stamp that would be much more efficient and would be definitely helpful for any future fireball recordings!

[ckuethe]

It looks like the imwrite function does not support any exif data, and that an separate EXIF library would be needed...

And now that I think about it, it sounds like a great idea to integrate EXIF support:

• Capture timestamp
• Exposure duration
• Camera model
• Image gain
• GPS location
• Sensor temperature
• gamma
• and all that other stuff.

I might try my hand at implementing this - what quantities would you want to see in the EXIF data?

[hdiessner]

For meteor detection, capture timestamp, exposure duration and GPS location should be sufficient. But the other data might be of interest for other future use cases. Perhaps, once the function of saving EXIF data to the picture is implemented, it might be a good idea to store just about any data that is available and that can be stored in EXIF.

[ckuethe]

I found your latency! There is ... some suboptimal behavior around capture.cpp:766 with regard to the capture delay. It took a while for the penny to drop, but it was super suspicious that my daytime capture interval was 15 seconds, and my night time captures were being saved every 15 seconds even when the integration time was 6500ms and the night time delay was 10ms (eg. ASAP)

For now I patched this by adding useDelay = delay; before the ASISetControlValue() calls; I'll have to think about a better fix.

[cbassa]

For storing meta data, it would be possible to add a writer for the FITS image format. FITS (Flexible Image Transport System) is a data format used by astronomers for storing images with the necessary meta data (timestamp, exposure length etc). In principle this could be added to capture.cpp using the CFITSIO library (https://heasarc.gsfc.nasa.gov/docs/software/fitsio/). Using CFITSIO in C is a bit cumbersome, and for my own all sky camera I'm using a python script mimicking capture.cpp but saving FITS files using the astropy library (https://github.com/cbassa/asm). My goal is to calibrate the astrometry of the images and detect meteors and satellites and measure their positions.

Has there been any discussion in moving capture.cpp and some of the bash scripts to python?

[EricClaeys]

This issue is from an older release of the AllSky software. If you think it might still be relevant, please submit a new issue. Thanks.
Version 0.8 names the permanent file with the starting time, e.g., images/20210910/image-20200910183714.jpg. That might not exactly what you're looking for, but should be closer.