SGPro 3.1 and Early 4.0 News

We should make these posts more often… Maybe I should retire soon and do this. Here are some things going on with:

SGPro 3.1 Release

This has been a long beta, but has some significant internal changes… In addition to what is there now, we will address the following before formal release:

  • Auto Focus improvement. Re-run based on bad fit or validation frame error (for a user defined number of times and then return to starting position).
  • PlateSolve2 search regions bug (Number of Search Regions Bug)
  • Add ability to filter which notifications pop up (Before moving Beta to official release)
  • Remove the profile name in the sequencer window… This serves to promote a conceptual error wrt how profiles apply to sequences. Once the profile is applied, it is no longer relevant to a sequence… this makes it seem like it is (rather than just being historical information).
  • Possible bug with exposure time formatting… needs to investigation ([BUG] Event duration)
  • Turn API guider logging off (My logfile growing huge)
  • Investigate and address issue where profiles are not updated with Flats Cal Wizard data (Flat calibration wizard - crashes (beta
  • Replace existing settings system… as of late, it seems to be creating a lot of situations where SGPro is refusing to start

SGPro 4.0 Thoughts

It is very early in this thought process and none of these things are written in stone (some are pretty complete though). Current thoughts on new features for 4.X

  • Formal support for switches. Manually adjust switches in SGPro and automate their state at sequence start and end (Includes support for ASCOM switches and PrimaLuce Eagle… Maybe Pegasus Astro… except for special cases, we’d like to promote ASCOM Switch implementation)
  • More Auto Focus improvements with emphasis on long FL rigs, star poor regions and clustered stars
  • Multi-camera rig support for coordinated dithering
  • Sequence visualizer (see a graphical representation of how SGPro will capture data… updates in real time as you adjust your sequence’s events)
  • Possible support for flat boxes that are implemented with ASCOM’s Switch interface.
  • Better support for extremely large sequences (better memory management for SGPro targets)
  • Possible cloud support for private, synchronized storage of sequences and profiles
  • Possible cloud support for public sequences (with built in rating system)

Thanks Ken for this update.

I can now see why you have been converting sequences to json… but is this the right path ? Who from your user base asked for cloud storage of sequences ?.. the practical use of this for an astrophotographer is next to none.

A missing point is the API improvement, would this be something that wI’ll fit in 4.x ?

That is just not true… You are projecting your use cases onto everyone else.

1.) Many SGPro users use multiple machines to create and execute sequences (all of them with internet access)
2.) Many users would benefit from target sequences made by more experienced astrophotographers. It is a great learning tool and allows for community contribution

Those features have little bearing on our decision to do this…

Unknown… not a lot of clamor for this.


On the forums I didn’t see a anyone asking for it so either I missed a lot or isn’t just me projecting my use cases into others.

I really find it with low practical use… because we are dealing with stuff which is not binary, take a quick example, even if both of us have the exact same equipment, the sky from were we image could be really different which means gain/offset ratios will not be the same… so your sequence which works perfectly in your region will not yield the same results for me.

Great work guys! I look forward to the ever enhanced versions appearing.

I hope that you will be fixing the weird behaviour when trying to abort a sequence that is waiting for Safe to restart, as reported in my posts recently. I’m hoping that this will be in the next Beta release, which I am hoping is imminent!

One further feature request for v4.0 - as a UK based imager, some kind of cloud reduction tool would be most helpful…:grin:

I don’t necessarily agree with your feedback here, but it’s all fair. Sequence capture for targets with similar gear (a lot of it is similar) do not vary as wildly as you are suggesting… Anyhow, no need to continue with this discussion… I take your point. Either way… sequence sharing is not a priority… the primary purpose is sequence and profile sync.

This sounds familiar… like I have fixed this? Sorry, my brain is cloudy. Did we report this as fixed in the 3.1 beta?

Ken, I’ve been in discussion with Jared over this one and await a release with a fix. It is more than possible that you have fixed it very recently, but I don’t have a beta release to test it yet…

Thanks for the updates, Ken! Am particularly looking forward to switch and cloud support in 4.0

Clamor clamor!

Expanding the API would be a huge win for me.

It’s probably my most desired improvement to the package, and if I’m being honest, feels the most “unfinished” as things sit right now.

It seems unfinished because we have never intended on extending it to our users. What exists now has always been for partner integrations (using gear that SGPro owns). Im not implying that our thoughts never change, but it has always been our philosophy, for the niche we were trying to fill, that, if an API is a very requested feature, we have failed to provide some sort of automation within the application itself. These days… since we have less time to work on SGPro (in general), it is certainly possible that we may shift our stance here… Just a little information on why the API seems half baked.

Actually, I passively use google drive at the moment to cloud sync all my data. I run from a remote obsy and any sort of cloud integration, I will be excited for! Awesome news!

Also, clamouring for API enhancements…


And that seems perfectly fair. And I see the wisdom of your point…if there’s lots of API need, then should the software be doing something better?

Your answer suggests (at least as I read it…I could well be wrong) that the API is generally thought of as a way to expose some sort of functionality.

Perhaps there’s another “point of view”? In that the API exposes information about what’s happening. Just as one example, I have a “status page” for my observatory…it tells me weather info, power usages, and so on…and it also offers information from SGP’s API on what gear is connected, what it’s doing, and so on.

I feel like making that aspect of things more robust and complete could present a ton of opportunities to others for things like customizing alerting to their own needs, “quick glance” looks at what’s happening, real time log viewers (or loggers even!) and so on.

Again…I see where you’re coming from, and I respect your desire to provide desired functionality through the application. I would just welcome being able to ET&L complete obs/session info for my own responses/visualizations. :slight_smile:

I see an API as a way for sophisticated expert users to obtain specialist functionality for their specific situation. Many of the requests seem to me to come into that category.

Using an API for that sort of thing will reduce complexity because most people won’t need it and even those that do will not need such an extensive UI.

We used to put quite a lot of hooks into automation applications for this reason, we couldn’t forsee every way the product would be used or what the hardware might require.


Dual scope and camera is a big ask from many folks, myself included. Clear sky time is valuable and many astrophotographers have two scope/camera setups on the same mount to double their data capture.

1 Like

Is the posibility to change the phd2 connection port implemented in this release?
Because I have 2 setups, I wanna use 2 instances of sgp, each one with its own instance of phd2, like in APT and NINA.

1 Like

Ken, could you expand a bit on the point below please?

Better support for extremely large sequences (better memory management for SGPro targets)

At the moment, I think the largest Fov allowable in the FMW is only about 20 degrees. I’ve long been wanting an automated solution for doing very large mosaics, e.g 50 panels with a 135mm lens. At the moment, AFAIK, there is no software package out there that can do this.

Is this the kind of thing you are talking about above? If so, then I would upgrade to v4 tomorrow :grinning:

1 Like

Thanks for the update, Ken. It all looks like good stuff, but I have to say that I’m a bit disappointed that there won’t be anything else regarding improving autofocus in the foreseeable future. The re-run feature will be useful, but for those cases where autofocus simply does not work well, re-running the routine won’t help much. I got the impression from the numerous threads requesting improvements to AF such as outlier rejection and ROI selection that these were actively being investigated. From what I have read on the other forums, this is the primary reason people are choosing other software over SGP.


1 Like

SGP 4.0 listed numerous AF improvements

D’oh! Sorry. Missed that.


Wow, I am so looking forward to the AF improvements in Ver 3.1 and 4.0 as well as the multicamera support. Very exciting. I am tired of all the basing SGP gets in CN and everyone saying to try NINA or Voyager. I just dont see it. These updates will kill a lot of noise out there.

Do you have any tentative release data for V3.1?

1 Like