This is a scratch-pad page to jot down ideas of coding projects people could attempt.

Improve annotation images

  • find more lists of objects for annotating images
  • reimplement the annotating code in Python using Cairo.
  • find a library for layout out the shapes and labels so they don't overlap and interfere with each other.
  • see also 830

Automate supernovae searches

Lots of amateur astronomers do supernovae searches, and part of the process involves "blinking" old and new images. We should be able to do better! Given two images with substantial overlap, (and taken by the same telescope, same exposure settings, etc) solve both of them using Astrometry.net, then using the two WCS solutions, either:

  • project sources from one image into the other image and look for new stars; OR
  • project pixels from one image into the other and compute the difference image.

You'll probably need to add some sort of margin to avoid detecting stars that were just below detection threshold in one image and just above threshold in the other. It may be beneficial to use SExtractor rather than the Astrometry.net source extractor for this.

We have a few contacts who can supply data and advice.

Build a set of functional tests

Some high-level tests of the kind "does solve-field solve this file?", "are the correct files written?", etc., would help to avoid breaking different parts of the code.

Allow users to correct the positions of annotated objects

We're using the NGC/IC Accurate Positions catalog, which were painstakingly measured and collected over many years. With many eyes looking at the rendered results in different images, we might be able to feed some useful information back. Even a couple of links to flag an annotated image - "the positions of the galaxies in this image look good" vs "the positions of the galaxies in this image aren't quite right" might help, but I bet we could also get our users to select more accurate sizes and positions. Lots of JavaScript? fun here.

Automate a Testbed

  • end to end tests on large sets of diverse images to measure speed/accuracy
  • regression test style -- known solvable/unsolvable images to see what changes
  • "random" xy lists to detect potential false positives

Build and test 2MASS Index

  • find a good set of test images. Possible contact: Frank Valdes at NOAO.
  • run 2masstofits, build-an-catalog to build Astrometry.net catalog from bright 2MASS sources
  • run index-building (cut-an, hpquads, etc etc) to build indexes
  • run tests

Figure out how feasible it is to take images with mobile phones, MacBook cams, OLPCs, etc

  • get one of these devices
  • find an SDK for capturing images
  • find out what aspects of image capture are controllable: focal length, shutter speed, ISO, aperture, white balance, etc.
  • find out the properties of the camera - focal length, distortion, sensitivity
  • figure out what kind of development environment exists - languages, compilers. Does it give you a C compiler?
  • capture a stack of images
  • see if they solve with the Astrometry.net web version
  • find out how much memory & compute power is available on-board
  • see if you can build a small enough index to fit on-board
  • see if you can build the required programs to run on-board

Produce VAMP AVM tagged images

exempi should make this pretty easy.

AVM web tool can be used to see what the XML should look like.

Build an index that just nails all images of Messier objects

  • we get a lot of these images submitted and it's embarassing when we fail on them!
  • find catalogs that cover these regions well
  • extract positions and brightnesses into a FITS BINTABLE of RA, DEC, MAG.
  • plug in to the Allow building indexes from custom star catalogs project below.

Experiment with triangles, quads, and quints

  • get a good set of test images. Eg APOD.
  • build triangle, quad, and quint indexes
  • measure success rates and compute time as a function of angular scale, etc.

Find out how much the performance degrades with smaller indexes

  • get a few thousand SDSS fields
  • build indexes with half as many quads
  • see how the performance characteristics (solve time vs solve percentage) change

Measure how long it takes to solve images using different indexes

  • find a good set of test images (eg APOD)
  • for each one, test it using each index separately and see how long it takes for each one
  • devise a good way to schedule or prioritise indexes to optimize solve time for images of different scales

Design and build roboscope prototype

This is a hardware design project.

"Roboscope" is a side project to come up with hardware and software that will help amateurs contribute to the OSSS. Currently it consists of some scripts for experimenting with remote control (via USB) of digital cameras, the idea being that someone like me would set up their digital SLR with long lens on a stationary tripod (not a telescope mount), hook the camera up to a computer, and the roboscope software would snap photos all night long then do image processing, etc.

A next step would be to design and build a simple software-controllable mount, so that the software could do active control rather than just having the camera sit on a tripod. It should have two or three degrees of freedom, have a strong enough mount to be able to hold a DSLR with a long lens, and be controllable via USB. It doesn't need to provide feedback about where it's pointing -- we can use Astrometry.net to provide feedback, so dead-reckoning is fine -- though some limit switches might be necessary and it would be useful to be able to read out their state.

Figure out optimal exposure time, ISO settings, etc, for fixed tripod-mounted cameras

For The Open Source Sky Survey, we want to allow people with digital SLRs and tripods (but not motorized telescope mounts) to take useful images. Figure out, for a given focal length and aperture, what is the optimal exposure time, ISO settings, etc., so that the number (and signal-to-noise) of detected stars is greatest. Long exposure times will lead to star trails.

Try to detect and correct star trails

Given a focal length and exposure time (both available in the EXIF header), compute how long the star trails should be as a function of RA,Dec. See if you can come up with a Hough transform or other algorithm that detects trailed stars and tries to "un-trail" them.

Do bundle adjustment on the USNOB plates

We work with a catalog of stars call USNO-B that contains positions, brightnesses, and motions for a billion
stars.  It was produced by the US Naval Observatory by scanning about 20,000 photographic plates.
They matched a set of stars on each plate with a catalog of known stars to find the pointing,
rotation, scale, and distortion to map from plate coordinates to sky coordinates.  This mostly works
okay, but it tends to make a lot of mistakes at the edges where plates overlap.  The solution would
be a lot better if you jointly optimized the positions of all of the plates simultaneously, ensuring
that the places where the plates overlap are consistent with each other.  In computer vision this
process is called bundle adjustment.  You can think of it as a big machine learning problem: you've
got a bunch of parameters (the pointings, rotations, scales, and distortions of the plates), and a
bunch of correspondences (star A on plate 1 is probably the same as star B on plate 2, so they should
get mapped to the same place on the sky), and you want to learn the parameters that optimally explain
the observed data.

Tons of astronomers use this catalog every day, so improving it is a useful scientific contribution
in itself.  It's also a big interesting machine learning problem with connections to computer vision.

How might this project proceed:
  * find USNOB entries that have observations from different plates (survey+field pairs).  These are
(possibly correct) correspondences. There are also a lot of missing correspondences, but finding
these will be much harder -- but will be easier to find one we've done an initial refit.
  * transpose this list to get, for each plate, all of the stars that also appear on other plates, while
keeping track of the correspondences.
  * for each plate, compute the initial plate solution (pointing, scale, rotation) and assign each star
a "pixel" position.
  * figure out how to feed this whole system into Keir's software, then run bundle adjustment.
Alternatively, use an off-the-shelf minimization routine to minimize the (5 surveys * 1000 fields * 4
plate parameters) <20k parameters to minimize the correspondence distances.  It's very sparse so this
isn't completely insane.

Work on Roboscope web gui

The beginnings of this project exist. Initialization: use the gphoto2 program to find a remote-controllable camera connected to the system and interrogate it to find out all the controllable features of the camera, and to build maps from the camera's control numbers to human-readable values ("F/4.0" -> value 7). Standard operation: a web page with drop-down menus across the top with those controllable values ("ISO 200", "F/4.0", "4 s", "RAW"), buttons to start and stop a run, and to tag or label them as dark frames, flat fields, etc. A large image window showing the most recent photo, with stats (number of saturated pixels). Astrometry.net solution. Image stacks. Ability to enter a target object and get directions about which way to move the camera. "Move 2 frames up to get to the Andromeda galaxy".

Work on Roboscope image processing

Dark frames, flat fields, RAW image processing, etc.

Projects that people are currently trying

Done

Implement tweak in Python

Tweak is one of the weak points in our system. Reimplementing the existing algorithm in Python would make experimenting with it much easier because we'd have a stand-alone version, and all the python plumbing around the core algorithm for experimenting with new and different algorithms.

Write a Google Maps renderer that can be hosted on Google App Engine

Write, in pure Python, a renderer that, for a given 256x256-pixel square in Mercator space, produces a PNG or JPEG image of either:

  • a list of (RA, Dec, flux_red, flux_blue) positions plus a PSF
  • a list of images (in any convenient format) + WCS for each one

Don't bother. AppEngine? has extremely stingy limits on the amount of computation time you can use. Rendering tiles is WAY outside the limits.

Allow building indexes from custom star catalogs

  • make cut-an support reading stars from a FITS BINTABLE containing RA, DEC, and MAG columns. 
    The first thing to do might be to create a little test program that opens a FITS table containing RA,
DEC, and FLUX columns using fitstable, and print out the values.  This can go in the quads directory
- our catch-all directory. :)

For dealing with FITS tables we have an-common/fitstable.{c,h} .  I added this fairly recently so the
API is not completely ironed out; comments are welcome.  "fitstable" has two modes of operation:
either you can read a whole column at once, or you can set up a correspondence between columns in the
table and elements in a C struct, and then you can read one row at a time.  I think we might want to
use the latter, because these tables could be quite big.  The best documentation for the struct mode
of operation is in an-common/test_fitstable.c in the function test_struct_1(), line 477; basically
you'll want to use fitstable_open(), fitstable_add_read_column_struct() to set up the mapping between
FITS columns and struct elements, then fitstable_read_extension(), fitstable_nrows(), and then
repeated calls to fitstable_read_struct(). Fitstable isn't documented very well so please let me know
if you get confused.