StellarSolver Mods

[Jasem Mutlaq]

Hello Hy,

These are both very good points. Regarding the partitioning, IIRC, I added
an overlap but apparently it's not sufficient for all images if it happens
to be exactly in the center of two overlapping regions. I suppose we can
extend it and add other routines to remove duplicates.

--
Best Regards,
Jasem Mutlaq



On Sat, Jan 29, 2022 at 4:19 AM Hy Murveit <murveit at gmail.com> wrote:

> Rob and Jasem,
>
> I've been looking at star detection for a couple side projects
> (collimation and better detection for donut-out-of-focus stars), and when
> looking at the images I noticed a couple of areas for improvement in
> StellarSolver I'd like to address. I'll probably send an MR in at some
> point in the next few weeks, but this email is a heads-up, and, of course,
> request for feedback if you have any.
>
> 1- Partitioning
> The partitioning that was done to speedup StellarSolver definitely does
> affect star detection.
> Here's an image taken from my experimental work, where the left one has
> partitioning disabled, and the right has partitioning.  You can see the
> bright stars running across the middle, which happen to be close to a
> partition boundary, are not detected with partitioning. I'll probably try
> and add some kind of overlap (and duplicate removal) to solve this, as well
> as larger partitions. Of course, this is exacerbated with larger detection
> (like for the donut stars I have) but would still occur with smaller stars.
>
> [image: Screen Shot 2022-01-28 at 5.00.50 PM.png]
>
>
> 2- Sensitivity
> Although there are a ton of StellarSolver parameters, it turns out that
> one of the most basic parameters is hardcoded--that is the sensitivity of
> the system, e.g. the brightness above background level required for a pixel
> to possibly be considered signal instead of noise.
> See this line,
> https://github.com/rlancaste/stellarsolver/blob/master/stellarsolver/internalsextractorsolver.cpp#L458
> where "2 * bkg->globalrms", or 2 times the background level, is used as the
> threshold for signal. Below you can see a comparison (with partitioning
> off) where the right uses the default 2.0*background, and the left uses
> 0.5*background. As you can see many more real stars are detected. I'm not
> suggesting 0.5 is a good threshold--2.0 is probably decent for our
> application, though I'm not 100% sure--but it is possible that some
> applications like the ones I'm looking into would need more sensitivity.
>
> [image: Screen Shot 2022-01-28 at 5.15.23 PM.png]
>
> Hy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220129/44c7ce7b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2022-01-28 at 5.00.50 PM.png
Type: image/png
Size: 1860135 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220129/44c7ce7b/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2022-01-28 at 5.15.23 PM.png
Type: image/png
Size: 2891693 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20220129/44c7ce7b/attachment-0003.png>