Alignment point size in Lunar/Planetary with AS!3?

[ONIKKINEN]

Is there a "right" size for alignment points with Lunar and planetary recordings when stacking?

I have enormous files with a 678MC and stacking takes forever, so have not experimented much on this. For full resolution 3840x2160 captures i have used a fairly large size, like around 100 or so and there is still thousands of them in the end. With smaller ROIs i have used smaller sizes, like 64 or 48 but not much smaller than that. They still take forever to stack.

Is there a rule or a guideline on what should be the AP size? I assume seeing plays a major part in this and the AP size should be big enough to account for the shimmering of the atmosphere, but that is just a guess from my part.

[Elp]

I usually just auto place them. As a general rule the larger they are the more processor intense they'll be as the search area is larger, but a lot of aps will also slow it down also. I assume your computer is fairly capable? One session on Jupiter I ended up splitting the runs into five smaller ones, then stacking the five results separately. 

[vlaiv]

48 minutes ago, ONIKKINEN said:

I assume seeing plays a major part in this and the AP size should be big enough to account for the shimmering of the atmosphere, but that is just a guess from my part.

That.

Try to make alignment point big enough so that any shimmers are caught by it (imagine point where AP is and see how much it jumps around. all those jumps need to be inside of the box).

Don't make it larger than it needs to be as sometimes it can confuse stacking software if AP are large - sometimes same looking features can fall in two APs (think small craters on the moon as example). Stacking software is not very smart - it looks for correlation between detail and can't distinguish craters one from another.

[ONIKKINEN]

7 minutes ago, Elp said:

I usually just auto place them. As a general rule the larger they are the more processor intense they'll be as the search area is larger, but a lot of aps will also slow it down also. I assume your computer is fairly capable? One session on Jupiter I ended up splitting the runs into five smaller ones, then stacking the five results separately. 

My PC is a bit aging now, but it was built with good kit in 2016 so its by no means a slow one today. 6700K with a decent overclock, early adopter DDR4 ram and GTX1080 but not sure AS!3 uses GPU acceleration so might not matter.

I thought it went the other way with alignment points that smaller sizes and a large number is more intensive than large AP size and lower number of them. Gotta test it now.

[ONIKKINEN]

2 minutes ago, vlaiv said:

That.

Try to make alignment point big enough so that any shimmers are caught by it (imagine point where AP is and see how much it jumps around. all those jumps need to be inside of the box).

Don't make it larger than it needs to be as sometimes it can confuse stacking software if AP are large - sometimes same looking features can fall in two APs (think small craters on the moon as example). Stacking software is not very smart - it looks for correlation between detail and can't distinguish craters one from another.

Right, i think i will try pre-stabilizing some of the files with PIPP to make the AP size selection a bit easier as i kind of just guessed it when there is a lot of variation from frame to frame. I might be able to squeeze something new off recent lunar shots that were a bit soft.

[vlaiv]

1 minute ago, ONIKKINEN said:

I thought it went the other way with alignment points that smaller sizes and a large number is more intensive than large AP size and lower number of them. Gotta test it now.

Not sure about that.

I think it will take the same time - it has to do with surface covered by APs - and not the number and size of them.

If I'm not mistaken - square around AP is "search area" - and for each point in search area - displacement correlation against reference image is measured and best match is added to "displacement mesh"

This means that all pixels that belong to AP surface will be checked once as center of correlation (for given AP).

[Elp]

Listen from the author himself:

https://youtu.be/JIjXmRh1DE0

 

[ONIKKINEN]

2 hours ago, Elp said:

Listen from the author himself:

https://youtu.be/JIjXmRh1DE0

 

Was a good watch, thanks for the link. Answered many questions about the software, including some of the AP size things.

Looks like the multi-scale option partially makes up for incorrect AP size and placement troubles, so maybe not a critical thing to worry about as long as the size is thereabouts correct

2 hours ago, vlaiv said:

Not sure about that.

I think it will take the same time - it has to do with surface covered by APs - and not the number and size of them.

If I'm not mistaken - square around AP is "search area" - and for each point in search area - displacement correlation against reference image is measured and best match is added to "displacement mesh"

This means that all pixels that belong to AP surface will be checked once as center of correlation (for given AP).

Just tested different AP sizes for a recording, took 22 minutes for AP size 48 and 3760 points and 15 minutes for AP size 96 and 875 points. So looks like its a little bit faster when there are less alignment points. This was a half resolution recording though so the difference is probably not inconsiderable for very large files.

[Elp]

For how many images/frames?

[ONIKKINEN]

40 minutes ago, Elp said:

For how many images/frames?

That one was 10k frames 1920x1080, OSC camera, not drizzled and double stack reference disabled.

The full resolution 3840x2160 captures take considerably longer and completely kill my PC for doing anything else in the meanwhile, so rather not test much on those.