Beta 2.5.1.1 - Exception in FindStars

it never worked. i was previously running 2.5.1.0, and had found that on the inside of focus, toward the end of the focus run SGP would start picking up hot pixels instead of any donuts, and compute a crazy-low HFR like 1.2, which then completely confused the calculation. so the first thing i tried in 2.5.1.1 was to set the minimum star size slider a couple of notches higher than the default, hoping that would fix the problem. when it detected no stars, i started messing with that slider to see if there was any effect, and there was none. subsequently i found that if i loaded some real, in-focus exposures, no stars were found either, and thats when i noticed the error in the log.

Hello,
same observation here, no star detection, adjusting the sliders does not change any thing.
Regards.
Pascal

Piling on here…
I noticed the “no stars” thing when I loaded v2.5.1.1 on the home computer and then pulled up an AFPack image from the previous night. Thought it was curious.
Last night I tried some AF from the OBS. The sky was overcast so expectations were low.
The focuser moved out the prescribed amount, but did not change after that.
Plot points were extremely slow to generate and fell at the zero HFR value.
No stars were selected during the procedure, even though they were evident on the screen.
A note at the bottom said the focus was expanding the range (smartfocus was turned off).
This was on my 12"LX200 with Starizona SCT corrector.
Apologies for no logs. I’m currently on the road.
Mark

I don’t quite know where to post. I loaded 2.5.1.0 and the focus routine appeared to not work. It was a clear night and I wanted to image. As a result, I want back to the stable release 2.5.0.23 and forgot about it. The problem with 2.5.1.0 was that it detected absolutely nothing at least with the focusing option that does not use pinpoint. I forget, but I think that is the HFR focus option that I used. I did not use the focus option that needs pinpoint, which I have.

Last night I downloaded 2.5.1.1 last night and came up with the same issue. Absolutely nothing detected. In addition, I could not follow the direction regarding the star size option. It was like the program did not load correctly. The HFR focus option (does not use pinpoint) did not have the sliders greyed out. Don’t know what was going on.

Then I changed to the option which used Pinpoint and for the first time ever, it drew one of the finest almost V shaped slightly U shaped curves I have ever seen on my screen. It was fantastic. In the past, the focus option was picking hot pixels and parts of columns for the first report on the graph and I knew that it also lowered the arithmetic average of the FWHM reported. I would get readings of 1.8 and 1.2 and I knew that this was impossible. This time for the first time the first data report always reported correctly around 4.2 or so. It then went down to the expected value of 2.5 or so.

It thought it was an anomaly, but found that it worked very well all night long. I am not changing a thing for now. I started to save the focus packets and can send them along via dropbox if you want them.

Good work guys for now. Focusing is a huge issue and if you keep going in the direction you are going with the improvements, you are going to greatly enhance your product.

I image with a GSO RC10 at 1700 mm and 2000 mm with robofocus and feathertouch focuser.

Hi,
I have just realized that at the Profile Manager the Star size option is grayed, but at the Control Panel (the DSLR camera icon) that option is grayed out and you can use it.

Tonight I’ll do a test. Yesterday it was raining but it seems I’ll have some clear hours tonight.

See you

This issue is specific to 2.5.1.1, it is working OK in 2.5.1.0.

My quick tests this morning are always: open SGP, open an image, run the HFR calculation, close SGP
2.5.1.0 it works. i.e., it detects stars and returns the HFR calculation (log: sg_logfile_20160408095911.txt (20.2 KB))
install 2.5.1.1, I have the error (log:sg_logfile_20160408100054.txt (20.3 KB))
downgrade to 2.5.1.0 (actually requires two runs of the msi), it works (log: sg_logfile_20160408100250.txt (20.4 KB))

well this is good news; sounds like if the native star detection starts working again then RC owners are going to be in good shape!

OK folks,

Sorry for the delay. We were traveling to NEAF. I took a look and this is completely my fault. I left code in that would only work on my development machine (so all the tests passed). I am not in a position to make a formal (signed release), but you can access the fixed version here:

Quick feed back: Loaded several subs from various targets to test HFR routine. It is now showing the HFR of multiple stars but the “Minimum Star Size” slider has no effect. It always detects 300 stars on every image – even ones that only had a total of 42 stars visible. It seems to make no difference whether the slider is at 2 or 15.

Charlie

Don’t worry about that. The minimum star size refers to minimum diameter not sample size. There might be a bug in star count UI stuff. We are just concerned with V curves at this point.

Also I can’t remember if the slider works in real time for images opened from disk.

Are you seeing stars selected that have a smaller diameter than you allowed?

Autofocus routine a dramatic, drastic improvement. Spectacular Just confirmed it works great on my RC10 again tonight. Great job. User interface may need help. I am at the machine and am using Full Width Half Max with Pinpoint. Have not tried HFR but when I did in the past it did not work. I am going to leave it as is because it works fantastic for the time being until you do another release.

Thanks for this enhancement.

Doesn’t the slider determine how many stars are detected? If I set it at 15, I expected that only star images that are 15 pixels in diameter (or larger) would be detected. Maybe clusters of hot pixels look like donuts to the algorithm?

Before invoking the HFR calculation, about 40 stars:

After clicking the HFR icon - 300

But then something strange happened. I had undocked the Focus Control module to have it floating over the image so I could take the screen shot above. Then when I re-docked the module on the side of the screen the star detection suddenly changed; that is, it started working correctly:

The slider works in real time – move the slider one notch and the HFR calculations / star detection is immediately re-done. So, some kind of initialization error causing the initial 300 star detection – like the star size was set to 1 pixel.

Charlie

No, not really. It determines what stars are selected… doesn’t really care about how many. We won’t use more than 300 for the HFR calculation, but that is separate from star detection.

Not really sure. You were able to move the slider around and nothing changed until you re-docked then undocked again? Any other hints? Did SGPro start with that module docked? Did you do it after startup? Did you ever toggle the HFR “star” button during this process?

I wish we could claim that this was a recent victory, but in reality, there have been no changes to the Pinpoint based AF routine in years.

i can’t do any live testing due to clouds, but i’m seeing the same behavior with an image loaded from an AF pack - no matter what the slider is set to, it seems to behave like the slider was set to 2. if i then just grab the slider and move it, the ‘hot pixel’ stars are no longer identified. so it would seem that when the very first image is loaded, the user’s minimum star size setting is not applied until it is changed.

i should probably send in this particular pack - SGP seems to only be able to find one donut star in this image though there are many more of similar brightness.

After installing your updated beta, I opened a saved image and clicked the star button to do an HFR calculation on the image. The slider was in the default position and the Focus Control was docked on the side of the screen with several other modules. The image frame was immediately covered with 300 star detections as the screen shot showed in my post above. Since the slider was in the 3 (?) pixel position, I moved it to the right thinking that would reduce the number of stars detected and toggled the star icon. Nothing changed and the image still showed 300 stars detected. I moved the slider to 15, toggled the star icon; and, again there was no change with 300 stars detected. I moved the slider several more times, toggling the star icon each time. Nothing changed.

At that point I decided to make my post with the result. In order to do a screen shot, I undocked the Focus Control and moved it over the frame and made the screen shot. After taking the screen shot, I moved the Focus Module back to its docked location on the side of the screen. As I docked the Focus Module, the frame suddenly changed and dropped to just a handful of detections – as shown in the third screen shot. With the Focus Control docked, the slider worked as expected. Moving it immediately changed the HFR calculation and the number of stars detected without the need to toggle the star icon. I used the left and right arrow keys to move the slider one pixel at a time to watch how the star detection changed at each step. Everything seemed to be working great.

After making my post, I continued to experiment with subs from other targets. What I then discovered was that the slider would intermittently stop working – that is, moving it did not result in a new HFR calculation or star detection. Even toggling star icon had no effect. Undocking reactivated the slider.

Unfortunately, some frames that I tested resulted in virtually no stars being detected even though they were above the slider threshold. In the frame below, the slider was at 7. The frame shows two false detections at [7x7], two stars correctly detected, and about 40 stars that I thought should have been detected but were not:

All my subs were taken at 2475 mm with a large central obstruction but there are no donuts in the subs as they were reasonably well focused manually. My PC is a Windows 7 machine.

Charlie

That is too bad. The HFR routine does not work for sure but the, I guess old pinpoint related routine, is working great for some reason. I guess I finally tweaked the settings correctly. Apologies. The HFR routine does not work for sure. I abandoned it and played more attention to the Pinpoint related routine and hence the success.

I really have no idea what this is or why it’s happening. I cannot reproduce it. I followed the instructions above and my slider works immediately in real time. Not sure what’s different… what I can say is that I don’t think it’s super critical to the process of refining AF. It’s most important that the actual AF routine respects that number… Not saying I’m giving up on that part just that we need to look at other aspects first… like the image you provided above. If you want, you can make that FITS image available and we can take a look at why the AF routine is skipping so many stars.

Hello,
if this can help, I encountered exactly the same problem that chasmiller46 here, sometime stars are well detected and sometime not.
Strangely, one of the image I used is also ncg3628, and I got exactly the same result as chasmiller46.
Some stars that appear to be in the good size range, are not detected.
Thanks.
Pascal

some complement to my last comment, on ncg3628, in some subs, stars are well detected in other not, depending of the filter I used … my green subs have the worst star detection (the best is with the luminance, where dozens of star was detected, only two or three with the green filter subs), may be because these subs are more noisy that the others. Noise and/or background level seemed to play a role her… may be.
Thanks.
Pascal


Ken:

The image with the undetected stars is in a drop box:

Dropbox - File Deleted

I did some more testing of the HFR routines and made careful notes of the exact sequence of events that I used. What I found was that sometimes the HFR routines worked correctly other times the exact same sequence resulted in the HFR routines failing completely. Whether the HFR routine worked or failed seemed completely arbitrary.

As a commercial software developer, I have seen this same behavior in my own code. It can be caused by an uninitialized variable used by the HFR routine. Sometimes when SGP is started, that variable gets a random value that is compatible with the HFR routine and it works. The next time, that variable gets a garbage value that causes the HFR routine to fail. Just thinking out loud…

Charlie