Because INDI is a full client/server implementation, multiple indi clients can communicate to the same indiserver and receive data from the same devices.

Passive mode allows you to setup a second (or third/etc) instance of indi-allsky to point to an existing camera being controlled by another instance of indi-allsky (via an indiserver). The first instance of indi-allsky has primacy, controlling exposure, gain, etc. The passive instance just receives all of the exposures requested by the primary server. The 2nd/3rd/etc instance of indi-allsky *thinks* it is controlling the camera, but I nerfed all of the exposure and gain controls so they have no effect.

I used this a lot when I was developing the stacking and stretching algorithms. I could connect my development environment to my production camera and have two separate processing pipelines without losing any data.

I have an Oculus mounted at the observatory but the software I'm using is not well adapted to all-sky use (it's not the Starlight Express S/W as they don't produce macOS S/W). This looks like a great solution.
waplus
projectfreetv.onl

Hi Aaron,

another perhaps trivial question. Sorry!

In the CLAHE algorithm description the description of tile size is a bit ambiguous. In the wiki it refers to "tileSize" being a default of 8x8. This suggests that the size of each tile is 8x8 (pixels I suppose). But then, below that, in the code fragment, the parameter is called tileGridSize, and has a value 8x8, so this suggests that the image is divided into an 8x8 set of tiles (so 64 in total). As the example image is not square, but rectangular, it implies that the tiles are also rectangular.

Which is the correct interpretation?

Thanks,
Richard

I have created the following wiki page with some instructions. Hopefully this can get you going.

github.com/aaronwmorris/indi-allsky/wiki/indi_pylibcamera-setup

Absolutely! Please let me know if you need any help.

That is actually a great question. According to the OpenCV docs, the image is divided into the set of tiles according to the tile size. I have never actually looked that closely at the docs until now, so comments in my code may be wrong.

docs.opencv.org/4.x/d6/db6/classcv_1_1CLAHE.html

OK, so looking at that, it's the latter.

Generally speaking our sensors are rectangular, while the all-sky image is circular (I have an excellent horizon so in my case it's almost completely circular). This means that the tiles will have different numbers in the up-down and left-right dimensions.

It probably doesn't matter, but it's good to know in case of artefacts -- my first use of the tool was completely clouded out and indeed there was a grid-like pattern in the noise, which must have been due to this.

Thanks,
Richard

This has been the primary complaint with the CLAHE algorithm. It can create a grid pattern as well as a "glow" at the boundary of the image circle (or above the tree line). Using a smaller tile size usually gives better results.

I failed to mention that you should upgrade indi-allsky to the latest version. I just merged an update necessary for indi_pylibcamera.

Thanks i resolved otherwise.

[Unit]
Description=Indi Server
After=network.target

[Service]
#User=masseris
#Environment="PATH=/home/masseris/indi-allsky/virtualenv/indi-allsky/bin:/usr/local/bin:/usr/bin:/bin"
#Environment="PYTHONPATH=/usr/local/lib/aarch64-linux-gnu/python3.11/site-packages"
ExecStart=/usr/local/bin/indiserver -v 7624 indi_pylibcamera
ExecStop=/bin/kill -TERM $MAINPID
RestartSec=5
PrivateTmp=true
UMask=0022

[Install]
WantedBy=default.target

Ettore

Hi Aaron,

would it be possible to have multiple instances of indi-allsky (I guess yes, but with a big memory penalty) or creating a multi-camera version of it to control more than one camera. I know you are not bored out yet creating new features for it

CS, Markus

This has been the primary complaint with the CLAHE algorithm. It can create a grid pattern as well as a "glow" at the boundary of the image circle (or above the tree line). Using a smaller tile size usually gives better results.

In my case I have a very nice, clear horizon. See the attached image:

The camera is mounted on a mast at the north-end of the east beam of the roll-off roof. Note that it's not focussed in this image.
I focused it the following night but it had to be closer to ground-level for that (see the next image) so the full horizon isn't visible.


You can see this annoying glow from the CLAHE algorithm in both.

Would it be possible to offer an alternative contrast enhance which just stretches the histogram, as in the first images in the CLAHE wiki? Then one could choose to use one or the other depending on the circumstances.

Thanks,
Richard

PS: the bright crescent-shaped thing at the top of the mast is the Hydreon rain sensor. This was the first time I'd seen that. It's not in the visible spectrum and must from IR LEDs used to make it work. I fooled me at first -- I thought it was Jupiter (which was nearby at the time) out of focus. I have another point about focusing, which I'll put in a separate post.