If I get back around to testing SEP again I will reach out to you.

The Pi Zero is perfectly fine for just taking images, but I think generating timelapse videos will be a problem.  CPU power is not really a limiting factor, but memory is.  The downside of using python is it typically requires more memory than a more optimized C based program.  The 4 python processes spawned to run indi-allsky can easily take 400-500MB of RAM.

I have found that for 1K video (1920x1080) even with 1GB RAM (no swap) of memory you may end up with out-of-memory conditions where the linux kernel will kill the running ffmpeg process.  You need at least 100-200MB of swap in addition to complete the timelapse.

Memory usage of ffmpeg seems to scale fairly linearly with the resolution.  1K video requires ~512MB, 4K video will require 4x as much memory (2GB+) as 1K video.  If you scale 1920x1080 images by 50%, you might be able to get ffmpeg usage down to 256MB.

github.com/aaronwmorris/indi-allsky/#gotchas

As an alternative, you could use my software remotely from the Raspberry PI.  indi-allsky is just an indi client and can connect to remote indi servers over the network from a more powerful workstation.  There is a command line option in my software to connect to a remote indi server.

Thanks Aaron, feel free to update the article here: indilib.org/research/projects/197-indi-a...-record-the-sky.html

You should have access to it since I set it as the author.

Hello,
Aaron, do you think I can install your soft on the same Raspberry who has the soft of Thomas Jacquin ?

The configuration :
i@allsky:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="www.raspbian.org/"
SUPPORT_URL="www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="www.raspbian.org/RaspbianBugs"

Frank
 

Sure, just make sure you disable the allsky service so there is no conflict with the camera.  You can always re-enable later.

The web server will still have the authentication configured, but I do not think that will interfere with operation.

Early on when I was developing my software, I stopped allsky but forgot to disable.  When I rebooted it started automatically and I did not realize it.  Both pieces of software ran fine concurrently during the day because the exposures were so short, but as soon as night rolled around and the exposure times went up, things went haywire.   

Ok, great !
I'll do that this weekend.
Ok to stop the Allsky before .
Your function to detect the clouds is very interesting
Have a good day,
Frank

I am interested in your project, I have been running my own modified version of Thomas's software on a Rpi 3B with a ZWO camera, for several years. In my version of the software I make use of darks, to remove hot pixels, and stretching algorithms to bring out the most in the images. I have found that I need to take darks over a range of temperatures, because the hot pixels for my ZWO camera depends on the camera temperature. And in order to cancel them out I have to match both the exposure time (which I fix) and the camera temperature when the image is taken.
Can you briefly outline how you handle darks and any additional image processing.

thanks,

This is a screenshot from my mono camera tonight.  The stats on the lower right corner are queried from the sqlite DB and overlayed by the HTML page (not written to the image).  Every image stored in the DB has a brightness calculation (jSQM) performed and number of stars detected.  I have found that the brightness calculation is by far the best metric for objectively measuring sky quality.  Clouds will instantly register as an increase in brightness.  Counting stars is interesting, but the number of stars can vary, and things like air planes can throw off the stats very easily.
 
 

Currently, the code will take darks at the 3 different gain settings for day, night, and moon mode.  Darks are matched to the gain level, obviously.  The minimum dark exposure is 1 second and all subsequent dark exposures are at 5 second intervals until the maximum exposure time defined in the config.  Any exposure of 1s or less uses the 1s dark frame and all other exposures uses the next highest exposure level.  For example, a 13s exposure would use the 15s dark.

I have not found temperature matching to be especially critical.  As long as the darks are taken at the same or warmer temperature, they usually work pretty well.  I usually take my darks after dusk, which is usually the warmest part of the night.  I also retake darks once or twice a year, like summer and winter.  If you have a permanent all sky camera, they will develop new hot pixels occasionally.

As for stretching, I do not have anything like that right now, but I am very interested in adding this.  I have not been successful in researching a good algorithm for stretching.  If you have any examples, I would be more than happy to take a look  at those.

I also update my darks a couple of times a year. I take them using a fridge to reach the desired temperature, I usually take them every few degrees. I image at a fixed gain (50) and exposure (I use 12 seconds as I find that is long enough to pick up faint stars and yet not produce noticeable star trails), so I only need to match the dark to the camera temperature (I store the temperature in the Dark Frame Name, so it is easy to search on and find the one closest to the image temperature). I have ImageMagick loaded on the Rpi and run command line routines like "level" and "brightness-contrast" to sort of stretch the image. All of the image storing and processing routines are run in shell scripts that are called from subroutines in the main capture.cpp (C++) program.

I have thought about changing the camera (ZWO ASI 120MC) parameters when the moon is out, but I have not found camera settings that deal with a bright moon and can still image stars. I will look into how you are dealing with this. I also like the idea of determining sky brightness and logging this with the AP images I take with my telescope, on the same night. It may help set my expectations when I process the images.

I have had a lot of fun with the AllSky camera project over the past 3 years, it is probably time I did some updating of the program and equipment. I am on my second Rpi as the USB ports on the first one stopped working after about 2 years outside (the Rpi and camera are in a water tight junction box container with the usual plastic dome.)

So thanks for providing an alternative approach.

I have just completed development of fully functional web interface for indi-allsky.  The camera can be fully managed via the web interface with minimal interaction from the CLI.  Indi-allsky is now basically at feature parity with Allsky.

The interface is built on Flask so there is a unified Python code base for both managing the camera and viewing the images.  Since I use a database to store image and sky metadata, one of the cooler features is the charts function.  I have a view that shows recent sky conditions.  Things like brightness (jSQM) and star counts are graphed in realtime.

In this picture, it was early evening, twilight.  A cloud passed by showing a temporary increase in average brightness and a decrease in star counts.


 

Hello,
I've tried to install the indi-Allsky but...
I would like to install on my installation of Stellarmate (to use both).
The installation is correct until "Start the program" /home/stellarmate/indi-allsky

It's probably an error of path, isn't ? How can I do to solve this problem ?

Thank you