Does SGP talk to Planewave's PWI AutoFocus?

OK, here are some results from yesterday evening’s AF session.

As expected, conditions were not ideal: near full moon, wind gusting but my site somewhat sheltered, and seeing likely impacted by strong jet stream winds, But notwithstanding some thin haze I was able to work continuously from c19:00 to 01:00. Luckily ambient temperature held reasonably stable for much of the period.

My first exercise was to use GoldFocus to establish what the package describes as ‘Near Perfect Focus’ for each of my filters. I managed 5 results for L (one of which I discarded as it seemed aberrant), 2 each for RGB, but only one for Ha. The results were very close for each filter (apart from the one L).

A problem with GoldFocus (I think) is it tells you when focus is good/near perfect) but does not output the actual Focuser Position or the temperature, so had to keep running out to read the LED display on my Lakeside!

When my second attempt at Ha focus with GF failed I switched over to SGP. Overall, I managed some 40+ AF runs using a sequence L, R, G, L, B, Ha). Each AF run was followed by a single 60s 1x1 exposure.

Despite the iffy conditions, no AF runs failed until the sky was completely filled with small fluffy clouds. SGP even managed to complete AF runs even when PHD was losing its guide star?

I have summarised the AF results in the attached spread-sheet. The results are sorted by Filter.

To make the results as consistent as possible for comparison I:
a) Use SGP AF Log Viewer to determine the Temperature Correction Coefficient (TCC) for each filter,
b) used the TCC to calculate a ‘near perfect FocPos’ appropriate to the Temperature and Filter used in each AF run.
c) calulated the variance between the AF actual FocPos and the Temp Corrected GF ‘Near Perfect’ Foc Pos.

What I obeserve is:

a) The variance results for L are undoubledly the least and most consistent- most encouraging.
b) In order of least to greatest variance the results by filter are: Red, Green. Ha, Blue.
c) While the Ha and Blue results show the greatest variance from the extrapolated GF NPF, the variance within each set of filter results is actually not so great which suggests to me that either
i) my baseline GF NPF is incorrect (only one value for Ha)
ii) owing to the limited temperature delta, there is a strong possibility of error in the Temp Correction Coefficient.

Conclusion: So far I am favourably impressed with the ASTAP based AF. Not a single AF run failed and this near full moon and unfavourable weather conditions. The ability to continue AF when PHD had about given up was most impressive.

Attachments:
a) SGP logfile
https://www.dropbox.com/s/f4h0ct8rz263514/sg_logfile_20201102184706.log?dl=0

b) Excel Results worksheet

c) Managed a result even with images like these

@Jared :
I noticed what looks to me like an odd oscillation on the Image History graphic. It only seemed to appear on chart for Lum filter.

Mike,

Impressive and thoroughly investigation. The most important indicator HFR seems pretty stable.

The temperature coefficient could suffer from delayed cooling down of the materials and be complex. The trend is one way so that is good. Using your data I have put the L focus position against the temperature and a second order polynomial trend line fits nicely. The main factor is 21.7 focuser steps per degree Celsius. The spread around the polynomial fit is small.

Han

The image history is still using the internal calculation. Literally the only metric changed over was the one used for Auto Focus. Even the Image Statistics and the highlighting of the stars seen in the image behind the graph is using the SGP metric.

Jared

@Jared

Hi, Please ignore my comment about the Image History. I notice I had an alternating mix of 10s and 60s exposures. Fewer stars detected in 10s exposures.

Mike

Mike, I had look again to your images AFID-49_1. Using the ASTAP image inspector I see it detects about four pair double stars as single stars. It doesn’t influence the end result since there are enough single stars detected. But I had a look again in my code why.

In the past ovality measurement was used to exclude double stars and galaxies. It is still used for a focus routine I helped to write, but for ASTAP the main intend is solving and the ovality measurement was abandoned for an other approach. Now It detects if 2/9 of the boxed object has illuminated pixels. In general this worked better for solving especially for images with poorly shaped stars. Maybe this has an effect on telescopes with a large obstruction displaying defocused ring shaped star patterns, but I don’t expect so.

Han

@Han,
,
First thanks for your endorsement of the approach. I am still most impressed with the result obtained with the Lum filter. @mikael I am most curious to see what the SGP values might result from a well chosen hyperbolic fit. I will save the AF packs in case they are of value for testing.

I am now somewhat annoyed with myself for not persisting to obtain more GF results with RGB&Ha filters to average as I observe that a small change to the GF NPF values is sufficient to get the predicted FocPos as closely aligned to SGP results as obtained for Lum result. With Lum the average departure from the predicted Near Perfect is <3 which with my set up is less that 12 micron!

After each focus run I took a 1x1 binned image. Loading these images into ASTAP and APP I observe that there is a very low spread in the calculated HFD/HFR values. I’ve not done the maths but I think the std var for these images would be significantly lower than for a similar bunch of images captured after the old SGP focus method.

I am so far very convinced that the ASTAP method is:
a) more resilient than current existing SGP - no failed AF runs despite poor conditions, especially towards the finish.
b) More consistent - much closer bunching of the HFR values around the best obtained when image stacking.

@Kurious_George, @Ross_Walker ,

Hoping you guys will be able to test this change with your scopes quite soon.

Mike

Hi folks,

Here’s new focus data from a Planewave CDK24 to test with. This likely contains objects that would skew the SGP algorithm, although I didn’t verify that…

https://spaces.hightail.com/receive/HoVC2bACZe/Y3VyaW91c2dtb25rQGdtYWlsLmNvbQ==

KG

Looks all good in ASTAP. Unfortunate the focus position and RA,DEC position are missing in the FITS header. For the focus position I assumed linear steps of 100 between 1000 and 1700. Then the focus is found in the inspector tab at position 1332. The curve is a little asymmetrical but when I manually use the wings (green lines) I come to a little higher focus position. Probably a little larger steps will give a more reliable result.

The galaxies don’t spoil the detection. As you can see the 5 yellow marked values (center and corners) and the square rectangle in the last two screen shots show no real tilt in the detection.

Han
ASTAP inspector tab

ASTAP inspector result copied to a spreadsheet:
focus2

Hyperbolic curve fitting using the hyperbolic parameters from the ASTAP inspector tab and the green lines for a manual estimate of the best focus position.

ASTAP CCD inspector and Hyperleda annotation near focus:

Most out of focus position

@han,
Hi,

Thanks for your analysis - more comprehensive to what I could manage with Excel.

I think the FocPos is indicated by the File name with step size of 350. Looking at the results file I assume PWI / PI has given the near perfect focpos as 5689.

@jmacon

I guess we need someone with access to run SGPs parabolic/hyperbolic curve fit to determine a new SGP result for comparison with KG’s ‘gold standard’ result!

Mike

Aha , okay focus position from file name. Then I get for the center 5693 as the best focus position and 5696 for the full-image. Looking to the bottom of the curve all values look good enough.

This looks very good. Yes, focus position is in the filename.The Planewave PWI3 focus algorithm calculated 5689.2, so you’re spot on.

How does this compare to the current SGP algorithm?

…and are the outliers being rejected? There’s 100+ detected stars. If we had less stars and the outliers are not being rejected, it may be off like SGP is now.

As I mentioned earlier, SGP doesn’t appear to have an issue with the curve fitting. The issue is with the outlier rejection.

Visually I count 16 outliers in 277 star detection’s. Most outliers are galaxies. In the ASTAP inspector screenshot, the size of the red squares are proportional to the HFD value. But taking the median solves the outlier problem. You sort the HFD values on size and take the value in the middle of the list. As long the stars are in the majority, the median will be good representation of the HFD.

Note also that the five yellow values are very equal. So the detection in consistent and works for the four corners and center of the image. Sensor tilt, curvature or poor detection would skew the five yellow values and the yellow square.

The detection indicates a small tilt. The values on the right side of the image are a little higher. If this tilt is reported for an other image series of a different parts of the sky, I would consider it as confirmed. According the inspector the tilt is about 35 focuser steps. Bottom -22 to +22 equal 44 focuser steps and for the top -15 to +12 equals 27 focuser steps. (Note the inspector tab has limited field testing and in beta)

1 Like

The tilt could be caused by the clamp connection of the camera. Loosing it and tightening it again could fix it. Or rotate it 180 degrees and see if the tilt rotates

Not clear if the tilt you show is due to non-star objects? Any way to show the tilt with all outliers removed?

…and does the current SGP algorithm use median? If yes, I would expect this new technique to yield the same performance and the current SGP algorithm.

This is a best case scenario because there’s so many stars.The problem is magnified as stars decrease and/or galaxies and double starts increase.

As I mentioned earlier, the Planewave focus algorithm ALWAYS works. It never uses double stars or galaxies.

The galaxies and outliers do not influence the measurement. The tilt measurement is very sensitive. My system has about the same tilt and I can’t adjust it. Having screwed connections fixed most initial tilt.

How does PlaneWave system seperate galaxies from stars? From only a shape detection that would be almost impossible to realise. From a video I saw earlier today, it gave me the impression that they use a combination of PlateSolve2 (database?) and MaximDL, but public accessible documentation seems not available.

Yes, PlateSolve2 (star database) and MaximDL. Beyond that the details are proprietary,

The galaxies and outliers can influence the measurement considerably, especially when there’s not many stars and the outliers are not consistent (i.e., sometimes included and sometimes not included depending on the focus position). This is what started this thread.

IMHO, it’s not a curve fitting or tilt issue. It’s an outlier rejection issue.

I would be very surprised if PWI would use plate solving for focusing making it very complicated and prone to failure. Using the star detection of Platesolve2/3 makes more sense.

I agree that SGP curve fitting works. Outlier rejection is very simple having a good measurement. I think we are now come full circle, but IMHO, the main area to improve is the star detection. The measured HFD results by SGP within one image have a too large variance even in simulation. The correct approach will be to improve the detection and not a better outlier filter. You could test this assumption with SGP (4 beta version) focuser option " HFD - ASTAP". But install ASTAP v0.9.441 or higher.

omoeohlajmioejle

1 Like

Looking to video the below, at 5:55 minutes MaximDl take 5 images and PlateSolve2.28 analyses them and reports only star diameter. Then PWI software process these 5 values and you can select V-curve fitting or Quadratic fitting.

That means PlateSolve2.28 (and 2.29 as bundeled with SGP) can analyse images on star diameter. Maybe something for @Jared to investigate because I don’t think this feature is used in SGP.

The resulting PWI V-curve doesn’t look that good.