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

Just WOW! This is getting better and better, I must try this in the observatory. Got a couple of wide angle cameras perfect for this purpose. Awesome work Aaron, this is shaping up to be a fantastic INDI project.

Hello Jasem,
Have you an idea about my problem of installation ? See previous message.
Thank you,
Frank

I did, I checked the script and it needs modifications to work with StellarMate. I'll take a look at it later.

Ok, thank you !
Have a good day,
Frank

It looks like my setup.sh script did not complete successfully.

I have never run StellarMate, so I am not sure what interactions there may be.  I seem to remember from other posts that StellarMate may use lighttpd where I use Apache.  I do not have a hard requirement for using Apache, it is just one I am most familiar with.

Let me do some research.

No lighthttp, just nodejs running on port 3000, but port 80 is forwarded to 3000 by default.