Hi!

No, to the best of my knowledge (it's day now so I can't test until later), it does not do this. The offset there makes the focuser move a fixed amount of tics after focusing - this to make it possible for using another filter for focusing, which is not parfocal with the current filter. For instance, I use Lum to focus instead of Ha, but there is an offset of 100 tics between them. So after focusing with Lum, focuser moves 100 tics and shifts to Ha.

If I did that, I'd need to use the V filter as my focus filter, and then have an offset. Which is not what I want, for several reasons (among them, wanting to use Lum for focusing with my parfocal RGB filters).

If I set the offset but did not use V as my focus filter, I'd still have the problem of finding focus the first time when shifting from V to Lum.

What I need is a way to handle the fact that there is an offset between V and Lum that makes a shift from one to the other problematic.

Magnus

Not true. Yes, the scenario you describe is one of the applications, but basically the entries set up a mesh of relative focus differences. And they are automatically applied whenever a filter change happens, not only after focusing. If done properly, you can focus on any filter, then change to any other filter, and it should be (about) in focus. Definitely good enough to start an autofocus run...

So if you have 100 difference between Hα and V, focus Hα and then switch to V, it will shift the focus 100 units. If you focus V, then switch to Hα, it will change the focus by -100 units....

Ah, OK. I'll try it out tonight!

Thanks.

Magnus

Hello!

I've now tested Linear substantially for two nights, for my variable star shots. And it is quite obvious that I now use a slightly smaller aperture in measuring those frames. That is, focus is perceptibly better, not just very reliable. So - Thanks, Hy! This is a clear improvement!

Trad off is of course speed. It takes more steps than Polynomial. In my case, I compensate by focusing slightly less often, seems to work nicely.

Magnus

Hello Hy, I've been using linear focus with some success (but still some difficulty too). I have been analyzing the linear focus log output to monitor performance for my setup. I have a couple of comments/questions for you: #1. Would you by chance be willing to promote the "Linear: points=[(x1,y1),(x2,y2),(xn,yn)]..." log message to INFO level so we won't have to run logs at debug level to retrieve the points set? That would relieve some resource burden and be much appreciated. #2 Are you using a specific tool to graph the "points" set post-mortem? The reason I ask is that I don't recognize the syntax for direct import to a tool. I'm having to reformat the set to graph it. If you are using a specific graphing tool that requires the bracketed set, parens tuple delimiters [(x1,y1),(x2,y2)], could you let me know what it is? If you are not post-processing, would you consider changing the format to bracket, bracket form? (e.g. [ [x1,y1],[x2,y2],[xN,yN] ] )? That format is more Python/Matplotlib friendly...no reformat needed. Thanks for considering this request.... cheers, Doug

Doug, I'm not on top of the Python world, but I did write that log line to be compatible with a python notebook, and yes, I just cut and paste it into such a notebook and it works for me.
Here's what I did. I run:
jupyter notebook
(Since your on top of this, I assume you can install what you need to run jupyter--or I can re-look it up if you need)

I have the following in a first code cell
and then in subsequent code cells, where I want to plot the focus, I run this:
where, of course, the points= line is just cut and pasted from the log. That gives me a plot that looks like the attached.

Hope that's helpful.

I'll send Jasem a PR to move the focus summary line to be INFO instead of DEBUG.
Hy

Doug, Just sent the PR to Jasem. See phabricator.kde.org/D29440
He'll review and see if it gets integrated.
Hy

Hy, It's been a year or two since I played with Jupyter notebooks, but as you've said, it works just fine and does the job nicely. If only my vcurve looked as narrow on the bottom as the example you provided from Wouter! Cheers, Doug

I'm gonna revive this thread only to ask if there are any newer tips about the procedure. Tonight I'll gonna try those steps from the 1st post.My main concern is that I had clearly visible stars but I got always the message "no stars detected". (Color camera, 5nm filter, 20" exposure)

 

 

I tend to use the "Full Field" option. Which takes an average HFR of all stars in the field of view (excepting the anulus settings).

I'm still having issues with auto focusing. I've been using the linear process, but I only get a good focus about half the time. After looking at the process, I think the problem is that it is using an average HFR on the full field. The problem seems to be that, as the focus changes, the stars that are in the field changes (as more/less become visible)... so the average changes. This causes the curve to not be a curve!

Is there a way to only point at one star? That would seem to eliminate this issue. Or am I not understanding the process correctly?

Thanks,

Ron

If you deselect "Full Field" then you will work with just one star, be it automatically selected or manually selected. However, if your field is changing during focus then you're probably not tracking very well, perhaps due to poor polar alignment or due to other mount issues.
If your field is not changing all that much then you'll still get a reasonable curve, as long as enough stars are detected, changing the annulus setting allows you to select the stars in the centre of your field, or in a ring between 25% - 75% of your field of view. What you chose for these settings will depend on your target and target type.

You might want to test focus on a non-nebulous target first to get the hang of it, then move onto nebulous targets which might interfere with the algorithms.