That is indeed interesting.
Monroe
-------- Original Message --------
Subject: [AR] Re: Star Tracker
From: Ben Brockert <wikkit@xxxxxxxxx>
Date: Sun, December 30, 2018 8:32 pm
To: "arocket@xxxxxxxxxxxxx" <arocket@xxxxxxxxxxxxx>
That’s the core algorithm of the app Hyperlapse. Uses cell phone grade gyro
and processor to do image stabilization. You could definitely use that
technique to make a stacking algorithm faster.
On Sunday, December 30, 2018, Evan Daniel <evanbd@xxxxxxxxx> wrote:
On Thu, Dec 27, 2018 at 10:23 PM Henry Spencer <hspencer@xxxxxxxxxxxxx>
wrote:
for
On Thu, 27 Dec 2018, Ben Brockert wrote:
The star tracker is less useful if it only works when the thing it is
attached to has no roll. Stacking frames is effectively the same as a
longer exposure which, as Henry mentioned earlier in the thread, leads
to star trails rather than brighter stars.
There's one difference between longer exposures and stacking frames: you
can do shift-and-stack operations -- shifting frame N+1 around to look
the best correlation with frame N, and *then* stacking -- instead of just
stacking. Correlation can work effectively even when the features it's
matching on are buried in background noise, so you don't need to be able
to distinguish the stars clearly in each frame to do shift-and-stack.
This doesn't eliminate the problem, but can reduce it significantly, at
the cost of a lot more CPU cycles (which are not free, especially in a
low-power device with a hard real-time deadline to meet, but are much
cheaper than they used to be).
It seems to me that your shift + stack operation could get a good
starting point from some gyros, even ones that weren't inertial
navigation quality. And it definitely wouldn't need those gyros
initialized to any absolute reference. Is that common practice? Is the
precision just too low to be useful? Is the high CPU requirement still
present because of gyro noise?
Evan Daniel