Hi Kirill,

The Aberration Inspector is built into Ekos' Focus module. There are no changes to Indi for it. Its merged so if you pull and build the latest "master" you will have it. Easiest way to tell is that on the Focus screen there is a new button next to "Auto Focus" called "Inspector". If you just take Kstars/Ekos official releases it will be in 3.6.8 which is scheduled for the beginning December.

On your points:
1. Unclear error of margins. I agree it would be good to have some sort of traffic light system: green = good (no point in fiddling any more; amber = quite good but could be better; red = bad, need to adjust). However, I don't know how this would work on different systems so need user feedback to be able to calibrate this.
2. "Direction" of adjustments. This could get very complicated so I've kind of "ignored" it and left it to the user to figure out. I could probably improve this with feedback. The issue is that lens / mirrors all invert / flip the image in different ways so different scopes with different combinations of lens / mirrors will change the left / right / top / bottom of the image which in turn will change what the user needs to do with the tilt device. So, for example, move screw 1 on the tilt device "clockwise" may be the correct adjustment on "scope a" but the wrong adjustment for "scope b". Still with more user feedback I may be able to build in more help for the user.

Looking forward to any feedback.

Ref feedback, here is a thought.... perhaps you could show value using traffic light system at each of the corners to visually tell the user which corners need improving (rather than which screws need adjusting). So if top RHS is showing Red value, I know I need to bring that down and as I move the screws if the value changes to Amber then I know I am moving in right direction.

Thanks for your response John.

I will wait for the new KStars release as I haven't quite got around to building it myself.

Regarding the traffic light system idea you described, correct me if I am wrong but to me it sounds more of a "how close you are to the ideal" kind of an indicator.
I suppose it would use CFZ as its main reference and would light green when the delta between the smallest and the largest solutions (out of 4 corners & center) is within CFZ.

I was rather talking about the measure of trustworthiness, if you will, of the tool's output, as it relates to current atmospheric conditions.
I do not really see an obvious way to quantify that other than having the user run the autofocus routine several times without any adjustments and then fitting the results into some [normal] distribution.
Then you would be able to show, right next to your output of Delta (ticks), how it compares to the calculated standard deviation.
If my Delta readings turn out between -20 and 10, but the standard deviation is 30 (just an example, you could use a derived metric, such as 2 sigma, or whatever else), I would know not to bother any further.

Another approach could be to make use of PHD2's guiding assistant output (or some similar routine) where it estimates the high-frequency atmospheric vibrations, but I suppose it could end up quite sophisticated as essentially you would need to translate those readings (which relate to the camera sensor plane) into what would need to relate to distance of focuser travel in the direction perpendicular to the camera sensor plane.
That, in turn, would probably need to rely on how exactly a star image changes with focuser move, e.t.c..

Now, regarding where (corners / adjustment screws) the adjustments need to be made, I think you have already basically nailed it in your video @ 13:55 where you rotated the 3D graph and said "I'm sort of looking at this towards the telescope".
I think all the user needs to know is how the coordinate grid relates to their camera sensor. From the tool's perspective it means showing

1. Where the telescope is (which side of the sensor plane on the graphic). Maybe just show an arrow towards the telescope where the "Axis of Telescope" label is?
2. Where the top of the camera is, which is already done by the TL/TR/BL/BR labels

The KStars Handbook now has an Aberration Inspector section:
docs.kde.org/trunk5/en/kstars/kstars/too...aberration-inspector

I've been offline for a while, but I used the aberration inspector for the first time tonight.

This is great John!
Once again, well done!

PS: The link above to the KStars handbook doesn't work (or maybe doesn't work anymore).

Thx Fitchie,

The Handbook got reordered recently which I think broke the link. Here it is:
docs.kde.org/trunk5/en/kstars/kstars/eko...aberration-inspector

I made an attempt to use the Inspector running a rather fresh build of Kstars on Raspberry Pi and found it crashing just when the autofocus routine is done and results are about to be displayed. Nothing in the logs at all. Could it be that the graphical representation of results is relying on some libraries that are not bundled in my build of Kstars?

The solution was to run Kstars remotely from the laptop, although on my macOS 12.7.1 the latest Kstars 3.6.9 failed to start, but 3.6.8 did, and luckily it already has the AI.
It was a pleasure to use, but I had to go to the explanation video on Youtube to remind myself that the view is towards the telescope.

Hi Kirill,

The point you mention the crash of AI happens is when AI is doing all its work. If the libraries weren't available on the Pi then kstars probably wouldn't build although it's possible some run time component is missing. You could try minimising the datapoints just to see if it launches. Also, AI uses QtDataVisualization which isn't widely used in Kstars but is used in the star profile viewer. Can you launch this on the Pi?



Did you have verbose focus logging set on? Hard to comment much more without more info.

On the Mac issue you'll need to upgrade to Sonoma to run 3.6.9

Thank you John for this tool: it replaces Hocus Focus for me. What about adding the labels for Camera and Telescope too? Sometimes I forget where is the correct side and have to listen your video

FWIW, in a Bookworm Raspberry Pi OS aberration inspector crashes Kstars all the time and the way around it is to launch Kstars from the command line first setting XDG_SESSION_TYPE=x11.

First seen here: www.indilib.org/forum/ekos/14456-aberrat...rashing-on-rpi4.html

First - Thank you for this tool. I've been using ASTAP for it's inspector but it's cumbersome and the results are not often usable.
A thought about the "traffic light" suggestion above. Could you place radio buttons somewhere to "invert horizontally" and "invert vertically" the data on tilt movements? That way the user can configure the readout to a format that's usable for their particular tilt plate.
Also, my ZWO camera only has 3 tilt adjustment screws. is there a way to display data for adjusting tilt with a 3 screw system? That would be wonderful.
Thanks for the hard work. I'm really looking forward to trying out the Image Inspector next clear night.

Hi,

These items can certainly be done. The issue for me is that since I don't own a device to adjust tilt / backfocus its difficult to take this further on my own in a meaningful way. Happy to collaborate on it further though.

1. The traffic light idea needs some input from users over a range of equipment as to what constitutes R, A and G. One person's R will be another's A, etc etc. So some sort of consensus is required (which will probably be equipment related).
2. The invert buttons are a good idea.
3. Converting the tilt movements to something like turn screw 3 anti-clockwise a quarter turn is something that could be done but would require collaboration. AI already has information on the sensor but not the tilt device so the user would have to specify the location of the screws. For tilt I think if the thread-pitch on the screws were to be specified as well then it would be possible to calculate which screws need adjustment and by how much, to flatten the tilt. For backfocus its more complex: there isn't an easy relationship between backfocus delta and how far to move the sensor - its more a try it, see what happens and try again type of thing.

So, happy to explore doing more on it, if there are folks with tilt devices willing to collaborate.