This is not specific to AP mounts, so please forgive me if this isn't appropriate here.  I figure this is a pretty sophisticated group that may have some answers.

I will also post this to CN but the SNR on those threads can be quite variable.

I'm trying to use the NINA plugin Hocus Focus (HF) to adjust tilt on a Planewave DR 350 with QHY 600M.   I have the Octopi Astro tilt adapter.  General info is that you want 10 microns or less tilt because it is so fast.

 

Here is a very high level summary of how HF works from a user perspective.  HF takes a series of exposures which sweep through focus, in the same manner as an autofocus algorithm.  It plots a curve of the focus (star diameter) as a function of focuser position, but rather than do that overall, it divides the frame up into 5 different regions - each corner, and the center.   This gives it the optimal focus point (smallest star diameter) for each corner.  If these are the same, there is no sensor tilt.  If they are different, then HF tells you the relevant amount each corner needs to move - in focuser steps, or if you tell it the size of a step, in microns.   You can then use your tilt adapter to put the adjustments.  

 

ASTAP has a similar scheme which is discussed in a CN thread, which also gives some internal details, which is great.  This has informed my understanding of what HF likely does.  However, I am using HF not  ASTAP and I haven't found the comparable details for HF. Even if I were using ASTAP, I would have pretty much the same questions because of how ASTAP is implemented.

 

Here are some of the technical issues that make it hard to use HF up to its potential.  

 

1.  It is not clear where in the sensor frame the offsets are supposed are measured/defined.  Each offset is labeled  (i.e. "bottom left corner"), so one could guess that it is the extreme corner of the sensor, but I am not sure this is the case for reasons discussed below.   This little detail matters a lot - a tilt angle is offset over a baseline, but you need to know the actual X, Y coordinates of the location where the offset (in effect a Z coordinate) are specified to know the baseline. Does anybody know where this is?  Some more details are below.

 

2.  This might seem like a simple documentation issue, but it seems that HF uses an average (mean or median) within the region of the frame that is measured means that (but perhaps not).  ASTAP definitely does this, as discussed in the other thread.  Unfortunately, when you use a mean or median across the region you make the X, Y coordinates where the offset is measured into random variables, which depend on the tilt.  This can be avoided with a better statistical technique (see below), but I don't think this is being done in HF.  This introduces some unfortunate uncertainty in the question above about where the offsets are measured.  So even if the answer to #1 is "its the frame corner", the follow-up question is "how is that calculated?".

 

3.  Once you have the 4 offset numbers from HF, there is a further problem which is that the offsets are presumably relative to the sensor, but the adjustment screws are not at the frame corners.   They are much further away from the center of the frame.  That's good because a large excursion from the screw has a smaller effect on the sensor.   The Octopi Astro adapter uses 200 TPI threaded adjustment screws so one turn is 127 microns.  Although that is very fine for a screw thread, it is pretty coarse for sensor tilt.  But it means that one needs to convert the HF offsets into actual screw displacements. 

 

4.  The screw displacements are not just a multiplier on the HF displacements, because the 4 screws on the adapter do not lie on the sensor diagonals.  So, there is no 1:1 mapping between the sensor offsets and the screw offsets.  I have derived the formulas for converting from offsets at three or four points on the sensor into 3 or 4 screw locations, so I can write a simple program or spreadsheet to convert from the sensor offsets to .  It certainly would be nice if HF (or ASTAP) did that for you.   It would mean you have to input the screw locations, or perhaps just say what tilt adapter you are using.

 

5.  Turning screws - even 200 TPI screws - is a very crude way to input an amount because it is 127 microns per turn.  General info on other CN threads say that I should shoot for <= 10 micron deviations from a squared sensor for the DR 350.  Doing that means eyeballing, how much of a fraction of a turn you turned on the screw.  Half turns are OK but when you get to eyeballing 1/8 turns it is not very accurate.  This is a hardware issue, not an HF or ASTAP issue per se - but it does limit the utility of the software.   I am planning on solving this by installing 4 dial indicators that measure to 10 microns, one near each of the screws.   

 

So those are my basic issues and questions.   Some explanation appears below.

 

One might say - hey if it is really that bad, how can HF / ASTAP be usable under these circumstances?  Partly this is because I think that most people (including me) wind up using HF in only partly quantitative way in a feedback loop - run HF, make adjustments to each screw that are roughly what the program says, then run it again and repeat.  In this mode the exact quantitative offsets are less important than the relative movement, but this is very inefficient in time.   It would be much faster to get the offsets you need for each screw, turn them in with a digital display (dial indicator), and then you will be there, or nearly there and might need only one check.    Otherwise, you are running the process over and over again, and each iteration takes 10-20 shots to sweep through focus is quite time consuming.  If I had a permanent observatory, I would go through the pain one night and then try not to change anything for a long time.  But I am mobile so I must set up frequently.

 

HF outputs some debug information which is nice, but not documented.  However, I have figured out some of the issues.

 

I believe HF divides the sensor frame into 9 equal size regions - a 3 x 3 grid, but only looks at 5 of them, and what really matters are the four corners.   

 

For each image taken during the focus sweep, HF finds the stars, fits point spread functions to measure the diameter, and then throws out stars that are too small or too big or not round enough.  That approach is all fine, although one needs to be careful about roundness for two reasons.  One is that tilt makes stars into ellipses.   So if you throw out elliptical stars, you might be throwing out part of your signal.   The other factor is that optics can distort images as you get toward the edge. But my guess is that this is all done correctly.   ASTAP does something similar.

 

ASTAP then takes the median diameter across the region, and I suspect HF may do the same thing.  The goal is simple - one doesn't want noise in the measurements to corrupt the signal.   However, this is quite ill advised because tilt has a linear gradient on focus across the region.   That's pretty obvious if you look at an image from a tilted sensor.   Taking the mean or median actually throws away most of your data.

 

The median of a linear gradient across the region would, under ideal circumstances, throw out all of the values except the one star that is at the region center.  That means you are NOT measuring the tilt at the actual corner, you are measuring offset at the region center.    It's a big flaw with using median in this case.   Using the mean introduces a similar effect - it is slightly more vulnerable on large outliers than median, but absent huge outliers should give a more accurate result with respect to small amplitude noise (and there are other ways to get rid of big outliers).  

However the measurement is only at the exact center of the frame if you have enough stars, and they are uniformly distributed in the frame.   Even if you throw out stars that are too big or too small, you may also have an effect on whether the brightness of stars is evenly distributed across the frame.  This means that rather than the actual center of the region, you have actually measured the offset at some random location near the center of the frame.

 

A further complication is that the optics may have some field curvature issue. That will further bias the median or mean - either toward, or away from the center of the frame.   If the sensor is not perfectly centered on the optics, then the effect will be asymmetric.  

 

For these reasons, I am pretty sure that the tilt offset that ASTAP and HF measure is the sensor displacement at a somewhat random location near the center of the corner regions.   Because you don't know the actual location the offset is measured at, you don't actually know the sensor tilt.  Or, anyway, you know it over a shorter baseline, with less accuracy, than you may think you know it.

 

The correct statistical approach here is very simple conceptually:

 

-  Don't bother cutting into regions - that is unnecessary (and even harmful to accuracy) - use the whole image

-  For each image in the focus sweep, process the stars more or less as they are done now in HF.

-  This gives you a set of stars, each with an X, Y position (center of point spread function), and the measured diameter (FWHM or other).

-  Connect the stars from each image in the focus sweep, and make a focus curve for each star.

-  Fit a hyperbola to the focus curve for each star, which gives you the optimal focal distance Z for each star. 
-  This has the added benefit that by comparing each star to itself you avoid most issues with the distribution of brightness.

-  You now have a set of data - X, Y, Z for each star.  Do a least squares fit of a plane to the data.  This gives you the 4 parameters that define the plane.

-  Given the plane parameters, you can find the screw offsets by taking the X, Y of each screw and determining the Z

 

As a quality control issue, one should check to see if the stars are reasonably distributed - if the stars are all clustered on one side of frame - either because of the region of the sky, or a cloud - then this won't work, but neither will the existing algorithm.  HF will sometimes say "autofocus failed" and lack of sufficient stars may be why  - or may not, HF could be a bit more informative as to why it failed.

 

I am calling this the "correct" statistical approach because it deals with the fact that tilt introduces a gradient. The method that ASTAP uses (and likely the method that HF uses) actually destroys gradient information by blocking into very coarse (only four per frame) regions.   It also deals completely with field curvature, and the sensor being off center with respect to the optics. Meanwhile, lumping stars together within a region and taking the mean or median of the region interacts poorly with each of these features of the problem. Sensor tilt determination is fundamentally fitting a plane to the data. In general, one should never average data before a curve fit.  The whole point of least-squares fitting is to make the best estimate - averaging up front only messes things up.

 

Also, it is almost always better to use well understood methods like least squares curve fitting than to do an ad-hoc approach of coming up with average focus distance at each region and saying well, that must approximate the plane. 

 

I am pretty sure HF is doing something similar to ASTAP.   It does not seem likely it is doing a focus curve per star, because it draws the 5 regional focus curves, rather than the 500 - 1000 focus curves for each star.   I guess in principle I could download the open source code and figure it all out but that is quite a task.  Somebody must know.   

The cost of doing the "correct" approach is potentially a lot more computation, which would take longer.  I doubt that this would be a problem for a modern computer.  As it stands, computation time is small compared to the time of taking the images anyway.   Finally, if the method above is too slow, one could pick a random subset of the stars.

 

The existing HF / ASTAP approach is an approximation to this.  In cases where the tilt is small and you don't mind iteratively correcting multiple times it might be OK.  I am explaining the "correct" approach not to criticize HF/ASTAP, but because this helps illustrate the problems that come from the approximation.

HF outputs some data files for debugging purposes that seem like they MIGHT give enough information that I could write software to do this from those files.  That would be nice if so.  Or I suppose that I could write my own software entirely, but I am mostly a guy who wants to take pictures of the sky.

Any comments or information would be appreciated.

Nathan

 

This is an excellent post.

1. I fully agree that it is sufficient to look at the 4 corners. The reason I believe why HF is using all these regions is that they want to estimate both tilt AND curvature. I think it is really confusing to have all this info anyway. It is far better to separate tilt and curvature into different steps. This is also because when you remove curvature (by adding, removing spacing), you will influence tilt and vice versa.

2. I also think that you have highlighted correctly the challenges of using screws to correct tilt. Not only are screws somewhat "coarse" given the required focusing accuracy for the optics we are dealing with, they also suffer from backlash which can lead to non repeatability. It might be better to use shims once a very precise tilt has been calculated in step 1. 

3. Another option which I am currently exploring is to start with every component as parallel and orthogonal as possible. 
 a. Eliminate focuser tilt in the field by using a high quality focuser that runs on bearings -- not deformable bushings. 
 b. Test every adapter on a surface plate/height gauge to ensure it meets specs -- say within10 microns. I have found that QHY cameras and adapters are well made and are well within spec. 
 c. Build all adapters carefully. I have a machine shop where I can make my own parts and that is quite helpful in ensuring quality.

Further, if there is any tilt observed after all this, perhaps the issue is collimation? It is helpful to have a way to do daytime collimation. For your scope I recommend getting a Hotech Advanced Laser collimator which simulates the parallel rays of a star and uses double pass autocollimation to amplify errors. I know that several manufacturers included TEC use this to do their collimation in their shop.

Another additional thought which I have not yet fully explored is to compensate in collimation any residual tilt by decollimating in the opposite direction. Again, I haven't gotten that far yet.

Nathan,

I posted an article on this topic and discussed both Hocus Focus and astap. It will answer some of the questions you have posted. Please followup with additional thoughts. I'm away from my pc right now but can help chew this topic over with you and the group. I've used octopi on several systems from 130gtx to stowaway to epsilon, all with the imx455 chip cameras. 

See this thread for a link to the article. 
https://ap-ug.groups.io/g/main/topic/95343845#94835

Regarding collimating with the Hotech  -- I posted instructions on cloudynights many years ago. Several people found that post helpful.

https://www.cloudynights.com/topic/509460-daytime-collimation-of-a-cassegrain-scoperc/

The scope in question was a TEC ADL 300 F 5.6 which is no longer made.  As an additional note, it is very helpful to have a precision X-Y stage to make aligning the laser fast and efficient. 

On Sat, Mar 18, 2023 at 06:54 PM, Nathan Myhrvold wrote:

Great – I will take a look.

 

In related news, I got onto the NINA Discord server and had a conversation with the author of HF.   It turns out that HF already does have a mode I didn’t know about that does the per-star focus curves with an overall curve fit pretty much as I mentioned.  I didn’t know about it!   

 

However, HF does not do adjusted offsets for your screw positions.  But the HF author wants to add those.  I am going to send him some data and my formulas.

 

Nathan

I'm not sure how helpful the sensor model is for suggesting which corner to move. I believe it assumes that the image circle is infinite and that only simple defocus occurs with tilt. In reality we have field curvature and astigmatism which confuse the measurements. This error is easily seen with the backspacing analysis. It's unreliable for large chips. I've had many conversations with George about HF from the beginning and it is a really great resource despite some of the limitations.  I'd like to see some sort of sanity check for corner measurements. Not sure if eccentricity could be used or not, but HFR (Hocus focus) and HFD (astap) are not the most robust proxies for tilt analysis when issues other than simple defocus are experienced (such as eccentricity and astigmatism)

The problem with eccentricity and astigmatism is that if they are present, hfr measurements may place the vertex of the "optimal focus curve" at the wrong focuser position.  You can mitigate this by using an ROI to eliminate these aberrations from the analysis, but at the expense of measuring the very stars we are agonizing the most over. 

Even on a single star basis hfr assumes only defocus as the variable. Astigmatism and eccentricity confuse the measurement. Hence the optimum position presented by the algorithm has error.

When youbare only measuring focus and defocus across the entire chip you must be assuming the image circle is infinite in size as you are ignoring the effect of field curvature and astigmatism.  

By the way Nathan, your thought process is spot on. I'm in agreement with your logic. I only bring this up to illustrate a shortcoming with using hfr as the proxy for tilt, which may not steer you to your desired goal. 

Let me ask you this:  what would you prefer, a very tightly focused star with severe astigmatism, or a round star with a slightly higher fwhm?  Hfr analysis will steer you towards the former, when this might not be your end goal. If you base tilt and spacing analysis on hfr alone it's possible that the analysis diverges from your idea of a visually "good looking star."  

This has been my experience and both the Epsilon+imx455 as well as the 130gtx with QTCC+imx455. Inwas able to successfully use the analysis to get most of the tilt error out, but the final 10% required visually tweaking. Both ASTAP and Hocus focus were going around in circles once I got my field very close to perfect. 

I completely agree with you that for any of this to work you must have a well collimated scope in play. 

I've approached Gaston Baudat from innovations foresight, who has created wave front analysis software for collimation and he believes he can create a solution for tilt analysis that does not depend on the current methods. Not sure how much of a priority it is for him. This conversation does remind me to check back in with him...

It is very cool that this degree of freedom in design exists - thanks for explaining!

The point I am making, is that analysis using HFR is error prone. Maybe you can come up with a method to mitigate this error?  I for one would be very happy if you could. :-)

Devonvolution is not effective with astigmatism, but it is effective with bloated stars... especially RC blurxterminator. 

Here is a comparison I did a while back that illustrates the flaws of HFR analysis:  https://ap-ug.groups.io/g/main/topic/90845381#90967

On Sun, Mar 19, 2023 at 12:42 AM, Roland Christen wrote:

designed the 110 lens to have no off-axis coma, so it can be used without flatteners with small chip camera over approximately 0.6 degree field. It can be used with full frame digital cameras for bird and wildlife images and will produce very sharp images of extended objects, just not point sources like stars. When used with my upcoming F6.6 flattener it will produce round stars even in the presence of sensor tilt

The flattener will be the perfect scenario for programs like ASTAP and Hocus Focus, where simple defocus is the only symptom of tilt. I assume you just have a large enough and flat enough image circle that with proper spacing, field curvature is non existent for a full frame chip. 

On Sun, Mar 19, 2023 at 02:04 PM, Nathan Myhrvold wrote:

Perhaps by backspacing you mean this: autofocus the telescope, then defocus slightly by a pre-determined amount?   Sort of like the filter offsets that are used to change focus when you use filters of different thickness.

No, you can mitigate astigmatism by adjusting backspacing. (The distance between the flattener and camera sensor) .  See the link I shared about the 130gtx+Qtcc. 

I'll look at the rest of your post also, but I'm on my phone right now.