Drizzled Integrations and Geostationary Satellites

Since I've not had any feedback on this specific issue, are there settings that I should using for drizzled integrations, which are perhaps different for interpolated integrations, that I should be using to help reduce satellites?  Thanks!

Hello Kevin (or is it Jon?)

As no one has responded we might explore this a little. I don't know if I can help, but we might start by getting a bit more info.

Are you sure you have met the requirement of drizzle? Undersampled, lots of dithering and many, many subs. I have only had issues with APP failing to eliminate satellites when I've been oversampled, but you said you were undersampled.

How do you know you are seeing geostationary satellites? The satellites that cause problems are typically in low earth orbits, a few hundred km altitude, and move quite fast. I doubt that most amateur scopes could even image a geostationary satellite. These are about 35,000 km altitude. At best they may appear as a faint dot that moves across the tracked frame at about 0.25 arc-minutes per second. I have to wonder if you might be seeing an asteroid.

Why are you using median stacking? Drizzle requires lots of subs, and average is the recommended method when there are enough subs.

Some specific questions:

1) What is your image scale.

2) Are you doing a normal drizzle with a mono camera or a bayer drizzle with a colour camera.

3) How many subs have you got - per filter for mono or in total for colour.

regards

JC

Hi JC, and thanks for your reply.  It's both "Jon" (first name given by my parental units but which I never use except for instances in which first names are considered your only "valid" name) and "Kevin" (middle name that I actually use).

To answer some of your questions and comments...  I drizzle all the time when conditions permit, and when non-geostationary satellites are involved, APP+drizzle (plus Noise Xterminator later) removes virtually all traces of satellites.  It's only on the pesky geostationary satellites where I have issues.  I know they're geostationary because they are only near the celestial equator and they take several minutes to drift through a frame.  They move fast in space, but because they're so far away they take a while to exit a frame - I'm surprised you've never seen them before as I see them every time I'm imaging in central Orion or generally along the CE ... they're really not that dim.  I've been doing astronomy for 45 years, so I'm familiar with many types of things that find themselves in my field from time to time ... satellites, asteroids, meteors, alien spacecraft, drones, you know.  🙂

In this specific case, I am very, VERY undersampled, using a 50mm lens and my old ZWO ASI071MC Pro camera.  I'm using median stacking because that's what I've found works best to eliminate satellites - normal, non-GS satellites at least.

1) 19.7 arcsec/pixel in this case, which is why I want to drizzle.

2) In this case I'm using my aforementioned OSC camera and a Bayer drizzle.

3) For this project I have about 250 180-second subs.

I hope this helps.

-"Kevin"

Hello Kevin

45 years is pretty impressive. I'm guessing you are fully across issues of droplet size and scale and they may not bear on your specific issue anyway. I do have one suggestion, which I'll come to in a moment.

But first, I usually image at fl 550mm or higher, but I've dabbled with a fl 50mm lens. I'd have to say that I've come to the view that it is just too much undersampling for drizzle to deal with well, unless you have thousands of subs (especially for a bayer drizzle). Others may disagree, but I have recently acquired an 85mm lens partly in the hope that the undersampling is more manageable. This was so recently that I haven't really had a chance to properly test it yet.

My suggestion is to use a variation of a method that people used to use to deal with streaking stars when tracking on comets. If you divided your subs into 4 or 5 stacks and drizzle integrated them separately, and then did a normal integration of the 4 or 5 resulting images (using median stacking), I think that should eliminate your slow moving satellites pretty well. This may work best if the images in each stack are non-consecutive, but for a first test I would just break the stack into even chunks and give it a go.

I haven't tried this for your issue, but I think its worth a try. The disadvantage is that the individual stacks might not have enough subs for the drizzle to work well, so you might need more subs.

regards

JC

Posted by: @macejk

↑

Hello, and happy holidays everyone.  I've run into an issue which I'm sure that many of you have as well.

 

I use (only) Astro Pixel Processor to stack my data, and when I'm doing interpolated stacks, APP removes all but the brightest satellites.  However, with a few of my setups where I'm undersampled, I like to do drizzled integrations, and in this case I find that APP doesn't handle satellites as well with the (mostly default) settings that I use for interpolated integrations.  I use "median" most all of the time.  In particular, geostationary satellites are my biggest problem when drizzling.

 

Given that I don't completely understand "what's under the hood" when drizzling, are there some different APP settings I should be using for geostationary satellites when drizzling?  I've done some research online, but I've not yet found anything specific to this problem.  For reference, I am undersampled when drizzling, I do as many subs as is practical for a given target, and I am dithering - typically between every sub that's longer than about 60s, again target-specific.

 

Hopefully I'm just missing something here - thanks!

 

-Kevin

Hi Kevin @macejk and JC @connor231,

One vital requirement for drizzle to work as intended is that it always needs average integration. It preserves "the flux" of the data. So if you would set median integration in 6) integrate and enable drizzle integration as well, APP will automatically use average integration, you can actually see this in the console panel when the stack is starting.

So that will explain that your drizzled integrations suffer a little bit from these satellites compared to median non-drizzle integrations, because the median integration will be better in removing the outliers for sure.

On my issue list, we have a problem with data with many satellites so I am actually working on improving the outlier rejection for data with many satellites will still using average integration.

Currently I now have 1 big data set on which I am testing this and trying to "fix" this. Kevin, I think it will be very helpful if you can share your dataset with me so I can use it for testing as well. Can you upload it here:

https://upload.astropixelprocessor.com/

username: uploadData

password: uploadTestData

Please make a folder with your name and issue like:  macejk-sattelite-drizzle-issue

and upload your data into that folder and let me know once done 😉

Mabula

@mabula-admin Hello Mabula, and thanks for the information.  I wasn't aware of the need to use average integration when drizzling, so it's a good thing that APP automatically does that.  Should I be using different settings when attempting to better remove satellites from drizzled integrations? I'm currently not doing ANY outlier rejection. I've found that it's not usually required at least for interpolated integrations.  This might be a mistake on my part.

I've uploaded some data which I hope is helpful.  It's near the Horsehead Nebula, so there's lots of geostationary satellites, and probably some non-GS satellites to work with.

Thanks again for your development work on APP.  It's a wonderful product which I'm very happy to support!

-Kevin

Hi Jon @macejk,

Thank you very much for your compliment and feedback. We have received your upload in good order 😉 

You would always want to enable outlier rejection to get rid of artefacts. The automatic integration mode would actually perform very well for most data because it uses outlier rejection with settings that match the amount of frames.

I will work on improving the outlier rejection and will test with your data soon and will report back.

Mabula