• Save settings to file
• Add option to reset settings

May be useful to specify location as e.g. Paranal rather than just Earth. Unlikely to make too much difference to geometry (lat/lon <-> xy etc.) but probably more important for e.g. doppler shift calculations.

Possibly also want to explicitly rename planetographic backplanes too for consistency?

Likely comes from the fact that we have flipud in the wrong place to deal with RGB images

We currently basically generate backplane info with values corresponding to the centre of each pixel. It might be useful to also generate the values corresponding to different locations within the pixel (e.g. the centre and the 4 corners?).

see also #2

Manual tests

• Test on different operating systems
• Test with different python versions
• Test e.g. plotting Europa xy wireframe with overlaid circle to ensure they line up

ax = o.plot_wirefeame_xy(show=False)
circle = matplotlib.patches.Circle(
    (o.get_x0(), o.get_y0()), radius=o.get_r0(), fc='none', ec='r'
)
ax.add_patch(circle)
plt.show()

Unit tests

• Add basic round trip tests
• Add tests for known backplane outputs
• Add tests for file IO etc.

Source code checks

• Check for TODO comments in code
• Check for raise NotImplementedError
• Remove any old/unused files (e.g. scratchpad, profiling code, utils etc.)

Currently, the observer is located at the centre of the observing body, and there isn't any way to specify the precise location, e.g. the lon/lat/alt location on Earth's surface corresponding to VLT. This can introduce (very small) pointing errors, and potentially slightly more significant velocity errors (especially for Doppler shift calculations e.g. #3), so may be worth fixing.

You'd probably either do this by doing another layer of coordinate conversions within the observer frame to get to the specific point, or by creating a completely new frame centred on the telescope - the new frame method is probably the 'correct' way to do it with spice. In theory the user could probably provide appropriate kernel files to provide whatever telescope frame they want, so this isn't strictly necessary to be customisable in the python code (but could be useful as a quality of life feature anyway).

Add detailed general documentation about the coordinate systems, units, definitions etc.

Test different values to find balance between plotting speed and accuracy

Generally, the coordinate systems the user will be using are probably going to be xy, radec and lonlat, so should we make some/all vector (e.g. targvec) methods private for simplicity?

Add options to mark coordinates on image to help with fitting disc:

• lon/lat
• ra/dec

For example, may want to mark lon/lat of specific surface feature or ra/dec of specific background star

• Load/save ring data
• Process ring data into radec coordinates (only visible part etc.)
• Plot rings in wireframes etc.
• Automatically load some ring data

Currently we load the same set of spice kernels every single time a Body is initialised - this has a number of issues:

1. Loading kernels isn't instantaneous (~0.3s)
2. Creating a large number of bodies in the same session causes a SpiceNOMOREROOM error
3. Re-loading the same kernels is generally inefficient and messy

Possible fixes:

• Dynamically check if desired kernels are already loaded
• Add some flag somewhere to indicate kernels are already loaded
  • This could potentially cause issues if the user unloads kernels, so would need to document this somewhere
• Add separate function to load the kernels somewhere

Related to #23

Will also need to carefully check logic in init etc.

At the moment we assume all angles are in radians unless otherwise specified, i.e. get_lon_img() is in radians and get_lon_img_degrees() is in degrees. This is more consistent with the spice internals (which all use radians), but users will (probably) generally think in degrees and want to work in them.

Therefore, we should maybe swap the default from radians to degrees, i.e. get_lon_img() will be in degrees and then have a get_lon_img_radians() which can work in radians when needed. As the radians stuff is generally internal (for speed and to interface with spice), we could then cut down on the number of public methods and generally simplify the code.

There could be cases where it is useful to save/output backplane data even if there isn't any actual data (e.g. planning an observing campaign?)

• Add some kind of progress callback to long running functions (i.e. backplane generation)
• Display progress bar with tk when running from GUI
• Display progress bar with tqdm when running from CLI

Want to find a way to just set the direction as negative and leave it as that

• Make vmax/vmin customisable
• Make wavelength customisable?
• Make gamma customisable?
• Add option to sum image?

We basically want to append backplanes to whatever the input FITS file is, but at the moment we only keep the first HDU from the input file.

This could potentially work nicely with #32 by moving backplane saving logic to BodyXY then using this in Observation to append the backplanes to whatever the provided data is?

• README
• Examples

• #4
• #5
• #9
• #15

Would make selecting vmin/vmax easier

Option to save cylindrical map (as png?). Probably need options for:

• Choosing photometric correction (i.e. make $k$ customisable)
• Choosing wavelengths for map

Implementation

• Add support for map backplanes
• Add actual generation functions for map backplanes
• Add function to create mapped version of the observation
• Add map output controls to GUI

Generating backplanes for large images can be very slow (potentially minutes), so need to optimize the code and/or let the user know what's going on. Profiling suggests that most of the execution time is spent calling the spice functions, so there's probably relatively little we can do to directly speed these up.

Code optimizations

• Profile code to identify slowest parts
• Cache results where possible (e.g. with the @cache_result decorator)
• Test using a multiprocessing pool to do stuff in parallel (e.g. 2c1a7ee)
• #25
• #26
  • Add check for $r \ll d$ to make sure this is valid?

UX stuff

• #51
• Add explicit warning about it being slow somewhere in the UI
• When running the GUI, maybe create separate subprocess to perform the actual backplane generation and file writing. This can then run in the background (maybe have a dialog box with a progress bar?) so the user can e.g. start work fitting the next observation immediately.

• Add method to save FITS file containing backplanes
• Add appropriate metadata to header

Basically want to be able to reproduce all the python API with the GUI, and have nice flow when opening e.g. a jpg

Add backplanes for state of each surface point:

• Distance (observer -> point)
• Velocity
• Doppler shift (derived from velocity)

• #1
• #3
• #19
• #17

Profiling suggests we could gain a decent chunk (~10%) of performance by encoding strings to bytes manually rather than letting spice do it slowly for every single call: #24 (comment)

See Henrik's code https://github.com/henrikmelin/spacecraft_rs/blob/master/spacecraft_rs.py#L268

• Allow all plotted features (e.g. limb, lon/lat grid/terminator) to be toggled on and off
• Allow appearance of features to be customised
  • Colour
  • Linestyle
  • Linewidth
• Properties
  • Grid
  • Rings
  • lonlat POI
  • radec POI
  • Other bodies
  • Other bodies (labels)

Save set of basic backplanes to FITS file with the data. Need to do the appropriate transformations etc. pixel-by-pixel so probably only want to run this when needed at the end of the reduction process when the file is being saved. Depending on speed and possible optimizations may want to display progress bar etc.

Basic set of coordinates to add initially (want to keep code generic to allow more to be added easily):

• lon,lat coordinates
• ra,dec coordinates
• i,e,g angles

The most costly part of backplane generation is finding the targvec for each xy coordinate. At the moment, we do this for every pixel, meaning that we run the expensive sincpt function for rays which completely miss the disc. However, we know the disc radius in pixels, so can very quickly and cheaply calculate the distance of each pixel from the disc centre to see if it's on the disc or not. If the pixel is off the disc, we can short circuit and avoid running sincpt when we know it's going to raise a NotFoundError.

This can probably be implemented in _get_targvec_img without touching any other code. To be safe, we should probably put a buffer around the disc, e.g. only short circuit for cases which are more than r=r0*1.1+1 pixels or something.

Implementation

• Add rough initial code
• Make sure we get the correct largest radius for the disc
• Optimise the distance calculation code (precalculate any constants, skip sqrt by squaring both sides etc.)
• Test appropriate buffer values to use

For observations which are smaller than the target, could be useful to move the observation around the target wireframe rather than moving the wireframe around the observation