Skip to content

FAQ

Jump to bottom
Aaron W Morris edited this page Jul 24, 2023 · 47 revisions
Is indi-allsky a fork of Thomas Jacquin's Allsky?

indi-allsky is not a fork of TJ's Allsky. TJ's Allsky was the inspiration for some of the early settings and semantics, but indi-allsky is a completely unique all sky implementation.

It is extremely challenging to add additional camera vendor support to TJ's Allsky. A separate image capture program would have to be written for every camera vendor since TJ's Allsky directly manages the camera. I bypassed this challenge entirely by using INDI for the camera interface. indi-allsky is completely hardware agnostic and does not communicate directly with the hardware. The indiserver manages the hardware and indi-allsky is a standard INDI client which communicates with the indiserver.

I originally started indi-allsky in late 2020 to operate a the new Svbony sv305 color CMOS camera. INDI had recently released the svbony support.

What programming language is used in indi-allsky?

indi-allsky is written in Python 3. indi-allsky was started largely as an experiment to see if Python could even support running an all sky system. Python has a reputation for being slow, which is a valid criticism. In the case of indi-allsky, Python is really just the glue language. Most of the heavy computations are performed by Python modules with C/C++ bindings which greatly enhance the performance of the system.

Some of the modules with C bindings:

  • pyindi-client - INDI integration
  • OpenCV - Image processing
  • Numpy - Image/data processing
  • PIL - Image processing
  • PycURL - File transfers
Does indi-allsky support my camera?

indi-allsky supports more camera models than any other all sky software. The answer is almost always "yes" but there are always caveats.

Most astronomy/planetary cameras are well supported. (In no specific order)

  • ZWO (ASI)
  • QHY
  • Starlight Xpress
  • Player One
  • Touptek
  • Altair
  • Svbony

Canon DSLRs are also supported.

Most of the MIPI/CSI camera modules are supported with libcamera on Raspberry Pi 3+ SBCs only.

  • imx477 (RaspPi HQ Camera)
  • imx378
  • imx708 (Camera Module v3)
  • Hawkeye (64mp)
  • imx219 (Camera Module v1)
  • imx296 (Global shutter)
I have a camera that is supported by INDI but is not on your list.

Please open an issue and I will add the support. If you can connect the camera and connect it to the indiserver with EKOS, then provide the output of indi_getprop on the CLI, it would be helpful.

It usually only takes me about 15 minutes to add support for a new camera. I primarily just need to know how to configure Gain for the camera which is specific to vendors.

What cameras are not supported?

Even though these cameras are on the DO NOT USE list, it may still be possible to use them with the indi_webcam_ccd server. However, the cameras will likely be limited to 1 second exposure times and there is little control over image quality.

  • Avoid any MIPI/CSI camera module connected with a USB adapter.
  • Avoid USB web cameras
Can I use a Network IP Web Camera with indi-allsky?

Yes, it can work. The indi_webcam_ccd driver supports downloading JPEG images from a remote web server, eg a Network IP camera. indi-allsky cannot control the exposure or settings on the remote camera, the camera manages itself.

You may need to discover how to download JPEG data directly from your camera module. Below is a Reolink example.

https://github.com/aaronwmorris/indi-allsky/wiki/INDI-custom-config#webcam---ip-camera---reolink

Why do I need to compile INDI for libcamera support?

There is no hard requirement specifically for the cameras to function, however, indi-allsky makes use of the INDI virtual telescope driver to emulate the function of a camera on a mount. The data from the virtual telescope is used to determine where the camera is pointing in the sky (zenith is assumed for now).

You may also utilize the GPSd integration with INDI if you have a GPS adapter.

I made a setting change. Why did not take effect?

By default, when you click Save on the config form, the settings are only saved to the config file, but not applied to the running program. When you want a setting change to take effect, you must enable the Reload on Save switch before hitting Save.

Once you do this, it may take 1-2 minute before you see the results of the settings. All of the indi-allsky processes have to be restarted to take effect.

Why is my image green?

By default indi-allsky operates on RAW data from cameras. By nature, RAW data does not (and cannot) have white balancing included with the data.

Almost all color cameras have a color bayer pattern which includes one red, one blue, and two green pixel in each grouping. The two green pixels causes images to have a green bias. indi-allsky includes some SCNR algorithms that were documented by the PixInsight team. Maximum Neutral is the most commonly used algorithm to remove the green bias.

Why does it take indi-allsky 2+ minutes to complete a 60 second exposure?

This is a problem with libcamera and not indi-allsky. If you attempt to utilize Auto White Balance [AWB] with the Raspberry Pi camera modules at night, libcamera may end up taking several exposures internally to compute the correct color balance for each image. There is just not enough illumination at night for the libcamera algorithm to perform color balancing in a single exposure.

This problem only occurs at night, during the day, there is enough light for libcamera to perform its calculations in a single shot.

Does indi-allsky support non-Raspberry Pi hardware?

Yes. indi-allsky has been tested on many different ARM Single Board Computers [SBC]. Orange Pi, Banana Pi, Rock Pi, etc all work very well.

It is strongly encouraged to use an SBC with 64-bit ARM support and 2+ GB of RAM for the best experience.

Unfortunately, the Raspberry PI camera modules will only work with Raspberry Pi hardware. Astronomy planetary cameras all work fine with alternate hardware.

Clone this wiki locally