×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New All Sky camera management software: indi-allsky

  • Posts: 124
  • Thank you received: 28
Hi Aaron, perhaps I could help as I use SEP on python with FITS files as well:

I use astropy for fits handling:and the image is used like this:So I know that SEP needs float, but it should work. If you need further help, please let me know.
Michel
The following user(s) said Thank You: Aaron Morris
2 years 2 months ago #79005

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 18
It seems like the new Pi zero 2 W might be well suited to running indi-all sky, it might be a little memory starved (512 MB) for full up StellarMate but it is the same cpu as Pi3 so should be OK for this?
2 years 2 months ago #79013

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65
I believe the DMK41 is a v4l2 device.  My software will work with v4l2 devices, but there are caveats.

I have tested a couple of other v4l2 devices, mainly web cams.  None of the devices I tested had any adjustable gain settings (via INDI) and true exposures were limited to about 1 second.  Long exposures seemed to be simulated by internally stacking multiple frames together.  These cameras seem to be intended for video/planetary cameras and not really long exposure deep sky stuff.

I am willing to work with you if you want to do some testing.
2 years 2 months ago #79015

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65
If I get back around to testing SEP again I will reach out to you.
2 years 2 months ago #79016

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65
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.
2 years 2 months ago #79017

Please Log in or Create an account to join the conversation.

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.
The following user(s) said Thank You: Aaron Morris
2 years 2 months ago #79018

Please Log in or Create an account to join the conversation.

  • Posts: 123
  • Thank you received: 10
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
 
2 years 2 months ago #79033

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65
Sure, just make sure you disable the allsky service so there is no conflict with the camera.  You can always re-enable later.
systemctl stop allsky
systemctl disable allsky

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.   
Last edit: 2 years 2 months ago by Aaron Morris. Reason: Formatting
2 years 2 months ago #79037

Please Log in or Create an account to join the conversation.

  • Posts: 123
  • Thank you received: 10
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
Last edit: 2 years 2 months ago by Frank.
2 years 2 months ago #79039

Please Log in or Create an account to join the conversation.

  • Posts: 388
  • Thank you received: 17
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,
2 years 2 months ago #79040

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65
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.
 
 
2 years 2 months ago #79041
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 255
  • Thank you received: 65

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.
2 years 2 months ago #79044

Please Log in or Create an account to join the conversation.

Time to create page: 1.034 seconds