Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SkyTools 4 Imaging and SGP
#1
Many people naturally want to know what niche ST4 fills. Where does it fit into the imaging workflow, and what software does it replace?

The answer is that ST4 creates a whole new niche - one that adds value to your existing imaging workflow. It isn't meant to replace your existing software. It doesn't control your camera, focuser, dome, or rotater. You already have software to do that.

Think about the part that you play in the workflow. Your function is to select appropriate imaging targets, decide when to observe them (or at least define the parameters that will determine when), and to set up efficient observing sequences. Without your making good decisions, all that expensive equipment is wasted. So you can think of ST4 as your own expert aide. It's not there to rotate your camera or do the focusing. It's there to help you find suitable targets and to maximize the SNR on your images.

In practice, the question of what ST4's exact function is in your imaging workflow is ultimately determined by what equipment you use and how you go about using it.

If you use ACP or ACP Expert then this is pretty obvious. SkyTools generates ACP plans for use with ACP, and it intelligently submits projects to Scheduler.

But what if you are using a camera on a tripod? It isn't necessary for ST4 to interface directly with the camera. The SkyTools Scheduler simply tells you when to image your targets and what exposures to use.

What if you use the very popular SGP? Where's my ST4 integration with SGP, you say? While I can see just how cool integrating with SGP would be, it isn't necessary in order for ST4 to fulfill its primary function.

When you use SGP, you decide what to image, when to image, etc. So let ST4 help you make those decisions. Then go ahead and use SGP the same way you already do. Let ST4 be the brains behind SGP. To do that, use the SkyTools Scheduler. Once a Schedule is built, program the sequences into SGP. All you need to do then is to start imaging near the right time. If you think you can set up an entire night, go ahead. Or it may work best to work in shorter periods. You can set up a schedule to start and/or end at specific times of the night via the time sliders (aka From... To) on the Scheduler. Just clear the schedule, set the start time, and schedule away.

That said, I am sure there are things that I can quickly implement that will make it easier for you to use ST4 with SGP. Please tell me what those things are and I will do my best to implement them ASAP. If you find yourself asking, "how do I?" Ask me. If you find yourself thinking, "I wish ST4 would..." Let me know what you were thinking and why.

None of this means that I don't fully intend to integrate ST4 with SGP as fully as possible in the near future. That will be one of my primary tasks in the coming months. But before I can make a plan, I will need to investigate SGP and see how much the SGP developers are willing to work with me.

SkyTools Imaging may say version "4" but in many ways this is just the start. It is not yet at its full feature set. From here on out, I will be updating ST4 much more regularly, so you can expect to see things like SGP integration in the near future.
Clear skies,
Greg

SkyTools Developer
Reply
#2
This is my first post here.

I just started to get back into this hobby after a 25+ year gap. I have a C8 from 1986 and I bought my first goto mount a few months ago and am in the process of getting it all setup for imaging. I have just installed the trial version of Sequence Generator Pro and am in the process of finding the right planning tool to feed targets to SGP.  SGP can import targets from a few planners, but not SkyTools. I was looking at using Deep-Sky Planner 7 to do the planning and then import the target list into SGP. That sounds like it will work for me. But, then I saw SkyTools and though it would allow the same workflow as Deep-Sky Planner to SGP, but with better planning tools. But, it doesn't.

So, since you asked for ideas on integrating with SGP. This is what I would like:

1) At a minimum, export a target list that can be imported into SGP. Even if you just emulate the simple format of Deep-Sky Planner. Which is "Target name"<tab>decimal RA<tab>decimal DEC<tab>"J2000"<CR><LF>
2) Even better, export a complete imaging event sequence for each target for import into SGP. Probably would require SGP to add SkyTools to their import list.

I was surprised that no one has asked this yet, so maybe this is a dumb request. But, based on my limited knowledge and experience, it would seem like SkyTools should be able to feed the complete imaging plan to SGP for execution.

Regards,
Greg Jones
Reply
#3
As Greg wisely requests, export of a target list should be the minimum feature set.
Would probably upgrade to v4 for that alone.
I have the Deep-Sky Planner, but prefer to work with ST due to some UI-design I find tedious in DSP. (the rest are give and take, ST better overall for an astronomer, DSP better atlas with link to TheSky)
The SGP import menu choice for DSP-files should ideally read "OpenAstronomyLog", but I think they labeled it "Deep-Sky Planner" to avoid any confusion as to how much of the data (i.e. only targets) that SGP would make use of.

To meet this consensus of a minimum (we are two, yes Wink), ST could export to OAL (the only EVER sincere standards-initiative for a target/observation exchange format), and maybe ask the SGP guys to change the (DSP) import menu label to OAL/OpenAstronomyLog later on. Would be MUCH more comfortable with an OAL XML-schema approach, than yet another "CSV-implementation".

Not a lot has happened with astro-planners generally in the latest years, despite declared intentions. So I think that ST should have this simple target list export to SGP implemented quite soon, instead of waiting years to maybe have a full imaging plan transfer.
In the meantime I'm using ST3 now and then for general planning, which is quite good. But it's an island in terms of data exchange (except maybe for ACP, which I will gladly pay for if they will work with SGP), so I have sadly been forced to rely on other services to store my observation data.
(btw, I've been using Skysafari's livesky.com a little lately, and if they could complete their currently limited OAL-support, this might become a growing observation exchange hub due to they comparably huge user base)

Good luck exchanging!
Reply
#4
(2018-10-16, 11:32 AM)OlavN Wrote: As Greg wisely requests, export of a target list should be the minimum feature set.
Would probably upgrade to v4 for that alone.
I have the Deep-Sky Planner, but prefer to work with ST due to some UI-design I find tedious in DSP. (the rest are give and take, ST better overall for an astronomer, DSP better atlas with link to TheSky)
The SGP import menu choice for DSP-files should ideally read "OpenAstronomyLog", but I think they labeled it "Deep-Sky Planner" to avoid any confusion as to how much of the data (i.e. only targets) that SGP would make use of.

To meet this consensus of a minimum (we are two, yes Wink), ST could export to OAL (the only EVER sincere standards-initiative for a target/observation exchange format), and maybe ask the SGP guys to change the (DSP) import menu label to OAL/OpenAstronomyLog later on. Would be MUCH more comfortable with an OAL XML-schema approach, than yet another "CSV-implementation".

Not a lot has happened with astro-planners generally in the latest years, despite declared intentions. So I think that ST should have this simple target list export to SGP implemented quite soon, instead of waiting years to maybe have a full imaging plan transfer.
In the meantime I'm using ST3 now and then for general planning, which is quite good. But it's an island in terms of data exchange (except maybe for ACP, which I will gladly pay for if they will work with SGP), so I have sadly been forced to rely on other services to store my observation data.
(btw, I've been using Skysafari's livesky.com a little lately, and if they could complete their currently limited OAL-support, this might become a growing observation exchange hub due to they comparably huge user base)

Good luck exchanging!

I have to admit this  just fries me. Given that SkyTools 4 Imaging is new and few people have had experience with it yet, I find the comments above to be very disturbing and misleading. It does no good to compare a Tesla model S to a mini Cooper. I don't really care how much you like your mini Cooper or even if it has the right kind of charging cable for your phone.

This is a SkyTools 4 Imaging forum. Please be familiar with SkyTools Imaging in detail before posting. I did not spend four years developing an entirely new kind of software, much more powerful than anything that came before, to have it openly compared to such lesser products as if there is very little difference! Please refrain from posting comparisons to other products until have actually used mine. Maybe ACP? What are you even talking about?

As for data sharing, whatever that is, SkyTools offers everything you should ever need. I see no reason to export your logs into a format that loses much of the contextual data, and quite possibly ends up pointing to the wrong target object in the process.
Clear skies,
Greg

SkyTools Developer
Reply
#5
You know, I bought a product the other day. After reading the reviews I almost didn't buy it. But after much consideration and some trepidation, I went ahead and bought it anyhow, and I am so glad that I did. That product is awesome! But the reviews were very misleading. They fixated on little things that did not really matter in the big picture, and repeated misconceptions so many times that I almost believed that they were true.

When a small company develops an innovative new product, the hardest thing is is to get the word out about it. It gets marginalized. People who are unfamiliar with the product make assumptions, and say things that are misleading. Sometimes people own the product but spend very little time with it, or use such a small portion of the feature set that they never really get what the product is all about. They too say things that are misleading. It often seems that there is a strong wind of misleading words that are difficult to shout the truth over. This is one of the reasons I don't generally post on Cloudynights when people discuss my software. I would spend hours trying to set people straight when they say some stupid thing. The worst part is that eventually the misleading and over simple ideas start to appear on the web sites of competing, but much lesser products. I have seen this again and again. When I create something totally new, I often need to invent a word or terminology for it. Eventually I find that word being thrown around for other products in a way that intentionally confuses the meaning, even appearing as if it is a feature of another product when it is not, at least not as I invented it to be. It makes me angry, but there is nothing I can do about it on other forums. Here is another matter. This is why the terms of service for my forums forbid general discussion of competing products unless the discussion is specifically related to how these products are used together with SkyTools.
Clear skies,
Greg

SkyTools Developer
Reply
#6
The idea of using an open standard, xml based, file format for sharing target lists, and ultimately complete imaging plans, is exactly what I would like. It looks like OAL is mainly for sharing observation logs. But, it does has a schema defined for targets and their coordinates.

So, phase one could be to just use OAL's current schema for targets and their coordinates to implement a simple open interchange format for target lists.

Other phases could then build on that to implement the schema needed to support a complete imaging plan.


But, in the meantime, is there currently a way to use SkyTool 4 Imaging to create an imaging plan and get that target list, with J2000 coords,  into Sequence Generator Pro without just manually using copy/paste?

Regards,
Greg Jones
Reply
#7
(2018-10-16, 03:43 PM)gregwjones Wrote: The idea of using an open standard, xml based, file format for sharing target lists, and ultimately complete imaging plans, is exactly what I would like. It looks like OAL is mainly for sharing observation logs. But, it does has a schema defined for targets and their coordinates.

So, phase one could be to just use OAL's current schema for targets and their coordinates to implement a simple open interchange format for target lists.

Other phases could then build on that to implement the schema needed to support a complete imaging plan.


But, in the meantime, is there currently a way to use SkyTool 4 Imaging to create an imaging plan and get that target list, with J2000 coords,  into Sequence Generator Pro without just manually using copy/paste?

Regards,
Greg Jones

Not at the moment, no. I'm not a big fan of half-ass measures. Patience.
Clear skies,
Greg

SkyTools Developer
Reply
#8
(2018-10-16, 03:03 PM)theskyhound Wrote:
(2018-10-16, 11:32 AM)OlavN Wrote: As Greg wisely requests, export of a target list should be the minimum feature set.
Would probably upgrade to v4 for that alone.
I have the Deep-Sky Planner, but prefer to work with ST due to some UI-design I find tedious in DSP. (the rest are give and take, ST better overall for an astronomer, DSP better atlas with link to TheSky)
The SGP import menu choice for DSP-files should ideally read "OpenAstronomyLog", but I think they labeled it "Deep-Sky Planner" to avoid any confusion as to how much of the data (i.e. only targets) that SGP would make use of.

To meet this consensus of a minimum (we are two, yes Wink), ST could export to OAL (the only EVER sincere standards-initiative for a target/observation exchange format), and maybe ask the SGP guys to change the (DSP) import menu label to OAL/OpenAstronomyLog later on. Would be MUCH more comfortable with an OAL XML-schema approach, than yet another "CSV-implementation".

Not a lot has happened with astro-planners generally in the latest years, despite declared intentions. So I think that ST should have this simple target list export to SGP implemented quite soon, instead of waiting years to maybe have a full imaging plan transfer.
In the meantime I'm using ST3 now and then for general planning, which is quite good. But it's an island in terms of data exchange (except maybe for ACP, which I will gladly pay for if they will work with SGP), so I have sadly been forced to rely on other services to store my observation data.
(btw, I've been using Skysafari's livesky.com a little lately, and if they could complete their currently limited OAL-support, this might become a growing observation exchange hub due to they comparably huge user base)

Good luck exchanging!

I have to admit this  just fries me. Given that SkyTools 4 Imaging is new and few people have had experience with it yet, I find the comments above to be very disturbing and misleading. It does no good to compare a Tesla model S to a mini Cooper. I don't really care how much you like your mini Cooper or even if it has the right kind of charging cable for your phone.

This is a SkyTools 4 Imaging forum. Please be familiar with SkyTools Imaging in detail before posting. I did not spend four years developing an entirely new kind of software, much more powerful than anything that came before, to have it openly compared to such lesser products as if there is very little difference! Please refrain from posting comparisons to other products until have actually used mine. Maybe ACP? What are you even talking about?

As for data sharing, whatever that is, SkyTools offers everything you should ever need. I see no reason to export your logs into a format that loses much of the contextual data, and quite possibly ends up pointing to the wrong target object in the process.

I am sorry if my response seems overly harsh. I had not yet had my coffee when I responded, which always adds an edge to things. I also worry that I was not very clear. What I am trying to say is that there is something very special about SkyTools Imaging, and it has nothing at all to do with connectivity. Nevertheless, I spent months connecting to ACP, programming and communicating with ACP Scheduler, and coming up with a way to translate the power of the SkyTools Scheduler to those who have simple connections to their telescopes. As I have said repeatedly, SGP is next up. I concluded that it was best to release the extensive capabilities that it already has rather than delay another year. I say another year, because there are many other things I want to work on too. I do not expect SGP to be that difficult, based on what I have read. But I am in the middle of other important things. It will have to wait its turn.

But what concerns me most is the the implied idea that ST4 Imaging is only about connecting to control systems like other software... SkyTools Imaging is so much more than that. I do not wish the important things to be lost in the minutiae. Not now, when people are still wondering what SkyTools 4 Imaging is all about.
Clear skies,
Greg

SkyTools Developer
Reply
#9
for theskyhound
(2018-10-16, 03:43 PM)gregwjones Wrote: The idea of using an open standard, xml based, file format for sharing target lists, and ultimately complete imaging plans, is exactly what I would like. It looks like OAL is mainly for sharing observation logs. But, it does has a schema defined for targets and their coordinates.

So, phase one could be to just use OAL's current schema for targets and their coordinates to implement a simple open interchange format for target lists.

Other phases could then build on that to implement the schema needed to support a complete imaging plan.


But, in the meantime, is there currently a way to use SkyTool 4 Imaging to create an imaging plan and get that target list, with J2000 coords,  into Sequence Generator Pro without just manually using copy/paste?

Regards,
Greg Jones

Not at the moment, no. I'm not a big fan of half-ass measures. Patience.

I went back up and read my original post on this thread, which I wrote some time ago. I see that I was not very clear when I asked for suggestions. What I meant was for people who program SGP by hand to make suggestions for small general ST4 features that would help them use ST4 with SGP until full integration comes along. I like to focus on one thing at a time when I work, and when I do SGP integration it won't be piecemeal. When its turn comes I want to be thorough. This is why I'm not keen on simply transferring positions, because that means tuirning my attention away from what I am working on now to look at SGP. It is for the best that I do SGP all at once.
Clear skies,
Greg

SkyTools Developer
Reply
#10
Hey Greg!  Well, as someone who *HAS* been using ST4 quite extensively over the last few weeks, building profiles and such and then (laboriously) building SGP profiles that are then used, here's a few notes that I've made for my workflow into SGP that might be helpful .. realize that there are several preconditions for me that likely won't be true for the other 99% of the users out there ...

- The "imaging project" in ST4 seems to be oriented toward "get it done tonight" ... as would be the case with an iTelescope user, who has a limited amount of time and wants to see some results for credits spent.  That's different than me, who is the "get a little bit done night after night, week after week and *then* get some results" ... as you know, I take the results of a nightly stack and *then* build a super-stack of those after a few months or so
- Because I'm building a super-stack, I'm all about consistency from night to night ... that's why I use "locations" to segregate by SQM values and seeing FWHM values
- To combat mirror flop, I don't transit the meridian in a session so I've got two more "location" segregations by pier side
- ST4 also combines imaging projects with imaging devices, which is good and bad ... it's good that it allows me to further segregate OTA's, but bad in that I've got six different imaging configurations I use based on what I'm shooting, so each imaging project gets duplicated at least 2x for each object
- In experimenting with building my super-stacks from nightly sessions I've developed a "minimum SNR" for each type of object that will give me "something" after 50+ stacks; for galaxies with "arms" detail that SNR is 11, for planetary nebulae with "faint" detail that is 8 and for larger nebulae with "faint" detail that is 6 ... so my "imaging projects" have each been set up for "single night", "IQ B or better" and "SNR to shoot for" at 11/8/6 depending on the object, then at 15, 20, 25, 30, 60, 80, 100 and 120 to correspond to those SNR's for the evening.  I've also set the "maximum subexposure time" to 10min, as I don't see a large increase in dynamic range if I go beyond that but I *do* find I'm more susceptible to differential flexure, meteor trails, airplanes, etc. ... and ST4 very nicely recalculates the total integration time as needed
- To allow me to take multiple exposures of a single object in a single evening, I need to again duplicate the imaging projects into multiple copies of the various SNR values; 3 for the 60+ ones, 5 for the 20-30 ones and 8 of the ones below 15 [thank you SO much for the "duplicate" button!]

My next step is to add in some workflow time to the project: when I image an object the sequence is (slew to focus object near primary object) (focus) (platesolve/ slew to primary object) (expose) then (for each 45min exposure time during a single sequence (slew to focus object near primary object) (focus) (platesolve/ slew to primary object) (expose)) until that object is done.  ST4 doesn't  have a good way to let me program in those inter-exposure slews and platesolves, so I manually calculate thattime and add that to the per image read time value. 

So, say I've got 3 objects that are candidates for the evening with a particular imaging stack ... that's a total of 9 imaging projects per object by SNR and then the SNR duplicate for about 60 project candidates for the evening (it's usually 8-12 objects, but I'm simplifying the example).  I select the appropriate "location" based on expected SQM and viewing and pier orientation, press "autoschedule" and let ST4 do it's calculations.  One *VERY* nice thing about ST4 is that it will optimize the "best first" by SNR which means it will figure out how to squeeze in an 'A' at SNR 60, another 'A' at SNR 60, then a 'B' at SNR 30, then two 'C' at SNR 20, then four more A at SNR 10 ... that gives me a baseline ordering of objects, I will then use the priority selection on the scheduler if I want a certain number of a certain SNR's but generally ST4 is pretty good about optimizing my time ...

So, ST4 has done it's stuff and generated a list of raw start/ stop times and slew locations for me as it skips across the sky ... for each object I then plug in a start number and location into SGP, manually put in my slew/ focus/ platesolve/ expose steps, also manually put in my slew/ focus/ platesolve/ expose every 45min of a sequence step and move on to the next object.  I repeat this for each pier side "location" and then have an SGP "project" to run that evening ...

Although this sounds laborious and complex, it allows me to satisfy my preconditions quite nicely and lets me take advantage of the biggest strength of ST4 for me, the ability to calculate subexposure times based on conditions and then to optimize by night imaging to get the most number of daily lights possible ...

Hope this helps, good stuff!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)