×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

New Focus Algorithm in Ekos

  • Posts: 70
  • Thank you received: 9

Replied by Damian on topic New Focus Algorithm in Ekos

Do we know when this will make it from nightly to stable PPA please ?
I'd love to try the Linear 1 Pass but I cause enough problems of my own with my rig, without adding the nightly code into the picture ;)
1 year 8 months ago #84076

Please Log in or Create an account to join the conversation.

  • Posts: 593
  • Thank you received: 274

Replied by John on topic New Focus Algorithm in Ekos

The plan is that 3.6.0 (which will include L1P) is released 29th July.
The following user(s) said Thank You: Damian
1 year 8 months ago #84080

Please Log in or Create an account to join the conversation.

  • Posts: 70
  • Thank you received: 9

Replied by Damian on topic New Focus Algorithm in Ekos

Fabulous. Thank you John
1 year 8 months ago #84082

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
John, I have a question.
Actually, it was more than one, fortunately I first read through your PDF more carefully, which answered them... :whistle:
I've been running L1P for a while now, with one instance being an OSC camera connected to an oldish Canon FD lens that has some longitudinal CA issues.
It turned out that I got a nice and sharp red channel, with the other two being mildly and strongly defocused. That is an issue that Rob Lancaster had spotted (and, AFAIR, taken care of) that for debayered images the first channel (=R) was used for focusing, which was changed to using the second one (=G). And I was quite sure I had tested it successfully before (at that time with Linear)
So my question is whether you do handling of image types in your code (and use the first channel), or if something else went wrong with that patch. Or I'm doing something wrong of course....
Pit
1 year 7 months ago #84826

Please Log in or Create an account to join the conversation.

  • Posts: 593
  • Thank you received: 274

Replied by John on topic New Focus Algorithm in Ekos

Hi Peter,

L1P leverages existing code to take exposures so as far as i’m aware it would be the same as the other algorithms (e.g. Linear).

I don’t have a OSC DSO camera so i can’t try this myself, but what did you do before L1P and / or how do you think this should work?

Are the channels not parfocal with the OSC? Or is the lens making them non-parfocal? If red is in focus but the green and blue aren’t how do you use this setup normally?

Sorry for all tje questions, just trying to understand the issue. (I vaguely remember seeing a thread about plate solving with OSC where there was discussion about which channel to use).

John.
The following user(s) said Thank You: Peter Sütterlin
1 year 7 months ago #84833

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Hi John,

I assumed that, but wanted to be sure. So I need to dig out that other thread and see what the status there is.

I'm still experimenting a lot, so 'normally' doesn't yet exist...
Yes, they are not parfocal (at the tiny pixel size of that camera), it's a lens error. The lens is from the times of photographic film where the "pixel size" was much larger than this error. So I somehow need to find a way to find the best compromise. Usually that is the green channel.

Hehe, I was the one who started asking... Yes, likely it was that thread, as SEP/stellarsolver is the recommended star/hfr detection method for focus. Maybe using a greyscale image might give better results - though there white balance might play a role which opens another can of worms.

Anyhow, thanks for the response (and L1P, of course).

Pit
Last edit: 1 year 7 months ago by Peter Sütterlin. Reason: Where are the quotes!?
1 year 7 months ago #84834

Please Log in or Create an account to join the conversation.

  • Posts: 47
  • Thank you received: 6
A quick question now that this is merged into 3.6.0.
Later versions of the EAF INDI driver include a backlash compensation setting at the indi driver level. Should this be disable for this algorithm to work optimally?
1 year 7 months ago #85621

Please Log in or Create an account to join the conversation.

  • Posts: 47
  • Thank you received: 6
I'm about to update and I was wondering if there is any experience about this. Logic would seem to suggest that setting backlash compensation at a driver level would fight the internal backlash compensation of the algorithm? Any first hand account?
1 year 6 months ago #86039

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Why should they fight? The algorithm just sends (additional) tuning commands to ensure you are out of a possible BL. They don't do any harm if there is no BL. Whether the latter is because the system doesn't have it, or because a driver-internal correction is in place, doesn't matter.
I have the driver BL correction of my EAF active, and no problems with the two linear algorithms.
1 year 6 months ago #86041

Please Log in or Create an account to join the conversation.

  • Posts: 47
  • Thank you received: 6
Great to hear that. To answer your question, I thought they would fight because apparently the way the driver level BL comp works is by moving the equivalent of x-steps, where X is the BL level, without returning that as a value in the resulting step position, so that creates a discrepancy between step value and shaft position. E.g. say you are at step 20 and your last move was in. Your BL comp setting is 10. You move in 20, motor moves 20 and final value is 40. Now say you move 20 out. Motor moves 30 out, but your final value is reported at 20. So if the BL is not in the EAF, now You're at a shaft position of 10, with the driver reporting 20. I thought this would throw off BL calculation at the Linear algo level, that's all. Glad to hear that I am wrong!
1 year 6 months ago #86051

Please Log in or Create an account to join the conversation.

Time to create page: 0.822 seconds