Jump to content
  • Dealing with Satellite Trails in PI

    Reggie Jones

    Telescope Live astro image data is normally of very high level of quality. However, there is one problem it can have that will not be easily solved and that is when satellites streak across the image capture frame as the data is being acquired.



    I downloaded the NGC 5364 Bundled 1-Click Observation data. This is a beautiful 10th magnitude spiral galaxy in the constellation Virgo, about 51 million light years away. The data was taken on CHI-1, which is the Planewave CDK 24 telescope using the Finger Lakes Instrumentation 12 micron camera. It is one of my favorite Telescope Live imaging systems to use. You can guess my dismay when I opened the data and 42 of the 43 sub exposures looked like the first image I’ve posted here. They didn’t have one satellite trail; almost all of them had at least 2 trails if not 3 or 4. This is an example of the astro image apocalypse I have always feared was coming.

    Normally when I am dealing with data with satellite trails, I will preprocess the sub exposures as is normal, which for my workflow in PixInsight is to use the Blink, Cosmetic Correction, Star Alignment and Normalized Scale Gradient (NSG) processes in that order. When the NSG process completes for each set of subs (LRGB), it will automatically send you to use the Image Integration process to integrate each set of subs, which is the key process to use to correct data that has satellite trail issues.

    In Image Integration, you can select how aggressive you want to be in dealing with satellite trails. In this case, the number of subs for each filter was around 10 so the Winsorized Sigma Clipping Algorithm is used. This Algorithm has a Sigma High selection in the Pixel Rejection (2) tab. The default selection is actually around 2.5; this means that if a pixel is more than 2.5 standard deviations above the average pixel value, that pixel will be rejected. The higher the number, the less pixels will be rejected; consequently, the lower the number, the more pixels will be rejected.



    I initially thought that I would change the default number to around 2.2, however when I executed this it didn’t reject nearly enough of the trails. Long story short, I experimented with this selection and eventually took this number down to 1.0; the luminance integration result is the third image I’ve posted. You can still see small traces of the satellite trails in the integrated results, but if I went much further than this the results were not good. After completing the integration, I used the Dynamic Background Extraction process and some brute force using the Clone Tool to eliminate almost all of the offending issues. I completed my workflow on this data and I think the final result came out Ok.



    I’ve learned 2 lessons here; first, the default settings generally work for most situations but not all. When you run into a data issue like this one, make sure you understand how to use the process settings of the process you think you need to use, get out of your comfort zone and experiment with different settings to get the best result you can.

    The second lesson? With the huge number of satellites being put into earth orbit every day, month or year, we are increasingly going to run into this issue with all the data we acquire and process either through Telescope Live or with our own equipment. I’m not going to keep quiet about the loss of our dark skies or our ability to do astronomy here on the planet (topics for another day) but the bottom lines is that we’re going to need to learn how to deal with this and keep going.

    User Feedback

    Recommended Comments

    There are no comments to display.

  • Create New...

Important Information

By using this site you agree to our Guidelines