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

Hi Stash,

Your testing helps

The tiff stacking went wrong because I used as filter *.tif* (for .tif and tiff) This picked up the *.tif_ marked as done but could not process further as tif resulting in the error. Fixed in version 0.9.285.

Clear skies, Han

p.s. one more note. ASTAP can read 8 or 16 bit tiff but can't read 32 or 64 bit tiff. That could be an other problem.

TESTED V 285 - OK PROBLEM not on test rig now on Obsys I5 8gb ssd Win 10.

Tried live stacking using files created by CCDCiel (on Windows) and Indiserver on a Gigabyte Ubuntu 64 bit connected to DSLR - so straight FITs

See attached screen dump - first file added then every files rejected - files ok via DSS/AT - not in same folder!

After renaming all files back - checked a couple with FITSAV no problem it loads them ok.

Also tried running normal stacking in ASTAP - (used just 3 files) same result first loaded then same error as above !

Strange

Hello Stash,

If the files are from a DSLR, the hot pixels & noise could be a problem. You will see in solving, stacking and live stacking. It could be also the settings. Could dump two or three files somewhere and send me a link , so I can have a look myself?

A dark could help but let me first have a look.

Han

Just noted the exposure time:
EXPTIME = 60 / Total Exposure Time

This should be an easy image to process without a dark....

Yes they are DSLR. I will try and get them off my Obsys system and put on Google and send you a link - may take a couple of days as I am trying to do a mod on my Obsys set up

@HAN

ok pm'd you with link to 3 files used on failure

ok another quirky item - on Ubuntu 19.10 live stack file count is from 0 - should be from 1 - think Windows version starts at 1. "Adding file 0 etc etc" !