Preprocessing, aligning on comet core does not work

Image processing, astrometry, photometry, etc.
Post Reply
Forum_2014
Posts: 255
Joined: 03 Dec 2018, 22:33

Preprocessing, aligning on comet core does not work

Post by Forum_2014 »

Hello,

I am using AstroArt since version 3. My most serious issue is with aligning stacks of images.

I am currently trying to stack images of comet PANSTARRS. The images show an overexposed core of about 10 pixels width with tail and some stars. The software fails to find the core as One Star. I have tried to adjust the Star detector settings without success.
It is most annoying to see the software fail on a task that appears so simple.
I have dozens of series of images where the automatic alignment fails, some of them have thousands of images and doing this per hand is near impossible. I wrote some special software for such things 20 years ago but don't want to return to that.

Also, the software has strange problems when asked to do a median stack on 1000 BMP images (1392x1040), most often i need to split that into several chunks, again annoying manual task. I run 64bit Windows 7 and memory and diskspace are available.

Also, i would like to see that the software offers to adjust for differences in coverage during a longer series: When edges of the image are only covered by 10 images, while the center is covered by 20, why not simply scale the edges by 20/10? That would be easy to implement and help with drifting mounts, or long series of images tracking a moving target.

Also, it would be really fine if the software could memorize and reapply alignment information for series of images. I often try different stacking modes on large batches of files and redoing any manual alignment is a major pain. But this will fade in relevance if the automatic modes improve.

I can provide GB of images for testing if required...

Best regards,
Municher

Forum_2014
Posts: 255
Joined: 03 Dec 2018, 22:33

Re: Preprocessing, aligning on comet core does not work

Post by Forum_2014 »

Hello Municher,
it would be useful to see the first and the last image of the sequence, you may post them here, or send to us by email.
If the nucleus is really saturated (so, no bell shape) and it's 10 pixels wide, then it cannot be detected as "star", but (using Astroart 5) it can be detected as "planet", so you may try that alignment method. Depending the image, it still could be detected as star, modifying the detectors options.

"Median" is no longer recommended, the result image will have a lower S/N and higher quantization (on BMP images) compared to SigmaAdd or Add+HotPixels. You may make a test to compare that. This could solve the problem.

Edges can be treated that way, but the option must be enabled explicitly: "Copy missing borders".

Clear skies,
Fabio.

Forum_2014
Posts: 255
Joined: 03 Dec 2018, 22:33

Re: Preprocessing, aligning on comet core does not work

Post by Forum_2014 »

Hello,

I have tried to attach the first and last image of the series but the upload complained about some weird 640x280 limit!?
So i put the complete series of 65 images here:
Zip of 64 sample images

Using "Planet" works even worse than no alignment with these images. How exactly is that implemented, what does the software go for? The tail might be confusing? A "center of brightest rectangle of configurable size" approach should do it.

Not sure what "Copy missing borders" does, apparently not what i would hope for, will look at this later.

Regards,
Municher

Forum_2014
Posts: 255
Joined: 03 Dec 2018, 22:33

Re: Preprocessing, aligning on comet core does not work

Post by Forum_2014 »

Hello Municher,
I downloaded your zip file and succesfully aligned and summed the comet images.
Here is my configuration (with AA5):

[picture]

I did not modified my usual star detector (I was just luky :-)... ), I simply selected the core of the comet with a click of the mouse and selected the "one star" option in the preprocessing window.
Probably you will find this setting useful for other sets of images and yes... the other option is to play with the FWHM values (S/N values are less sensitive in these cases)

Regards
Martino

Post Reply