The fact that the RPi4 can use the USB3 bus makes a huge difference. Compared to using an SD card using an SSD connected to USB3 makes a massive difference.

Right now the RPi4 cant boot from USB3 but using the guide in the link below it can be made to use the faster port.

This link shows how to take advantage of this:

jamesachambers.com/raspberry-pi-4-usb-bo...or-ssd-flash-drives/

In my case, the storage benchmark results speak for themselves.

Storage benchmark using
Original SD card only the score was : 1025
With the SSD on USB3 it's : 8430.

It simply files, in fact, it's faster than my Windows 10 laptop.

Yes, we've been looking to do something like that in KStars. I think we need a very fast star-matching algorithm (to know how to rotate/scale frame before integration) and then some averaging algorithm. It's mostly just as a way to see live how the image acquisition is going. It's also great for observatories with visitors..etc.

I wish there is a library we could use to make this easier, unless a developer steps in to implement it from scratch based on the existing algorithms in ASTAP and/or CCDCiel.

Noticed both programs seems to use Pascal as well

If the purpose is live viewing and to prevent saturation, there is no need for alignment. If you could expose a single image of 200 seconds (with good guiding), the equivalent is simply adding 40 x 5 seconds exposures together without alignment. If done in memory this will be simple having low CPU load and memory size requirements. The only penalty will be more readout noise.

Theoretical for live viewing it would be nice to apply FIFO, first in first out but that would require adding 40 image arrays together for every update. That will probably too much but maybe a stack of the last 10 exposures is feasible with the available computer processing capacity. Applying a dark will be then the 11th action. If you work backwards, you could try to add as much as possible historical images till a watchdog says enough. But it will take a lot CPU load and memory space.

In my opinion, Object Pascal is excellent tool for doing some complicated stuff fast.

Han

A Lot of EAA users , which I am one, also use very fast OTA's , sensitive CMOS(but DSLR works as well !) or add Hyperstar which enables very short <10 secs exposures which are stacked and produce good details even after 3 or 4 images and not just one bright objects like M42.

it does not need to be a fully integrated into Ekos but an application that runs along side EKOS e.g. it could just be set up to monitor a folder of exposures - e.g. Astrotoaster style (Deep Stacker). Perhaps as PC CCDCIEL works well with Indi you could persuade PC to produce a stand alone (i.e. not part of CCDCIEL) application using just his "stacking" code. NOTE Astrotoaster allows real time colour (Color) etc adjustment.

Bottom line would a RPI 3/4 cope with stacking and not hinder other processors ?

Short exposure stacked images examples (especially see HiloDon from Hawaii) stargazerslounge.com/topic/276321-first-...ith-hyperstar-on-c6/

On my standard desktop ASTAP can stack 10 monochrome images of 2328 x 1760 pixels in about 11 seconds using star alignment. Without alignment it will be faster. Since there is interest, I will do some testing with live unaligned stacking using most resent images from disk. The only parameter would be the number images or maybe better a time limit. If the performance is satisfactory, executables could be provided for all major operating systems.

What live stacking speed would be acceptable?

Han

IMO the benefit and main purpose of live stacking is making deep sky objects accessible to visitors. What used to be the view of M42 in an eyepiece (with ppl standing in line waiting for their turn)now becomes an immediately visible M42 on a screen, readily visible for everybody. For the astrophotographer it does not offer any advantages over normal stacking IMO.

Looking to some "live stacking" videos, I see the following requirements for a live stacking program for deep-sky:

1) Alignment of unguided images with an exposure time of a few seconds. (Nobody is guiding)
2) Showing intermediate results

This mean you have to stack differently. Assuming the images are A,B,C,D... then

Simple serial stacking:

result1:=A
result2:=(result1+B )/2
result3:=(result2*2+C)/3
result4:=(result3*3+D)/4
result5:=(result4*4+E)/5
....


The only question to ask when to restart serial stacking. If alignment fails a few times?

Han

... or if the telescope slews to a new object?


Wouter

No problem with live -stacking, this for sure is a benefit, but making the Indi FITS viewer more reliable should have much higher priority. It still crashes to much taking the whole observation session down with it. Just hitting a button can already make it happen.
(last time it was the apply button after selecting log histogram). Please detach it from KSTARS before applying new functionality.

Rgrds,

Paul

I briefly experimented with the code. Serial stacking works. Running on my standard desktop the cycle time using existing files is about 1.4 seconds for each 2328x1760 monochrome image including applying a master dark and flat each time.

I also had a brief look to DSS live. That looks nice but somehow people are only using it in combination with AstroToaster. What's wrong with DSS live only?

I assume the main benefit is that this solution can be used in Linux. The other programs look pretty established in Windows.

What to do with the input files. Maybe delete? Renaming is possible but it will produce huge amount of data since the setup is most likely operated with short exposure times. If I work this concept further out, I don't want to add more options.

Flowchart for images A, B, C, D...:

result1:=A
plot result1
result2:=(result1*1+B )/2
plot result 2
result3:=(result2*2+C)/3
plot result 3
result4:=(result3*3+D)/4
plot result 4
result5:=(result4*4+E)/5
plot result 5
...

The images in the above process with master dark and flat & flats dark corrected
Viewer maintains the actual view position and zoom factor

Great progress Han! Right, we desperate need something reliable working under Linux.

I already started adding ASTAP integration to Ekos as an alternative solver and hopefully by the next release we'd have something stable.

Regarding how to handle input files, this should be an option, because I could be running an actual sequence and just want to see the how the live stacking is going.

Hi,

Han, this is good if you add this function to ASTAP.

From my experience in CCDciel, it work better with a simple addition of each new frame. This is because people doing EAA don't really fear about star saturation but want the faint nebulae level to increase as quickly as possible. When you divide by the number of frame, you keep the faint nebula level very low, as it was on a single image, just with less noise. Also 60 x 5 sec. do not saturate more than 1 x 300 sec.
But the best option is to do the stacking in 32bit floating point, then scale to 16bit for the display.

Maybe with ASTAP you can also try to keep every frame to redo the full stacking each time, in this case you can use sigma clipping to improve the result. If I understand correctly this is what AstroToaster do.
And as Jasem say this can also be used to preview the result of a standard sequence, not only for EAA.

At the moment CCDciel shift the image with a single star alignment before stacking. This work fine with unguided mount but not with alt/az mount. It is good if ASTAP can also apply a rotation but this imply that more than one star can be measured in the frame.

Patrick