StellarSolver Mods

[Hy Murveit]

It's already fixed!
Hy

On Fri, Feb 11, 2022 at 1:13 AM Jasem Mutlaq <mutlaqja at ikarustech.com>
wrote:

> 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/20220211/1e591d77/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/20220211/1e591d77/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/20220211/1e591d77/attachment-0003.png>