<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>