[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: StellarSolver Mods
From: Hy Murveit <murveit () gmail ! com>
Date: 2022-02-11 9:15:14
Message-ID: CA+B1P8v0k0pyw4qJYMtC_+ttC2Du01MUQ-8WqgAYaavCKxmjqg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
It's already fixed!
Hy
On Fri, Feb 11, 2022 at 1:13 AM Jasem Mutlaq <mutlaqja@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@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
>>
>>
[Attachment #5 (text/html)]
<div dir="ltr">It's already fixed!<div>Hy</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 11, 2022 at 1:13 AM \
Jasem Mutlaq <<a href="mailto:mutlaqja@ikarustech.com">mutlaqja@ikarustech.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div \
dir="ltr">Hello Hy,</div><div dir="ltr"><br></div><div dir="ltr">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. </div><div dir="ltr"><br clear="all"><div><div dir="ltr"><div \
dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem \
Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 29, 2022 at 4:19 AM \
Hy Murveit <<a href="mailto:murveit@gmail.com" \
target="_blank">murveit@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Rob and \
Jasem,<div><br></div><div>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.</div><div><br></div><div>1- Partitioning</div><div>The partitioning that \
was done to speedup StellarSolver definitely does affect star \
detection.</div><div>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.</div><div><br></div><div><img \
src="cid:ii_kyz4ovd70" alt="Screen Shot 2022-01-28 at 5.00.50 PM.png" width="542" \
height="144"><br></div><div><br></div><div><br></div><div>2- \
Sensitivity</div><div>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. </div><div>See this line, <a \
href="https://github.com/rlancaste/stellarsolver/blob/master/stellarsolver/internalsextractorsolver.cpp#L458" \
target="_blank">https://github.com/rlancaste/stellarsolver/blob/master/stellarsolver/internalsextractorsolver.cpp#L458</a> \
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. </div><div><br></div><div><img src="cid:ii_kyz57njs1" \
alt="Screen Shot 2022-01-28 at 5.15.23 PM.png" width="542" \
height="306"><br></div><div><br></div><div>Hy</div><div><br></div></div> \
</blockquote></div></div> </blockquote></div>
["Screen Shot 2022-01-28 at 5.00.50 PM.png" (image/png)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic