Also, SGP developers have been working pretty hard to make FLI camera owners happy especially for KAF-16200 and KAF-16803 CCDs. Not many vendors support this many cameras like SGP does. I believe FLI camera owners have been asking SGP developers to add more support for FLI cameras especially for RBI mitigation and SGP listened and implemented.
It’s not the customers’ job to tell SGP developers to set the priority of how and when SGP developers want to implement their software. If you want to bash at SGP, go buy a different software.
I don’t think there’s anything wrong with SGP’s AF routine. Yes, there’s always room for improvement. There’s a saying “Good enough software is never good enough”. Once SGP has finally finish their higher priority implementation of their software, they may go back to AF routine and see if it further needs improvements.
What?!! I come back to see this thread is going the wrong direction, can the people who have no issue with Autofocus just refrain from making drive by comments that are not really adding to the request. The developers do not need any help defending, they are free to do whatever with what we observe and like to be enhanced …
Again, I have about 5 different setups some work beautifully with nice V - Curves and some not, even after all the tricks in the book … as do some other here in this thread. I changed everything, from gain to iso to binned and not binned, changed camera’s used all kind of filters, different step sizes, pin point etc etc etc … so I would welcome enhancements in the focus department.
I for one and I know I’m not alone are looking into other softwares just because and solely because of the AF routine … It’s also the one reason I did not update, I would in an instant if progress was made on the AF routine …
I even looked at implementing sharp lock but that seems impossible for the setups in question …
I recall the last time that the SGP focus algorithms were tweaked (about 2 year’s ago?) the developers asked for focus packs, in which we share a set of images to test algorithms on. I think it is one of the options in the settings.
That might be a good place to start, especially for those who have setups that stubbornly refuse to cooperate. We are probably in 80/20 territory and the remaining 20 are going to have to provide more information, other than ‘it doesn’t work’, to the developers.
I could provide focus packs. I assume these would have to show stars at various levels of defocus, as you move through the curve? Should be pretty strait forward to generate something like that and upload it.
Jon - I will have to check when I get home but last time, Jared and Ken asked for packs with which to develop the HFD algorithms. I think there is an option in the focus settings that automatically save the images to their own directory.
Some sort of information is essential. If the developers don’t know what the problem is there’s nothing they can do. Just complaining that it doesn’t work won’t achieve much.
I think that people who don’t need this have a point of view. They are also entitled to support and there is a significant amount of work needed even to find out what the problem really is and to research solutions. You can’t expect Ken and Jared to drp everything to concentrate on this.
Exactly - what would be most useful are the cases where SGP algorithm fails but a different application succeeds. One of the outcomes may not necessarily be an application change, but revisions to best practices in regard to V-curve range, binning, exposure and so on.
Kudos to Jon for starting this thread. You have my vote for auto-focus being the most important area of SGP to improve upon. I have been using SGP for years. Really like it and I gladly upgraded to version 3 to show my support.
I have two setups that I use SGP and auto-focus on. For my FSQ-106 it works reasonably well. For my 200mm Canon lens with belt driven focus solution from Starlight Instruments it works better than I expected but still fails to give me a good focus occasionally. With the tight focus tolerance of the camera lens and backlash in the belt driven system, it would be a good use case for focus data. If the clouds ever clear here on the Texas Gulf coast, I will try to get some data.
Did I miss an update in regards to this? Seems like a lot of potential for autofocus to be much improved.
I don’t know how difficult it would be, but having SGP “learn” about things like focuser backlash and temperature compensation training via the logs could really put SGP a cut above the rest of some of the other automation tools out there.
I’ll hop back on here and bump this thread again as well, as this remains one of the more frustrating parts of using SGP. I just came from a thread where someone was asking for similar improvements and being told he must be doing things wrong. This thread was the first suggested thread after that, so at least the forum software recognizes there’s a problem!
It has indeed been months and no further feedback on this topic. Is it safe to assume that the AF functionality we have in SGP is simply what we have and we should not expect any improvements? Even with one of the most expensive focusers on the market, the NiteCrawler, on one of the better scopes on the market, the FSQ106, I have still had bouts of unreliable focus with SGP. Same exact kinds of problems I have had with other systems, so I am pretty sure the issue is not the hardware. The hardware is mind bogglingly precise and repeatable in my own manual testing. This is the one area where I think SGP’s lack of progress could push me onto other options in the not too distant future… :’(
Well lately AF become once again a big subject, a lot of recent topics related with AF are once again opening the discussion.
Jared told us that something is coming… what we are missing is a concrete timeline, this can happen in the next beta or in 5y from now which once again is kinda of a downer.
I personally love SGP. It has changed everything I do with my astrophotography. That said, I don’t think the software is profitable enough for the SGP developers to make a full time living adding new features. I’m amazed at how much they do responding to issues raised by users.
I see this software as more of a “community” venture than a “commercial” venture.
I wish there was a way we could funnel money to the developers to help them respond to requests for new features. I guess I’m thinking of a “GoFundMe” approach. For example, I would donate $25 in a minute to have the developers work on the autofocus issue.
I’m not sure what a reasonable rate for highly experienced and skilled developers would be in the US but $25 per hour seems low to me.
Also money may not be the issue, If you are holding down a full time job then your spare time may be priceless to you. I don’t know if this applis to Ken and Jared, they may be freelance and see this as part of their normal work but even then they would need to see this in commercial terms and get a reasonable return for the time this takes.
I am a retired professional software developer with a lot of experience in this sort of development and my rule of thumb for estimating is that you always underestimate the size of this sort of problem and the less you know about it the more you underestimate it.
My opinion is that a robust fix to focusing would take of the order of months of work to get a fully developed, tested and released solution. It would probably take two to three weeks just to get an idea of the scale of the problem.
$25 an hour for 40 hours a week is $1000 a week, $4000 a month.
What I’m saying is that you are asking a lot from people who are probaby doing this more as a labour of love even if you are paying a nominal amount, and demanding hard time scales is asking a lot.
