This page collects a series of animations I've made showing planets orbiting, or how planets orbit more generally.
There is a very well known animation of the four planets in the HR8799 system moving around their star made by Jason Wang and Christian Marois.
It uses the known orbits of the four planets to interpolate their motion between images taken over several years.
This is great, but it got me thinking: what if we don't know where the planets are? Supposing we had some idea of the orbital plane of the system—it's inclination, and longitude of ascending node—can make a similar animation for all sources in the image?
There are six variables needed to describe the local and velocity of any object in 3D space. These can be (x, y, z, v_x, v_y, v_z), or the six Keplerian elements (a, e, i, ω, Ω, t) which are semi-major axis, eccentricity, inclination, argument of periapsis, longitude of the ascending node, and time of periastron passage. Once we have these six values, we can project the motion of the object forwards and backwards in time using Kepler's laws. Let's assume for now that the orbits are not eccentric, so e=0 and choose ω=0 since it becomes undefined for circular orbits.
This leaves just (a, i, Ω, t). If we know the orientation of the orbital plane, we have i and Ω, leaving just two variables: a & and t. It's at this point, you may notice that a 2D direct image of a sytem also has two variables: x & y. This tells us there should be a general transformation for any x,y point in the image to a new (x,y) point at any future or past epoch!
Rearranging Kepler's laws into this form was messy, so I'll spare the details. Once we have a function mapping (x,y,a,i,Ω) to the full set of orbital elements, it's a relatively straight forward to plug into an existing orbit solver (in my case I used our DirectOrbits.jl package).
The last missing ingredient for transforming images was to hook into ImageTransformations.jl. If you supply a callable object mapping a 2D input vector to new positions as a 2D output vector of pixel coordinates, it can handle the rest. It does require a way to invert the transform, which for Keplerian orbits is simply to flip the direct of time. This is because the package performs a backwards transform, mapping output pixel coordinates to their locations in the input image before doing an interpolation. This is a standard way of avoiding messy seams and missing pixels after image transforms.
The main limitation is that the inner pixels of a source's point spread function will be mapped to faster orbits than the outer pixels. After more than around 10 degrees of motion, this can start to distort the images unphysically. That said, the peak of the point spread function should still be following the correct orbit.
The animations were rendered with Makie.jl. Feel free to use them in any presentations, just please cite the original authors of the data for the AB Aurigae image given above.
Thanks for reading!
-WT