Live stacking methods?

In the last version I changed counting such that it start from 1. If the version are the same, they should behave the same., unless I made a mistake with copying the source files.

About you DSLR images which didn't stack. Where the 60 second images guided or unguided? Images with oval stars doesn't work.

Han

stash wrote: @HAN

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

Thanks Stash,

Analysed the images.

Solving works fine with setting downsample x2 or auto x0
Stacking unbinned fails.
Stacking binned x2 works fine

Images are oversampled and contain hot pixels. Maybe I should at an internal step to binx2 for alignment since with OSC cameras, you don't want to bin them before de-bayering.

Let me add a internal binx2 step for alignment only so these images are processed smoothly. Maybe I should binx2 the result in one step.... In what resolution do you publish these images?

Han

Han,

I will check the version number again just in case but the Windows version is fine and stars from 1.

Guided or not - dont remember. I dont always guide but still require (and do ok) to stack.

Didn't actually try Platesolving with ASTAP so cannot comment!

"What resolution do you publish these images" - sorry dont understand - the images were 5184 x 3456 as per default on the Canon 100d and if I upload the images t o local Astro group I just do a screen print output via PNG via Paint or equiv.

version number was 0.9.283 dated 2019-10-19 Linux Ubuntu 19.10 AMD 64bit

Edit going mad - it was Linux Ubuntu 18.04.3 LTS(bionic) on this test rig - use so many versions I lost track - sorry

Hello Stash,

ASTAP version 0.9.286 just uploaded does stack your images reliable. I have implemented what was already longer considered, "to bin (if specified) for star alignment stacking". Stacking is also little faster since finding stars in a binned image goes fater then an unbinned imaged making more then up the time required for binning. The binning is default at 0 equal auto or can be at 2.

So live stacking (the topic) is working well now on your images.

About your images, the HFD/half flux diameter of the stars is about 12 pixels and the image height is 0.36 degrees. This is equivalent to 0.37 arcseconds/pixel. The seeing was then about 12*0.37 is about 4.4 arc seconds which is typical. For several reasons an average HFD of 2 or 3 is the best . The SNR is best while not loosing resolution due to undersampling. So your image could be binned x4 to improve the SNR with not losing resolution. Since it is a OSC/DSLR this can only be done after demosaicing. So these small pixels are not the perfect match for a 12" telescope unless binned later.

Han

I will try out the new version

Without seeming rude - ASTAP has to compare with what I can do already do (excluding running on Windows,Linux etc which AT/DSS can't) so the jury is still out on how useful ,to me, ASTAP is at this moment in time. Having said that it is an excellent professional application perhaps too good for me and my workflow in EAA But I do thank you for your tremendous efforts !

OK tried out latest version on Windows i5 64bit - seems ok . Used some image files produced last night by CCDCiel and I must say Platesolving is being done in 4 secs as opposed to 10-16secs in Ansvr. However blind solving Ansvr still wins - ASTAP fails (even with 180 degree and 120 sec time out) but ansvr does it in 44 secs. So like life nothing is perfect but what a great extra lot of tools we Astro Nuts have - thanks Han & Peter(CCDCIEL).

Will have to wait a while ,it seems,for the next clear sky - anyone invented a cloud converter LOL.

EDIT - spoke too soon calling ASTAP for plaesolving now fails under Ubuntu AMD 64bit

I may be doing something wrong, but I think the Pi4 running Ubuntu Mate may be overwhelmed by the computing required for live stacking.
I am using ASTAP for live stacking of Nikon .nef RAW files I collected and saved last night and it is going very slowly, slower than the frames would be coming in. It looks like it takes about 70s per frame to be added to the live stack.
And that is with b&w output only.
However, seeing M42 increase in definition and getting the fainter parts of the nebula and inner structures resolved progressively is nice and would be doing wonders during outreach to draw people into the hobby.
Am I doing something wrong here, or is this a limitation of the Pi4 that one cannot overcome?

No that's a limitation of the Pi4. Looking to your screenshot, your having raw's of 24 MP (megapixels) My previous values where:

Mono FITS 4 MP 10 sec
Mono FITS 16.2 MP 35 sec
RAW 8 MP 33 sec (to colour)

Since you have no colour (debayer not set), I assume it is processed as mono. A fits file of 24 MP would take (24/16.2)*35=>51 seconds plus the time for conversion raw to FITS. Would you activate debayer, (stack menu, tab stack_method) it would probably take 50% more time (75 seconds?).

So for the Pi4 it is no success for colour images. You have to bin to 2 to 4 MP to make it reasonable fast. But that means you can only use it for public demonstrations and not while collecting 24 MP images. Maybe if your camera can produce binned colour images, you could try to stack jpeg files for public demonstrations.

Han

Hi Han,

I'm testing live stacking on OSX. I see the OSX build is listed as being a version or two behind the others. Is it possible to get an OSX build? I'd like to provide feedback on the latest and greatest so I'm not reporting things that are already resolved.

- Greg

schwim wrote: Hi Han,

I'm testing live stacking on OSX. I see the OSX build is listed as being a version or two behind the others. Is it possible to get an OSX build? I'd like to provide feedback on the latest and greatest so I'm not reporting things that are already resolved.

- Greg

Greg,

Just released a new macOS version (0.9.298). It would be nice if you could test it. My testing of the macOS version is very limited. I compile it using virtual machine running 640x480 resolution only on a old laptop.

Han