Image Stacking

[StarGeezerPhil]

Hi @aaronwmorris,

Excited to see the introduction of image stacking, but could you provide a quick overview on how it works/what it does if I enable it or how you envision it being used?

E.g.

• does it replace the normal images saved, or is it in addition to those images
• can I stack the whole night (I've done this with DSS separately before)
• are these images just used for the star trails / star trail timelapse?

Awesome to see you adding so much - need to really catch up on developments. Do you post a summary changelog for each release iteration?

[aaronwmorris]

I need to do a much better job with the changelog. :-) I think I need to just create a section in the readme to highlight new features.

The stacking is performed as kind of a rolling stack. The system keeps X number of previous images in the buffer and then stacks these images together. If you enable registration/alignment, then the last image is used as the reference for alignment.

The stacked image does replace the original image, so it is used as the basis for the timelapse video and the startrails/keograms.

The results of stacking (and alignment) is a mixed bag. On my monochrome camera, it increased the detected stars by at least a factor of 2. I had star counts increase from ~400 to over 1000 in some cases. The background of the images is significantly improved, especially with color cameras--the chrominance noise is significantly reduced in high gain situations.

Stacking is a relatively inexpensive operation, even on low end hardware. Registration is much more expensive, assuming it even works. Given favorable conditions (few clouds, etc) it can take a few seconds. However, I have seen the alignment runaway with 45 seconds of time and fail to find a solution. I have had to put in a few measures to ensure the alignment does cause the system to fall significantly behind on processing.

Stacking a whole night will probably not produce the results you want, at least not using the software packages I use for indi-allsky. The fisheye lenses common with allsky cameras have a lot of distortion that does not stack very well for large image sets. I have a couple of test scripts in the repo for doing this, but it takes a significant amount of time.

I posted this on cloudynights... this is 1 hour of data stacked together:

[dbainbridge]

Is it possible to have an option NOT to replace the original? I don't know if it is too much but would almost like two separate flows.. One with the stacked and one without. I do not want originals replaced. I tried stacking once already but did not like the split screen and loss of original data.

[aaronwmorris]

I am not a fan of losing the original data either. Things like meteors are effectively "averaged out" when stacking.

I will think on it. I may add an option to save to JPEG in with the "save raw" option. The original image would not be processed (rotated, flipped, etc), but at least you could keep an original image.

[aaronwmorris]

Merged #504 to export non-stacked images. JPEG is now an option for the "raw" export even though it is not technically raw. The "RAW" image is unaltered, [dark frame] calibrated data.

[StarGeezerPhil]

Thanks @aaronwmorris,

I've barely had any clear skies to really test this out yet, but I think my results are probably:

• Individual images are better; though, I seem to be getting a fair amount of misalignment. Any tips
• Timelapses aren't; due to the stacking the resulting timelapses loose their quality - appearing jumpy/blurred as a image feature (e.g. passing cloud) lasts 3+ frames - so the smoothness is lost entirely.

Therefore, if there's anyway to have a set of high quality individual images stacked, but use individual frames for the timelapses I suspect this might give the best results.

However, as I say - only one clear(-ish) night so far since testing and the Moon is high/bright - so not the best test cases so far.

[aaronwmorris]

Merged #601 to extend the I/O timeout for sqlite. Hopefully, that will help.

[StarGeezerPhil]

I've applied the journald changes... I think and it ran for ~10 hours before going down again.

Just to check, I usually use nano. So instead created the directory and then added the content via sudo nano /etc/systemd/journald.conf.d/25-volatile.conf:

[Journal]
Storage=volatile
Compress=yes
RateLimitIntervalSec=30s
RateLimitBurst=10000
SystemMaxUse=20M

I assume this would work exactly as you intended?

[aaronwmorris]

Yes, that should work. The last step in that was restarting journald (rebooting would be fine too).

sudo systemctl restart systemd-journald

[StarGeezerPhil]

Yes, had done both but still getting it going down. It's always been stable until this recent update.

[aaronwmorris]

Merged #601 to set the sqlite PRAGMA synchronous to off.