Blog - Posts by Laura Hayes

Artemis II Solar Eclipse

2026-04-09T00:00:00+00:00

The Artemis II mission recently completed its landmark voyage around the Moon, marking the first departure of humans from Earth orbit in over fifty years. Soon after Artemis II set the record of human distance from Earth, the astronauts took stunning photos of the the solar eclipse they observed on April 6 (EDT) / April 7 (UTC). We highly recommend watching the recording of the eclipse on YouTube; the reactions and descriptions of the astronauts are worth it.

Image credit NASA

On the SunPy blog, we rarely miss the opportunity to talk about a solar eclipse. So when we saw the eclipse photos taken by the astronauts, we immediately wanted to use SunPy to compare them to other images of the solar corona. Here is one of the amazing photos that has been shared:

Image credit NASA

This photo is particularly well suited to comparison with other solar observations because the limb of the Moon is clearly visible, and there are stars and planets in the image we can use as references. Understanding the coordinate system of the photo will allow us to overlay images taken by solar observatories.

The following images in this post, and the code to generate them, are from these two examples in the SunPy gallery:

Visualize the path of Artemis II

We can use JPL Horizons to obtain the trajectory of Artemis II and to confirm the time range of the solar eclipse. The sunpy/astropy coordinates framework enables visualizing the trajectory in any desired coordinate frame, and our example shows it in the frame co-rotating with the Moon’s orbit around the Earth.

Visualization of the Artemis II trajectory with the eclipse highlighted.

Also in our example, we confirm that the total eclipse started around 00:34 UTC and ended around 01:29 UTC.

Determine the coordinate system of the photo

To be able to compare this image with other observations of the Sun, we need to identify where the camera was pointed and how it was oriented. To do this we perform the following steps:

Extract the time information from the metadata stored in the image.
Use the time information to look up the exact position of Artemis II.
Fit the edge of the Moon to identify the center of the Moon, and the size of the Moon in the image.
Use the three planets visible in the lower right of the image to determine the rotation angle.
Use the planets to fit the distortion of the lens.

The following is an abridged version of the code in our example.

Find the position of Artemis II

The first step is to know the time the image is taken; we can extract this from the EXIF metadata. As with the trajectory above, we use JPL Horizons to obtain the position of Artemis II at a specific time.

from sunpy.coordinates import get_horizons_coord

artemis2_coord = get_horizons_coord("Artemis II" , "2026-04-07 01:06:19")

Locate the Moon

The next step is to use a known location in the image as a reference point. The easiest one for us to use is the center of the Moon, which we find by doing edge detection and Hough filtering, using scikit-image.

import numpy as np

from skimage.feature import canny, peak_local_max
from skimage.transform import hough_circle, hough_circle_peaks

edges = canny(eclipse_image, sigma=2)

h, w = eclipse_image.shape
radii = np.arange(0.25*h, 0.4*h, 10)

hough_res = hough_circle(edges, radii)
accums, cx, cy, rad = hough_circle_peaks(hough_res, radii, total_num_peaks=1)

A cropped view of the Moon, showing the results of the canny edge detection algorithm and the Hough filter.

Calculate the image scale

Based on the determined center of the Moon and its radius in the image we can construct an initial coordinate system for the image.

from astropy.coordinates import SkyCoord
import astropy.units as u

moon = SkyCoord(coords["moon"], observer=coords["artemis_ii"])
R_moon = 0.2725076 *  u.R_earth  # IAU mean radius
dist_moon = SkyCoord(coords["artemis_ii"]).separation_3d(moon)

moon_angular_width = np.arcsin(R_moon / dist_moon).to(u.arcsec)
im_radius = rad * u.pix
plate_scale = moon_angular_width / im_radius

We can now construct a sunpy Map using this information and overplot the anticipated location of the planets:

Initial coordinate system fit to image, notice that the locations of the highlighted planets are incorrect.

Determine the camera orientation

It’s clear from the previous image that we still need to correct for the camera orientation. Having the camera at a specific orientation is tricky even when using a tripod on the Earth’s surface, and we imagine is even trickier when flying through space! Fortunately, the planets serve as excellent reference points.

We determine the camera orientation by using a peak finding algorithm to locate the planets in the image and comparing these positions to the planets coordinates extracted from JPL Horizons. Doing this gives a \(-21.2^\circ\) roll angle which we can add to our Map metadata.

Image showing the expected positions of the planets and the detected (peaks) positions of the planets, from which the roll angle is calculated.

Account for lens distortion

The final correction to apply to our fitted coordinate system is the distortion of the camera lens (a Nikkor AF 135mm f/2D DC). This makes objects distant from the center of the image appear even more distant than they should. We can quantify exactly how much the image has been distorted by comparing the expected versus actual positions of Mars and Mercury (not Saturn as it is too close to the center of the image). We add this distortion to our coordinate system and our planets now appear in the correct place.

Coordinate system fit with additional correction for lens distortion.

Overplotting Coronagraph Images

Now that we have established the coordinate system for the eclipse photo, we can compare this observation of the corona to other data. To do this we are going to use the coronagraph (the LASCO instrument) on the Solar and Heliospheric Observatory (SOHO) which is located around the Sun-Earth L1 point. We reproject (or re-grid) these images to the fitted coordinate system of the Artemis II image to compensate for differences in satellite location and point of view, and then crop them to the limb of the moon.

The Artemis II solar eclipse photo with the positions of Mercury, Mars and Saturn highlighted, and coronagraph images from SOHO’s LASCO instrument plotted over the disc of the Moon.

The coronal structure visible in the LASCO image is not visible in the Artemis II eclipse photo, but the former has undergone significant image processing, and the latter is mostly straight out of the camera. A more scientific comparison may be possible when additional imagery from Artemis II is released in the future.

Closing thoughts

We think this post is a striking demonstration of what sunpy makes possible. By combining image metadata, spacecraft ephemerides, and coordinate-aware reprojection, we can place the astronauts’ eclipse photo and SOHO/LASCO coronagraph data into the same physical frame and compare views of the same corona from two very different vantage points. As a reminder, you can find the full code behind this post in these two examples in the SunPy gallery: Artemis II trajectory and Artemis-II Solar Eclipse.

If you are lucky enough to observe the total solar eclipse which will be visible from parts of Europe on August 12, 2026, remember you can try this type of analysis with your own photos by following our previous blog post!

SunPy Development Team wins a NASA Group Achievement Award!

2024-06-19T00:00:00+00:00

We are delighted to announce that the SunPy development team has been awarded with a NASA Group Achievement Award!

The award was given to our team for “developing and continually improving free and reliable open-source software that supports NASA missions and the analysis of NASA’s vast archives of solar physics data”.

This award is a collective achievement, and we share it with everyone who has contributed to SunPy! We look forward to continuing our mission of supporting solar physics research and making impactful contributions to the scientific community.

The What, Why, and How of SunPy Affiliated Packages

2020-08-18T00:00:00+00:00

What are SunPy affiliated packages?

SunPy affiliated packages are well-maintained, open-source software packages that build upon or extend the functionality of the SunPy core library. The main idea behind affiliated packages is to provide additional tools and functionality to the solar physics community that is considered outside the scope of the SunPy core library, but builds upon it. Affiliated packages are aimed to integrate well with the SunPy ecosystem and together with the core library offer a diverse software ecosystem for which to perform solar data analysis. Affiliated packages are reviewed and registered with the SunPy project.

There are two types of affiliated packages - sponsored and non-sponsored. A sponsored affiliated package is an affiliated package that is maintained and overseen by the SunPy project, examples of these include sunpy core and ndcube. Non-sponsored affiliated packages on the other hand remain under the control and maintenance of the original developers, but must meet a set of standards. Examples of non-sponsored affiliated packages would be instrument-specific affiliated packages such as AIApy.

In this blog post we want to outline our new streamline process for becoming an affiliated package and we want to encourage package developers, particularly instrument teams interested in developing a Python package, to submit their package for review for SunPy affiliate status!

Why would a package want to become an affiliated package?

SunPy supports the development of affiliated packages through our community development efforts and by providing our package template. The SunPy project will also ensure that affiliated packages are publicized to encourage community development. For example, affiliated packages are listed on the SunPy website, and SunPy adverstises them at conferences and workshops.

Call to instrument/mission teams!

We invite instrument and mission teams that are interested in developing a Python package to become a SunPy affiliated package. Integrating mission/instrument-specific software within the SunPy ecosystem will be of great benefit to the solar community and will allow for a simplified and unified process for users to perform solar data analysis. For example, a package may consist of instrument-specific calibration routines which would be outside the scope of SunPy core package, but could build upon the functionality provided by core such as the data containers and file readers. Developing a mission/instrument specific package as a SunPy affiliated package will allow the code to live and integrate within the SunPy ecosystem.

Furthermore, for mission/instrument teams that would like to begin developing specific Python software, the SunPy project offers support through our package template and community resources for the package to be ‘incubated’ until it is at the level of affiliate status. We would really like to encourage instrument/mission teams to reach out!

Package template

The SunPy project is currently developing a package template that is designed to help developers create new Python packages within the SunPy ecosystem. The template is still in development, and we are working towards creating more documentation to make it accessible for developers to use. The idea is that this template will provide a simplified way to standardized packaging, testing, and documentation using the same framework as the SunPy core package. The SunPy package template will make it easier for package developers to meet the standards required by SunPy to become an affiliated package!

How does a package become an affiliated package?

To become a SunPy affiliated package, a set of criteria need to be met to ensure that affiliated packages provide useful functionality to the community at a standard of quality similar to the core SunPy package. We now have a new review process for becoming an affiliated package, aimed at being open, approachable and streamlined!

The reviews are performed as an open process through GitHub issues on the https://github.com/sunpy/sunpy.org repository. To submit a package for review to become an affiliated package, an issue should be opened on this repository. We now have an issue template for submitting a package for review to make it easier to provide all the required information and to start a dialogue about the process.

Once an issue is open, the Affiliate Package Liaison will check that the package meets the baseline requirements of an affiliated package. These include checking to see that it is compatible with the SunPy Code of Conduct, has an appropriate licence, provides a Python interface, is on PyPI, and is useful to the solar physics community. Following this, a reviewer independent to the package is assigned and a review is undertaken based on the criteria listed below.

The review criteria that are assessed are listed as follows with the associated gradings:

Functionality Does the package provide functionality that is useful and relevant to the solar physics community?
Integration - Does that package integrate well within the SunPy ecosystem? for example does it make use of all appropriate features in the core library, including the applicable data structures and dependencies?
Documentation - Does the package have satisfactory documentation that is up to the standard of the core sunpy library including a user guide and examples?
Testing - Does the package use a testing suite to verify the code functionality within its codebase? Does it provide integration tests?
Duplication - Does the package duplicate functionality within sunpy core or any of the other affiliated packages or other relevant packages?
Community - Is the package openly developed with active input and engagement from users within the community? Does the package have a code of conduct and does this reflect the same values as the SunPy project?
Development Status - Is the package well maintained? Are contribution responded to by developers? Is the package still under development with large API changes?

These criteria are reviewed on a ‘traffic light’ system and ranked ‘green’, ‘orange’, or ‘red’ based on the submitted package. For full details of how each of criteria are ranked please check out the Review Criteria.

For a submitted package to be accepted to affiliate package status, the package must be ‘green’ in Functionality, and one other category. It must also not list any ‘red’ scores.

If the package in its current state does not pass the criteria, it can be listed as Provisional once it does not list ‘red’ in the Functionality, Duplication or Community criteria. The idea is that the package can be listed as Provisional as it is working towards addressing the criteria for which it did not pass the review in.

We would really like to encourage packages interested in becoming an affiliated SunPy package to please submit an issue and open up a review dialogue. We will have an Affiliated Package Liaison that will help you through each step of this process :). Even if you are unsure about whether you want to submit a package, please feel free to open an issue and informally discuss your package.

Reach out!

If you are a developer of a package that you think fits nicely into the SunPy ecosystem and will of benefit to the solar physics community and want to chat to us about it please reach out! This can be of course regardless of how far along the package is - from concept to maturity! Join us our live chat Matrix room or join in on the SunPy weekly community meetings which occur each Wednesday (see our calendar for the time in your timezone) and are hosted on jitsi.