Hi John,

I haven't been able to download a new version of the Beta since the nightly builds have continued to fail. In the meantime, I had a question related to using the full field focusing option. When I see stars being selected in the autofocus viewer window I have noticed many stars with HFR less than 1 (I have the units set to pixels). I may not understand this correctly but a measure of less than 1 pixel seems implausible to me. During repeated focus measurements, I see the mix of stars change (it changes a bit frame to frame) and that 'regular size' stars HFR measurements are going up. However, the average HFR starts to go down because more of these sub pixel measurements seem to be included. The result is either not finding focus or taking a very long time.

Does it make sense to exclude these very small values from the algorithm? Or, more likely, that I am missing something?

Thanks!

Sorry about the problem with the nightly builds. Jasem made a change for the Mac issue so hopefully that will build on the next run. The Win64 one is slightly more complex as its failing on a compile problem that, again Jasem is taking a look at. Probably some lack of compatibility between build environments on different platforms.

Star detection is done by several algorithms in Ekos. SEP is generally considered the best. You can setup quite a few params. Here, for example, is my setup...


I wouldn't advise just copying these for other setups though. Hy and I played around a while and concluded that some settings that work well on my refractor don't work well on his Rasa.

For star extraction "Min Area" describes the number of contiguous pixels above the background required for a star "hit". In the example its 20. You could check what you're using.

There is also a filtering parameter Miin Size which will filter out small stars. You could set this if you like. If you put it above 1 then it will exclude hot pixels.

Its hard to be prescriptive with the parameters unfortunately as what you're trying to balance is detecting good stars whilst limiting noise / hot pixels, etc.

If you post a picture of your settings I'd be happy to comment / discuss.

Thanks John,

I'll experiment with these a bit. I am using SEP and have Min Area Extraction at 20 and Min Size at 0 so I'll move Min Size around to see how that impacts things. Can you explain how Min Area Extraction and Min Size interact with each other - I'm not getting a good understanding from the tool tips.

I'll try to capture a screenshot of my setting but the only difference I can see are that my Thresh Multiple is 2.0 vs 2.5 and my Cut Dimmest is 20 rather than 10.

Min Area is an extraction parameter so is used in to detect stars.

Min Size is a filtering parameter. So once SEP has extracted and measured all its stars they are filtered before returning the list to Ekos::Focus to do its thing.

Thresh Multiple is another extraction parameter. SEP will consider possible stars above the background (bg) and standard deviation of background (SD) and looks for stars above bg + Thresh Multiple * SD. So increasing this will get you less stars and less false stars due to noise.

Cut Dimmest is another filtering parameter.

The problems with the Mac and Windows nightly builds have been fixed.

John - thanks for the update. I hope to get back to using this in a few days.

I had a follow up question. I've reviewed your answer to me regarding Min Area and, since I've had it set to 20, I'm not sure how/why I was seeing stars selected in the focus routine that were showing HFR values of less than one. The tool tip indicates that smaller stars are ignored.

Thanks - feel like I must be missing something!

Hi Fred,

For 20 contiguous pixels you'd need say a grouping of 4 x 5 pixels above the background cutoff. This is a "radius" of 2.25 pixels. That would make the HFR around a pixel so its certainly possible to get some hits with an HFR < 1.

On the other hand with Thresh Multiple set to 2.0 you'll be extracting above the background noise about 95% of the time (2 sigma) so 5% of the time pixels above the background cutoff will actually be background noise (assuming the noise is gaussian). So its certainly possible to get a grouping of 20 pixels > background cutoff that are just noise.

If you zoom is on a star with an HFR < 1 so that you see individual pixels you'll be able to see whether it looks like a real star or not. If its just noise then there are several options:
1. You could increase Min Area.
2. You could increase Thresh Multiple.
3. You could specify a Min Size > 1 so stars with an HFR < 1 will be ignored.

The MacOSX nightly is broke again. May27th works, but the 28th has failed to build again.

I downloaded the OSX build dates 27 May and notes two issues before I quit it.

1. Immediately after selecting Capture and Solve, EKOS set my rotator to 360. This was unexpected, as normally it only rotates with LOAD and slew. I had never seen this action before.

2. Once it did the above, It no longer saw any of my plate solving index files. I assume it just lost the link to their location, but I don’t know why. No other previous version of KStars OSX did that.

As the night was clear and I needed to finish a target, I quit this version and launched one from May 11, which worked perfectly.

I’ll go back in and see if I can figure out what happened to the solver index files later today.

1. That's correct behavior for "Load & Slew" if "Automatic & Manual Rotator Control" was toggled.
2. Completely unrelated issue, did you check the index files settings? what makes you think it cannot see them?

Hi Peter,

It would probably be better to start a new thread for this. I don't think its likely that this is related to Focus changes, and I'm afraid I don't know much about the rotator code. A new item on the forum would attract the attention of a wider group of developers that may be able to help.

Also, can you clarify what you mean by "Calculate and Slew" - did you mean "Capture and Solve" or something else?

John.

Ok, I'll add a new thread after I do some more investigation.
Yes, I made a mistake with my description, which is why Jasem made his comment. I meant "Capture and Solve", which is NOT supposed to move the rotator as far as I know. It never did before, only "Load and slew" did. I have edited my original post.