StarTools

This may not be feasible, but why not.

Im picturing a feature added onto the Bin module where it analyzes the image and based on some input parameters of some kind, it can determine mathematically if the image is oversampled or undersampled.

If oversampled, it could determine by how much a provide a recommendation for a bin setting to correct this.

If undersampled, the program would recommend restacking the image with 2x or 3x drizzle, bringing it back into Startools and running the analyzer again. I just don't know if it's possible mathematically to determine if an image is over/under sampled or not. :/

That's a cool idea. I considered something like this a fair while ago, but the problem is any such estimations become quite difficult when there is any sort of pattern noise present. Such correlated noise will look like "detail" and will therefore cause any algorithm to conclude that the dataset is no longer oversampled.

That said, it should be possible to give the user some sort of estimate or "best guess" in the Bin module... Let me think about this one...

Hi,
... probably this could be done using an auto-star mask with dim stars included only and calculating an FWHM average of the "multistar" sample....
jochen

hixx wrote: ↑Sun Mar 06, 2022 4:26 pm Hi,
... probably this could be done using an auto-star mask with dim stars included only and calculating an FWHM average of the "multistar" sample....
jochen

In order to estimate the seeing component of things?

It is an interesting idea to add some analytics to ST's repertoire, both for usefulness and just user knowledge, but I imagine there's some complexity here.

For inputs one would likely need some focal length and camera pixel info, and then knowledge for the final stack if there has been any drizzle or superpixel. An exact focal length of the stack could probably be obtained from an ASTAP solve.

We "sort of" already ballpark part of this as users when we adjust the SS Airy Disk slider. But that setting could perhaps become a suggestion (or pre-loaded default on module entry) too, but might have to take into account cropping and binning done in ST. Where I'd really like to see this kind of ballpark guidance also fed in would be the correlation filter in Wipe. Assuming that mathematics can pull all this off.

EDIT: might also need some kind of warning about the potential effects of tilt, coma, focus, tracking, etc.

Hi Mike,
I think for small to medium size amteur telescopes the focal length does not have to be super accurate for this - the "officialy advertised FL" would do. And for the pixel size, It'd just be a one time effort to divide your exact sensor size by the numbers of pixels.Data for DSLRs is already published from page like dxomark.com or dpreview. com. Many astro cams are based on Sony sensors (which are shared with ILCE / DSLR models). For the stack info, this could be entered manually (the user should know how he created the stack). so I do not think this "complexity would really be an obstical. Bottom line - IMHO, even without super accuracy, an iterative "Home In" approach would be helpful as a starting point for most users.
And yes, such logic could also drive the correlation filtering, but I guess, walking noise (which is the main correlation filter target) is also depending on tracking /guiding accuracy, hence would vary not only by above resolution parameters
Clear Skies,
Jochen