Optimal Sedna

While I'm always searching for other objects, Sedna is a useful object to return to. It's a handy yardstick for measuring improvement in my detection process. I use Sedna to benchmark my tools as I go about searching for other interesting dim, slow moving objects. In this work I've increased the number of Sedna detections, improved the error residuals in those detections and found better OD solutions compared to my previous two Sedna studies.

I've titled this study Optimal Sedna because I'm integrating the optimal number of TESS frames to keep Sedna in one pixel. This choice of optimal frame integration also implies a linking parameter search space as well as a specific static sky template to build. I'll explain the motivation for isolating Sedna to one pixel as well as how these other measures fall out of that decision below. But first, here are the summary images for this (my third) Sedna study.

Motivation

Why would you want to keep Sedna in one pixel? Since Sedna is so dim (mag 20.9), it's not trivial to detect with TESS. In order to accumulate enough signal you need to coadd multiple TESS 30 minute exposure frames. If you don't coadd sufficient frames you won't accumulate enough light to detect Sedna. Conversely, if you coadd too many frames, Sedna's signal will be filtered out by median integration (which is how I coadd frames). Therefore, to maximize the odds of detecting Sedna we want to coadd the number of frames that we expect Sedna's motion to remain within one pixel for. Obviously you can only do an 'optimal' integration if you know something about the orbital characteristics of the object (specifically the RA & DEC rates), which of course we do for Sedna. Translated to TESS' pixel scale, Senda's motion is about 1.8 pixels per day during this observation window. TESS' 30 minute exposures yield 48 frames per day. Thus, coadding 26 of these frames (48/1.8) is 'optimal' to keep Senda in one pixel over this interval.

Consequences of a 1px motion constraint

As I mentioned above, a few decisions on subsequent parameter choices are made for you when you isolate a target's motion to 1px in your integration frames. This is welcome, actually, because the choices that you could make for these parameters are many and not immediately obvious. These parameters essentially become functions of the number of frames you coadd, which is helpful.

Implied static sky template choice

As a reminder, I use bootstrapped templates generated from the same integrated coadd frames I'm looking for objects in. There are many ways to generate these templates, but I've settled on a method that trims the highest N values at each pixel in a stack of integrated coadded TESS frames. For example, with this Sedna study I median coadd 26 frames to get one integrated frame then I do that again 22 more times for each full day in this TESS sector. Then I trim the highest N values at each pixel from the 23 integrated frames.

The challenge is choosing the N. The higher the N the more noise you introduce into the difference images. The ideal N is 1 for the case where the pixel is unilluminated for all integrated frames except for the frame where an object passes through through it. For fast moving objects this works well. However, with slow moving objects where you must take into account the maximum amount of time the object can stay within one pixel and consider edge cases. You might initially think that with the 1px motion constraint you could choose N=1 here too, but if your object is located between two pixels (thus illuminating both partially) it will take a choice of N=2 to ensure the object passes out of 1 pixel.

Linking search space

The other thing that falls out of the choice of frame coaddition number is the implied object velocity. Using a median filter to integrate the coadded frames filters objects moving substantially faster than the object velocity implied by that choice of frame coaddition number. In this instance, having chosen to median integrate 26 frames per day, I'm essentially targeting objects with motion of ~1.8px/day as explained above. When linking detections in these frames I can then limit my search to detections moving within a range centered around 1.8px/day and spanning a maximum of 1.8*23=41.4 pixels (pixel rate X number of integrated frames). These constraints substantially reduce the number of candidate links you have to test with OD.

Process notes

Link combination trimming

Candidate links that are tested with orbit determination can range in length from 6 up to the total number of integrated frames (23 in this study). My strategy is to test all 6 detection combinations of these candidate links. However, for long candidate detections you can easily end up testing thousands of combinations. In order to whittle down the number of combinations I'm doing two things. 1. I'm re-running the linker on long candidates with a universe of detections that only includes that candidate link's detections. By slowly tightening the acceptance parameters, I can start rejecting the detections that are less likely to solve with OD. 2. I'm stopping the linker once it returns a link length with a specified nCr() combination count. Previously I was telling the linker to stop prior to nice round numbers and then sampling the larger (but reduced) set randomly to OD solve. By choosing specific nCr() count numbers (say nCr(12,6)=210) I can have the linker return a link of length 12 given a starting link length of something greater than 12. This helps reduce the computation time for OD substantially.

Ideas and next steps

Sequential velocity filter on links

This is something I'm playing with in this study, but I haven't incorporated it into the process yet. My linking algorithm clusters detections that are moving at a constant-ish rate with respect to an origin detection. The 'ish' part is constrained by a tolerance parameter. Neglected in this is whether these detections also move at constant-ish rates with respect to one another. Sequential filtering looks at this question and filters links that don't have a low coefficient of variation in either the X or Y dimension (in the pixel plane space). Essentially it's keeping links that have constant-ish sequential velocities in one or both of those dimensions. I'm still playing with how aggressive to be with the filter (or whether to use it at all).

Improving astrometry/residuals with shift and stack

Here's a screenshot of my residuals for this Sedna analysis. It's the 'd' column in the table and it's in units of pixels. All residuals are substantially less than 1px, but remember TESS has 21" pixels so there's room for improvement here. I'm hoping that by using the detections generated by a study like this I can stack and shift along the implied preliminary trajectory over individual (non coadded) TESS frames. If I can then refine the initial stack and shifted trajectory to maximize the object's detection signal, I should be able to get better astrometry? It might also be a good way to investigate detections that link and OD solve but don't quite have enough detections to confidently validate.

Filter outlier input frames with clustering

Sometimes you load up a set of TESS frames and get lucky. The background level is low, there aren't any significant artifacts and all the frames essentially look the same. Other times this is not the case. The trick is figuring out which frames to discard without looking at each one (or worse, each constituent frame of a coadded frame). I'm playing with a technique that clusters 'sky vectors' (split each frame into an NxN grid, take the mean of each of those N² sub-images, then reshape all those values into a vector). Then I cluster these sky vectors to find the most similar image set to select for difference image processing. This is an implemented but still untested idea at this point.

Conclusion

This study demonstrates process improvements that increase the detection count, improve residual measures and yield more frequent OD solves for Sedna in TESS data. These were achieved primarily through a more considered approach to my frame coaddition count with respect to Sedna's pixel velocity in TESS images. Additional refinements to candidate link trimming helped reduce the OD search space while still maximizing the number of candidate sub-links that solve. With these tools in hand I can better target slow moving objects in TESS.

Published: 10/8/2021