Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SkyTools 4 Imaging and SGP
#11
(2018-10-16, 03:41 PM)theskyhound Wrote: .. 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.
Sorry for upsetting you. This is me, not native English, writing a note quickly. Honestly thought I was helping.
Didn't realize I was violating your forum rules. Have been using ST3 since two years. Thought it was relevant to explain my choice despite the other product's data exchange.

My comment about ACP was unclear. My new observatory is indeed a candidate for ACP. But again, I have waited to see if they would consider SGP support after all. Thought ST>ACP>SGP might be kind of a workaround.

Thank you for explaining, you made your plans very clear.

(2018-10-16, 03:43 PM)gregwjones Wrote: .. It looks like OAL is mainly for sharing observation logs. But, it does has a schema defined for targets and their coordinates.
You are right. And in case someone did not know, most of the OAL schema attributes are of type not required.
In couple of hours I made a repository with API and a simple web front, by importing the OAL schema and have generated the object model into a plain development solution. Just for private use. During the year I have added import and export of observation/target lists, as I was too often stuck with proprietary exchange formats. Point being, without much programming at all you can mimic a target list format accepted by SGP, while having cloud backup of your observations and imaging plans.
It's convenient to have vendors declare support for some specified data exchange, but life goes on without.

Best,
Olav Norrud
Reply
#12
(2018-10-16, 08:43 PM)choward94002 Wrote: 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!

Hi,

We have already discussed these things at length. Your way of imaging is very "specialized." I have never known anyone to go to the lengths that you do in order to make consistent stacks. To be honest, I am skeptical that it is all worth the trouble, but I am fascinated to hear how you work, and it provides a lot of food for thought regarding improvements to ST4 and my own imaging in the future. I don't see it as a shortcoming of SkyTools if it doesn't directly support your extreme style of imaging. I am simply happy that you can do what you want to do with ST4 at all, because you are way outside of its design goals.

You also said that, "The imaging project in ST4 seems to be oriented toward 'get it done tonight'" and suggested that there was a bias toward iTelescope. I have to take exception to both of these statements. As I have said before, this is absolutely not true. After all, there is no date attached to an imaging project, and one of the functions of a project is to keep track of your observations from night to night, naturally accumulating SNR from multiple sessions on different nights. You choose not to use it that way, but that doesn't mean it has a different intention.

The actual idea is to get it done on the most appropriate nights only (get something else when it isn't appropriate) and to get it done only during the most appropriate time of that night (get something else when it isn't appropriate). That is in fact what it is all about.

This thread is supposed to be about SGP, so we are way off topic. But if you want to continue our discussion elsewhere I would like to hear more about your process. At first glance what you are doing doesn't really seem justified based on my knowledge of how cameras, stacking and sky meters work. You don't appear to be taking into account the diminishing returns of stacking, I question whether stacking single nights and then stacking each nightly stack actually provides benefit, and your use of SQM values as if they are tied directly to the quality of the night seems suspect. But those are mere suspicions. I am not the one working with your telescopes and looking at the results. I also suspect that the difference may be in the details, many of which I am not fully aware of.

Thanks,
Greg
Clear skies,
Greg

SkyTools Developer
Reply
#13
(2018-10-16, 11:28 PM)theskyhound Wrote:
(2018-10-16, 08:43 PM)choward94002 Wrote: 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 ...

< wall of text >

Hope this helps, good stuff!

Hi,

We have already discussed these things at length. Your way of imaging is very "specialized." I have never known anyone to go to the lengths that you do in order to make consistent stacks. To be honest, I am skeptical that it is all worth the trouble, but I am fascinated to hear how you work, and it provides a lot of food for thought regarding improvements to ST4 and my own imaging in the future. I don't see it as a shortcoming of SkyTools if it doesn't directly support your extreme style of imaging. I am simply happy that you can do what you want to do with ST4 at all, because you are way outside of its design goals.

Yep, I'm drawing WAY outside of the lines and if I can inspire just a single thought about how to improve ST4 then it's worth typing my "wall of text" ... like I've said, ST4 has increased my productivity by at least 40% night over night and I'm telling everyone who will listen to try out ST4 for planning ... I may be using ST4 in ways you never considered, but it's a testament to the product that I *can* use it in ways you never considered, not a shortcoming!  

You also said that, "The imaging project in ST4 seems to be oriented toward 'get it done tonight'" and suggested that there was a bias toward iTelescope. I have to take exception to both of these statements. As I have said before, this is absolutely not true. After all, there is no date attached to an imaging project, and one of the functions of a project is to keep track of your observations from night to night, naturally accumulating SNR from multiple sessions on different nights. You choose not to use it that way, but that doesn't mean it has a different intention.

Fair enough, points well taken!

This thread is supposed to be about SGP, so we are way off topic.

It looked like you wanted to know how I used it with SGP ... so I told you about needing to put in delays for focusing, slewing, plate solving and the 45min refocus step (which would be nice if they were in ST4 ...) ...

But if you want to continue our discussion elsewhere I would like to hear more about your process. At first glance what you are doing doesn't really seem justified based on my knowledge of how cameras, stacking and sky meters work.  You don't appear to be taking into account the  diminishing returns of stacking, I question whether stacking single nights and then stacking each nightly stack actually provides benefit, and your use of SQM values as if they are tied directly to the quality of the night seems suspect. But those are mere suspicions. I am not the one working with your telescopes and looking at the results.  I also suspect that the difference may be in the details, many of which I am not fully aware of.

There's no question that you've thrown away more pictures in one month than I've produced in a year; I've seen your web pages, looked at your galleries, read of your adventures ... so there's no question that you've forgotten more about imaging than I've learned to this point and you might be quite right, all of my rigamorole might be pointless or there might be better ways to get to where I want to be.  I'd be glad to answer any questions you might have (I think over the last few weeks worth of walls of text I've pretty well described my workflow, I guess I could go into the flats routine or how I build my dark libraries but those seem far afield from ST4 stuff) ...

You're correct that stacking has a diminishing returns at some point (and there are endless threads/ articles/ books on that), my empirical evidence shows me that there *is* a threshold, but not what that is and the more lights I accumulate over time the easier it is to determine that number.  One thing that I *have* noticed though is "garbage in, garbage out" and that I always get better results with stack elements with as little pattern noise and gradient variation between the lights before I image as possible ... it's no different than someone going through the night results tossing out the fuzzy/ blurry/ hazy lights so they are all more consistently "good", or using the ImageQuality setting in ST4 to only image when it's "A", I'm just "stacking the deck" to eliminate those fuzzy/ blurry/ hazy lights using specific SQM and seeing values before I start my imaging.  Again, it's thanks to the ability of ST4 to so nicely compute daily exposure times and to optimize my viewing schedule that I *can* more easily do that ...

As time goes on and I get more competent I'll likely change some of my routine (for instance, right now I'm experimenting with LRGB rather than RGB but using a green channel as the L) and as software gets better change that as well (I'm experimenting with the stacking of APP, and always learning the inscrutable PixInsight ways!), just like I dramatically changed my routine when ST4 came out with it's SNR targeting and session optimization capabilities ...

Looking forward to the next update and to what is coming next!
Reply
#14
Hi,

One thing, you said: "You're correct that stacking has a diminishing returns at some point (and there are endless threads/ articles/ books on that), my empirical evidence shows me that there *is* a threshold, but not what that is."

SkyTools Imaging calculates this directly. So there is no reason to guess. I may not be perfect, and the results depend on what you tell it, but it should be pretty close to reality. The point of diminishing returns isn't something exact anyhow.
Clear skies,
Greg

SkyTools Developer
Reply
#15
(2018-10-17, 12:18 AM)theskyhound Wrote: Hi,

One thing, you said: "You're correct that stacking has a diminishing returns at some point (and there are endless threads/ articles/ books on that), my empirical evidence shows me that there *is* a threshold, but not what that is."

SkyTools Imaging calculates this directly. So there is no reason to guess. I may not be perfect, and the results depend on what you tell it, but it should be pretty close to reality. The point of diminishing returns isn't something exact anyhow.

Quite right, and the ability to set a target SNR that ST4 will stack to get to is one of it's benefits!  Now that I've done some SNR 10's and 20's and 30's and 60's and one 100 I have a better feeling for what I feel is "good enough" ... and ST4 has the ability to calculate what I need to do to hit that SNR with varying conditions, which is an invaluable ability for me!

I think there's still the sticking point of "why do I bother with daily stacks and then superstack to a specific SNR, why not just take the ST4 multinight exposure to get to that SNR and you're done" and the simple answer is that as the stacking software gets better, what might have taken X exposures of Y to get to that specific SNR a year ago now only requires a portion of that today.  There was a CN post recently that illustrated just that point [https://www.cloudynights.com/topic/63685...?p=8893284] ... the same data was used, but got dramatically different outcomes simply due to the stacking software being different.  

When ST4 comes up with a multinight estimate of X exposures for Y to get to SNR Z, it has no control over what stacking software I'm going to feed those X exposures into to get that SNR Z ... which can have a dramatic difference in the results.  Those 20 lights at 10min taken over three days that ST4 told me may look fine in DSS but will really pop in PI, or maybe not even really register in APP or Registax ... stacking software changes and what looked OK in 2018 may look terrible in 2020.  ST4 is *really* good at calculating the exposure time needed to hit a specific SNR for a specific night (maybe a bit too aggressive on the subexposure times, I cap that at 10min manually) but has no way of knowing how I'm going to be stacking those exposures to get to that target SNR Z.  The only real "constant" I can provide to the ever changing stacking software is the individual lights themselves that are registered, processed and stacked, and those come down to three basic quality variables: object signal dynamic range (which is affected by the exposure time), background pattern noise (which is affected by the sky brightness measured by SQM, my dark library, flats and dithering) and signal detail (which is affected by the seeing).  By making sure each individual light supplied to the stacking program has as much dynamic range as possible, as little background pattern noise as possible and as much signal detail as possible then as stacking software gets better and better at stacking you'll get the effect seen in the post, to say nothing of the effect of advances in postprocessing like drizzling, DBE and deconvolving ...

The ST4 exposure calculator is good, no question ... but it can't anticipate what PI or APP or DSS or XYZ will be able to do with the data ... maybe PI can hit that SNR 60 target in only 10 lights of 20min when ST4 had calculated 20 lights of 20min, and maybe in 2020 APP can hit that SNR 60 number in just 8 lights of 20min; we don't know.  What we DO know is "garbage in, garbage out" ... feeding the stacker the very best quality set of lights will result in the best results.  

In the "real world" I've already found that if I feed PI 60 lights each with an ST4 SNR of 8 then I will end up with a picture that StarBlinker finds indistinguishable from a single session ST4 SNR of 60 taken from 30 exposures of 10min ... but if I tell ST4 to give me a multinight result of 60 SNR and give it the nightly conditions that result in an SNR of 8 for that night (25 exp of 3min) ST4 tells me "signal not found" and the integration times don't match (30 x 10 == 300 versus 60 x 25 x 3 == 4500) because PI uses a different method to accomplish it's stacking that the ST4 algorithm works from.  Next year, maybe PI will only need 50 of those SNR 8 lights ... but again, by using ST4 to figure out how to get 60 lights of SNR 8 and then letting it schedule those in 5 today and 10 tomorrow and 8 the next day until I hit my magic 60 number I can then end up with that SNR 60 picture from PI that ST4 wouldn't let me gather with multi-night.

It's simply using software to it's best advantages and strengths; ST4 isn't a planetarium, it doesn't control mounts, it won't capture camera data, it won't stack lights, that's not what it's designed for ... it's made for calculating optimal exposure times and then optimizing image target sessions during an evening.  I don't expect ST4 to control my mount or talk to my camera, just as I don't expect it to stack my lights nor be able to predict how those stacks might turn out ... so like my CN tagline says I use Stellarium as my planetarium, ST4 as my planner, SGP as my controller and PixInsight as my processor and stacker ...

So, I have a range of nightly objects with different SNR targets ... ST4 very nicely tells me how many of what SNR for those objects it can take for that evening (maybe 2 SNR 30's of A, 3 SNR 10's of B, only 1 SNR 8 of C) and then very nicely arranges them so they all get taken in the best order possible (the high SNR's at IQ A times, the lower ones at IQ B times).  I continue to gather those various SNR lights night after night, like state quarters in my pocket, until one day I have 60 of those SNR 8 lights that I then feed into PI and *poof* out comes a nice SNR 60 picture.  A year later, a new version of APP, by now I have accumulated 70 of those SNR 8 lights and now APP 2.x gives me *poof* an SNR 80 picture ... you get the idea ... as long as my individual lights are as "clean" and "consistent" as possible to make them, I'll get wonderful superstacks back out ...

Clear skies!
Reply
#16
Hi,

We need to come back down to earth here. Stacking images isn't magic and it isn't some dark art that nobody understands. It is a relatively simple set of image processing algorithms. There is no realistic means to improve on it substantially. If you saw a report that new stacking software worked better than an old one, then there are only a few possible explanations for that:

1. The old software was not working properly

2. It was not being used properly

3. A different algorithm was used (e.g. a weighted average algorithm vs. median)

4. The person is simply confused or mistaken

SkyTools makes a simple assumption: that the stacking has been done properly. There really isn't anything more to it than that and despite all that is written and discussed, any differences in algorithms or implementations are in fact quite small, unless something is terribly wrong.
Clear skies,
Greg

SkyTools Developer
Reply
#17
(2018-10-18, 05:55 AM)theskyhound Wrote: Hi,

We need to come back down to earth here. Stacking images isn't magic and it isn't some dark art that nobody understands. It is a relatively simple set of image processing algorithms. There is no realistic means to improve on it substantially. If you saw a report that new stacking software worked better than an old one, then there are only a few possible explanations for that:

No worries!  As I said, ST4 is working great for what I need, I'm more than happy with it! 

You had asked why I was obsessed with matching SQM values and seeing across multiple nights ... I have explained the rationale behind it and how I used it with superstacks. 

You had asked why I don't do meridian flips ... I have explained the rationale behind that. 

You had asked why I accumulate lights of a specific SNR value over time and I explained how they are used for superstacks to build to a specific greater SNR versus using the ST4 multinight method to get to that SNR and I even provided an example of how by using a superstack of SNR 8 lights with PixInsight I was able to build an SNR 60 picture where ST4 simply told me that was not possible ("signal not detected") ... and I even provided a link demonstrating the value of taking advantage of advancing stacking technology to redo a superstack later and what a dramatic difference that can make. 

You asked the community how people were using ST4 in conjunction with SGP to accomplish their goals ... I detailed my own SGP workflow and goals, hopefully that gives you some ideas for how to integrate specific steps I do in SGP with ST4 image project settings

You also commented on why the poster to that link was getting much better results with a later version of the software with the same data, something which I have personally seen with my datasets time and again as I've used DSS, Registax, CCDStack, PixInsight and these days APP (and why I have learned to use specific stackers for specific objects and am always redoing my lights into new superstacks) ... you mentioned some reasons why that could be happening ...

1. The old software was not working properly

Absolutely, it's very possible that the implementer of the stacking software is/ was an idiot and doesn't/ didn't have a clue what they are/ were doing ..

2. It was not being used properly

Absolutely, it's very possible that the user of the software is/ was an idiot and doesn't/ didn't know what he's doing ...

3. A different algorithm was used (e.g. a weighted average algorithm vs. median)

Absolutely, it's very possible that as time goes on algorithms are always being discovered or refined ... for example, drizzling didn't exist 10 years ago (does now, makes a big difference), PixInsight's DBE didn't exist 5 years ago (also makes a big difference), deconvolution didn't exist a few years ago (makes a big difference), etc. etc.

4. The person is simply confused or mistaken

Absolutely, see point 2, the user could easily be an idiot then and is still an idiot now ...

SkyTools makes a simple assumption: that the stacking has been done properly. There really isn't anything more to it than that and despite all that is written and discussed, any differences in algorithms or implementations are in fact quite small, unless something is terribly wrong.

Here I make only the simple observation that if I take 60 lights built with an ST4 imaging project with an SNR goal of 8 using IQ B in SQM 19 seeing 2.0 skies, normal detail which have been dark/ light/ DBE processed that evening and sorted by SQM and seeing and *then* run those 60 sorted lights through PixInsight's stacker I will get a picture which is indistinguishable (using StarBlinker) to a picture taken in a single session with an ST4 SNR of 60 using IQ A, SQM 20.5, seeing 1.5 ... nice arm details, clear colors, sharp object stars, basically indistinguishable ... and that's the whole point of superstacking, using something someone has spent man-years perfecting to make magic happen ... 

If I create an ST4 multinight imaging project with a goal SNR of 60 using IQ B, normal detail, SQM 19, seeing 2.0 ST4 tells me simply "no detectable signal" and I can proceed no further. 

That tells me that there is something miraculous happening in the way that PixInsight does it's stacking that ST4 isn't aware of when ST4 decides that there's no 'friking way that you can take skies that have an SQM of 19, seeing 2.0 with IQ B conditions and get an SNR 60 image out of it ...


Again, ST4 is simply phenomenal at calculating my nightly exposure numbers, I've only needed to tweak the maximum exposure time but night after night with varying seeing, SQM's, airmass numbers, weather changes, etc. it can hit those target SNR numbers consistently.  It's more than helpful in optimizing my imaging order and is something I wax eloquently about ad nauseum to fellow imagers with ... every night I really *love* seeing what objects I'm going to be able to get, it's like a self-renewing winning lottery ticket!
Reply
#18
"That tells me that there is something miraculous happening in the way that PixInsight does it's stacking that ST4 isn't aware of when ST4 decides that there's no 'friking way that you can take skies that have an SQM of 19, seeing 2.0 with IQ B conditions and get an SNR 60 image out of it ..."

I am sorry, but that is not a valid conclusion. I don't know what to tell you. There is no such thing as magic. It is far more likely that you have misunderstood something in the way that SkyTools works, but I am not able to follow your descriptions well enough to see what it may be.

First you agree with me then disagree completely. I am not sure how to deal with that.

I do not wish people to think there is something wrong with SkyTools Imaging (it has been carefully and heavily tested). I do not want people to believe that that stacking is magic rather than science. I stand behind the model that SkyTools uses for stacking.
Clear skies,
Greg

SkyTools Developer
Reply
#19
A couple of last things because I really don't have time for these extended discussions and I am getting very frustrated.

1. I don't know what you mean by "normal detail." There is no detail selection in SkyTools. Detail means resolution. I suspect that you mean that your exposure goal of SNR = 60 is based on an exposure for the arms of the galaxy (which is not detail). If so, this is going to be a mean value for the arms, not for just the brighter parts. If you are going to measure the SNR it has to be done in the same way. It has to be consistent or it is a meaningless comparison. I have no idea how you are measuring the SNR, and for the arms of a galaxy this is something that is not all the straight forward to do.

2. You haven't mentioned the target object. I can think of at least one object that has unusually bright spiral arms. If it is such a galaxy, unless I have access to the brightness profile, then the brightness of the arms may be underestimated.

3. Garbage in = garbage out. There are many inputs that have to be set correctly. If they are not, then you will not get good results. My advice is that if you are not able to reproduce the results then please do not blame the software, do not try to explain it away as shortcoming of the software, and do not claim it is some magic image processing. Please instead look very carefully at your inputs, as this is much more likely to be the source of your problem.

4. Lastly I asked you to take this to an appropriate thread. This has nothing to do with SGP.

If you have specific questions I will be more than happy to answer them. Please create a new thread. Please also try to use SkyTools terminology as much as possible or I will have trouble understanding you., and please include as much information as possible. Otherwise all I can do is guess...
Clear skies,
Greg

SkyTools Developer
Reply
#20
(2018-10-18, 09:29 PM)theskyhound Wrote: A couple of last things because I really don't have time for these extended discussions and I am getting very frustrated.

Sorry about that, I'll do a quick reply and be quiet ...

1. I don't know what you mean by "normal detail." There is no detail selection in SkyTools. Detail means resolution. I suspect that you mean that your exposure goal of SNR = 60 is based on an exposure for the arms of the galaxy (which is not detail). If so, this is going to be a mean value for the arms, not for just the brighter parts. If you are going to measure the SNR it has to be done in the same way. It has to be consistent or it is a meaningless comparison. I have no idea how you are measuring the SNR, and for the arms of a galaxy this is something that is not all the straight forward to do.

2. You haven't mentioned the target object. I can think of at least one object that has unusually bright spiral arms. If it is such a galaxy, unless I have access to the brightness profile, then the brightness of the arms may be underestimated.

Targets done were the Helix nebula with detail at "main extent" and M33 at "arms" ... my criteria for "getting good detail" was if after postprocessing with PixInsight and superstacking daily lights I could see the central star in Helix and make out the blue supergiants in M33.  The SNR was given me by the ST4 exposure calculator, I set my target SNR and it told me what to do to get it both for the SNR 60 comparator and the SNR 8/10 daily lights ...

If you have specific questions I will be more than happy to answer them. Please create a new thread. Please also try to use SkyTools terminology as much as possible or I will have trouble understanding you., and please include as much information as possible. Otherwise all I can do is guess...

Yep, no questions, ST4 is doing quite nicely thanks!  Clear skies!
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)