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.

The short answer is: maybe. However, both instances would probably not be unified. You would have to have a separate flask config, separate web interface for each, a separate database, etc. indi-allsky can be pointed at a different flask config via the INDI_ALLSKY_FLASK_CONFIG environment variable. The flask config is where the database and migrations configuration lives. I think they could live independently, but there could be some gremlins I have not considered.

A better way of doing this would be using docker and running each camera from a different set of containers. This would have a different set of challenges because there are some hard coded references to a single set of containers in the docker build.

I had one person run one camera directly on a Raspberry Pi and then run the second camera from a docker container on the same Raspi.

At one point, this was kind of a dream of mine, to run multiple cameras from the same installation. In the end, I decided the added complexity would not be worth it for functionality very, very few would ever use.

Personally, I am not a big fan of the CLAHE algorithm, especially at night. During the day when it is cloudy, it is more impressive.

Stretching is your alternative. The algorithm I have clips the black point based on X standard deviations from the average. Reducing the standard deviations increases the dynamic range of the output (a more aggressive clip). It is best to use this with a detection mask where you can manually blank out areas to exclude from the calculation. Otherwise, the SQM FoV (Processing tab, default is central 50% of image) is used for the calculation area.

I now have a question about how to drive Focus Mode. There is very little in either the wiki or the web pages, so I relied to make it work.

I switched on Focus Mode on the camera tab, and set download to 1 sec, as my camera is supposed to support that (though today when making darks I got constant messages that download times were between 4 and 16 sec (approx) and this might be a camera fault).

I didn't see any metric for focus sharpness on the image. I looked in Tools and found Focus. That presented me with 4 text boxes (Refresh, Zoom, X offset and Y offset) and a small, empty black rectangle. Refresh was a drop-down menu with a few values between 2 and 15 sec. It didn't seem to have any effect on whatever followed. Zoom had a range of descriptive values, which also had no discernible effect on anything.

X and Y Offset were perhaps locations in the main image. Rather difficult to say. I tried entering various values which might put the rectangle near the centre of my image, but nothing further happened. If I left the page to check y image, these values were all reset to the values they had on first opening it.

In the end I could not get any extra info (nor even any extra refresh speed) from the Focus mode, and resorted to just looking at the whole image and seeing if I could see any imprevemnt in the number of stars visible in the Pleiades.

How is it supposed to work?

It appears the focus mode is broken... I will work on that.

You can use the Image Lag view (under Tools) to get the approximate download time for the images by subtracting the Elapsed time from the Exposure time. You can also see the value in the log with the message "Exposure received in 0.6046 s (0.4671)". The value in parenthesis is the time it takes to download the image.

I have fixed the focus mode. I upgrade the chart javascript library and I know I tested it, but I guess I tested when I had the old file still in place.

The indi-allsky capture process is almost too optimized for the focus mode. This is a major design difference between TJ's allsky and indi-allsky. TJ's allsky performs all actions serially: take exposure, process image, upload file, repeat. indi-allsky performs these actions asynchronously. If you run short exposures like I do, there are times indi-allsky can take 25% more exposures per night, meaning less of a chance missing meteors. The down side of the parallel nature, anything that slows down one of the pipelines, will cause things to back up.

indi-allsky is designed to take pictures with as little lag between images as possible. Therefore, I had to introduce some artificial lag in the actions. Focus mode removes the artificial delay between exposures (the period) and takes them as fast as possible. If processing (mostly compressing the image) takes a longer time than the exposure itself, the image processing queue can end up getting log jammed. The reason the default focus delay is 4s is due to libcamera, which can commonly take 2-4s to write the image. I would recommend maybe 2s if you have a USB astronomy camera.

The refresh time on the focus page is just because the web interface has no idea when a new image is available, so it just loads images at the refresh interval.

The X Y offsets on the focus page allow you to offset the view when you are zoomed in instead of being locked to the center of the image.

Thanks, and, I have to say it: you're really fast!

A beginner question: I guess I have to follow the update procedure in the wiki?

Thanks,
Richard

In this case, yes, but not due to this fix. The fix for the focus view was very minor, but I had just merged a major change. I am introducing thumbnail support to eventually support a new image library viewer.

And returning to the previous point:
Stretching is your alternative. The algorithm I have clips the black point based on X standard deviations from the average. Reducing the standard deviations increases the dynamic range of the output (a more aggressive clip). It is best to use this with a detection mask where you can manually blank out areas to exclude from the calculation. Otherwise, the SQM FoV (Processing tab, default is central 50% of image) is used for the calculation area.

I have disabled contrast enhancement completely, and now just use the stretch parameters. Earlier I installed a mask for meteor detection, which is a simple circle corresponding to 20 deg altitude (and I have backups at 25 and 30 deg). I made these by using an actual image as background in Photoshop and adjusting the mask according to the alt-az grid.
With this, the stretch seems to work pretty well.

Thanks for all the work on this!

Richard

PS: with this mask installed the images all look fine. But, if I select "mark detections on image" in the processing tab, then something odd happens: The mask obscures everything outside the mask, a vertical grey line appears down the centre and (this is the fist time I've seen this, because earlier attempts were clouded over) there are circles around (some) stars. So now I realise that the detections being marked are not meteor detections but star detections. This isn't so clear on the web page.

By the way, I'm sorry to be raising so many comments and questions which may appear critical. They are not!

I think you have made a really superb job with this software and the speed with which you respond to things is extraordinary.

I am seriously impressed!

Thanks,
Richard

No worries. I welcome all questions and feedback. Its nice to get feedback and if I get repeat questions, it just means I probably need to create more wiki pages.

Half of the features I have implemented have been ideas by others, even some things I did not feel would be particularly useful, but as long as they do not interfere with functionality, I will try to accommodate.