How about a compromise - add direct connection from Top Menu to the Live Stacking Window

Use of Jpeg - As politicians should know - "never say never" - would give speed increase I would have thought and maybe other uses I can't think of (others might ) If its not much extra work and no extra difficult support needed then why not !

I just uploaded ASTAP version 0.9.284. Live stacking will work with FITS, RAWs, JPEG and TIFF, PNG

I also uploaded 32 and 64 bit version for Raspberry Pi. Below the test result of live stacking expressed in time required per image. For Pi4 you have to set your exposure times for an mono image of 2328x1760 pixels at around 10 seconds or more . Note the memory card used are slow. Class 10?
Above these dimensions, the process time becomes too much to use.

Time required for live stacking per image:


My Pi3 was running out of disk space, so maybe it slowed done the processing.

Han

This happened to me after I installed it (apparently) successfully (all dependencies satisfied) on an RPi4, running Ubuntu MATE 18.04, with amd64 architecture added.



What am I missing?

Jo

Did you download the Raspberry Pi4 rather than the Linux version?

No, this is running on an Ubuntu MATE install, not on Raspbian.

As I wrote, install using the Gnome Debian Installer went without a hitch, but the program won't start. Unfortunately, the feedback I am getting when trying to start it from the Terminal is only marginally more informative than the 'nada' I am getting when just starting it from the App Menu.
ASTAP seems to be compiled for AMD64, the Pi4 is running on ARM64 architecture, so I suspect although I added that architecture (wouldn't have been able to install otherwise), the OS still doesn't like it.

I'm running ASTAP on ubuntu mate on an Odroid-N2, but I chose the raspberry pi install as it was arm64 rather than amd, and it works for me.

Far too simple a solution, really.....

Worked like a charm. It pays to read the instructions, but then again, I never ask for directions either...



Thanks, Jerry!

El Corazon, the debian package installer should have warned you about the wrong architecture unless DPKG was used.


Correction in my table the first row 10 seconds processing time is without dark. The dark is kept in memory, so it adds only 1 second to processing (10 seconds to 11 seconds). I assume a lot of time is lost by reading from memory card.

Han

I used the GDebi Installer, which I think is just the GUI for dpkg.
It gave me no warning, though. I had added the amd64 architecture to the system and install went without a hitch.

Thanks for sharing this with us, Han!

Looking forward to trying this out in the field. In outreach observation sessions, this will be invaluable. Being able to see an object 'materialize' on the screen in real time is what brings people into the hobby.

Hello Jo,

I checked it here but both in Ubuntu Mate and Raspbian Buster but I get a warning "Wrong architecture AMD64". Weird.

Han

Here the small correction:

Hi,

Tested out latest version results :-

1. CR2 picked up fine but also picked up TIFF file (used same AT files i used the other tests - it drivers ASTAP mad - see attached screen print

2. Remove tiff files and thumb nails and CR2 images picked up ok and ASTAP ran fine.

Image displays on my Samsung TV from ASAP Live Stack are very pixelated ! - Dont get that with AT

I don't know whether you want to go through the trouble of adding amd64 architecture to your system to reproduce the problem, but I suspect that is the main problem.

dpkg --add-architecture amd64

After doing that, it should resolve all dependencies (it did for me), but still not start.

Anyway, I don't think this is worth the trouble.

Sorry for the brief confusion.

Jo