2019 November: Complete LRGB Tutorial of NGC292, The Small Magellanic Cloud by Christian Sasse, Astronomer in Charge of iTelescope.net
2019 September: Astro Pixel Processor and iTelescope.net celebrate a new Partnership!
Blink mode to remove bad frames
Yes, agreed, it's on the wish-list if I'm not mistaken. Personally, I don't use blink all that much anymore as stacking with the "quality" option on and sliding the amount of frames to stack to about 90% gives me great result anyway. And, for instance subs with satellite stripes in them can still have great stars and will still benefit a stack.
I did not know there was an option for automatic quality restriction. I see on the load tab at the bottom there is a pulldown for "sort" with "quality", is this what you use?
Also, on the Integration tab is where you adjust to 90%? Do you also use the pulldown on "weights" and set this to quality, SNR or noise?
And as long as I'm asking you a million questions, on the outlier rejection which one of the MAD filters do you use ... I never integrate 1000's of frames.
Thank you for pointing me down this path.
Yes, in the integrate tab (6) you have an option called "weights" and there you have the "quality" option. Above that there is a slider called "lights to stack xx %", that's where I set it to 90-95% (personally).
For the outlier rejection filters, I usually go for the LN Sigma or LN Windsor options. Winsor is almost always preferred.
So, I just ran through my data again with the suggested settings. I have one frame out of 117 with an airplane track and one frame out of 117 with the object of interest being significantly off to the left. When I run the data it appears that the one frame of the airplane track is still being used and the one frame of the object off-center is causing the final integrated frame to shift the object of interest significantly. If I manual deselect both of the trouble frames and run the data then the object of interest is well centered and I have no visible airplane track lines in the final integrated frame. Any thoughts on what settings would automatically remove both of the troubled frames from the final integrated frame without me deselected them manually?
Mm, maybe airplane tracks are a bit too much even for sigma clipping (which I guess you had on?). The shifting I've never seen, but that's likely because I never had a frame shift that much. So, I guess that's coming down to me personally having no issues with airplanes and shifts, which results in me never having to blink much. Slightly elongated stars and such are not contributing much and will get lower quality values, satellite trails will get rejected and the rest can still be used. So in your specific case, a blinking option might actually be of good value. 🙂
Was the shifted sub, by any chance, selected as the reference frame? If so, that might cause a shift I think.
I'll check on if it was selected as a reference frame. I think some clouds rolled by and PHD2 got confused and then luckily after the bad frame was collected it was time to recenter and plate solve again and the rest of the frames were centered. Thank you for your help. I'm going to try this on some other data ... some that do not have these crazy outliers. I really do like knowing how to automatically select the best 90% now! Thank you again.
It's not a "in the dark decision", it's all based on a lot of statistical data. Signal-to-noise and star shapes are some of those and you can decide to throw away say the worst 5% or so by quality stacking 95%. Personally I never blink my data anymore as the result is always very good, if you do have a problem with the end result due to some really bad frames, it might be wordt to do it. I think it is on the todo-list of Mabula.
Help me understand how the % number is not an in the dark decision?
You mention 5% how do you come to that number? What if all my subs are good ? How do I know that it’s best to keep them all?
What if high clouds rolled in and my SNR dropped dramatically? 5% needs to turn in to 50%.
How do I know what the optimal % to throw away is?
You don't, it's simply analyzing all frames, showing you the statistics in the overview list below and there will always be a range of what is the best versus the "worst". That 5% won't influence the end result all too much if I loose it and I'm sure it'll have thrown away the least data usually based on the star shapes. Which is the reasoning behind it. If it needs to be 50% I usually already know it was a very bad night and would increase that, I however prevent that data from even going in because I tell my capture program to start over when guiding is off or the star is lost due to clouds. Other problems in subs like satellites can be clipped away and with proper flats there isn't much left to be very bad. If clouds are present, these should influence the statistics a lot and be thrown away in that 5%. For me that works in all cases until now so I had no need to tweak it more. If you have a situation where it does cause an issue, you'd have to tweak it a bit or change the entire workflow to reduce the problems. It's been very reliable for me. But a blinking tool can still be a peace of mind or sometimes still necessary so it is on the to-do list.
Right now I use PI’s sub frame selector tool to identify bad frames and give me a statistical plot of things like star count, FWHM, SNR, Eccentricity, etc. It makes it very easy to see where the outliers are.
I then cull the outliers and load everything back into APP.
Glad to hear this is on the todo list. APP already has all the information to do the same thing, just no way to visualize it before integration.
Man, you must have very different skies than I do. I have absolutely zero “average” nights. One night will be cloudless with excellent seeing, the next will be cloudless and seeing gets worse as the night goes on, the next night high altitude clouds roll in for 3 hours and disappear by the morning.
I have no way of knowing what kind of night it was until I statistically analyze my results. Taking a flat average just does not work.
Ah, well I think that has more to do when I decide to image. I took a lot of data in the Netherlands where clouds are the norm. I simply didn't go out if there was even the slightest chance of it and like I mentioned, my capture program wouldn't have allowed that data to come through anyway, my blinking was basically done at that stage. I limited the number of nights by a huge amount doing that, so indeed I decided to go remote to better skies anyway after a few years. 🙂 Looking at my end results, personally ofcourse, I decided not to mess a lot with the statistics anymore in the Netherlands as it simply was all over the place anyway and the end-results where always as good as I could get them, the throwing away of a lot of data didn't influence that by a big enough amount for me. The biggest difference in quality is a darker sky anyway, when I went to New Zealand, I was blown away and the downside of that was that I quit taking images from my own backyard in the Netherlands. But anyway, we all should make the most of it, and a blinking tool will be nice for some for sure.