(2018-09-26, 08:39 PM)theskyhound Wrote: Hi,

How on earth are you scheduling from the target list? Only projects can be scheduled. The Target Selection Tool is used to select targets, which become projects. It is projects that you are scheduling, so I don't see how the target list helps you schedule. I'm confused.

Ok, I see what you mean by detail, but that's not really what it is. This represents the signal that you are exposing for. It is what the SNR is computed for. Detail is about resolution.

(2018-09-27, 05:14 PM)theskyhound Wrote: Ok, thanks for the details. I appreciate your taking the time. I tried to read that before I'd had my coffee, btw. Bad idea! I still have some questions about the bigger picture in order to help me design a workable solution to the pier flip problem, to help you make the best use of the software, and to improve the software in the future. My first impression is that there are better ways to accomplish what you are trying to do by making better use of the Observing Programs feature. But I will save my recommendations until I fully understand.

And I appreciate your indulgence in this!  I'm really quite excited about the potential for this software and was chatting about it just this morning with a friend of mine, using the analogy of builders in the Medieval period ... they didn't have the benefit of FEA programs, they simply tried building things and if it fell down they tried something else, if it stayed up they said "cool, I'll do that next time!" and over generations they learned how to build some pretty amazing things!  Right now Astrophotography (for me, at least) is still in the Medieval period ... I try an exposure series, if it works I say "cool, I'll do that next time!" and if it doesn't I'll try something else; but I really don't have generations to get it dialed in!  ST4 appears to be the equivalent of FEA software for astrophotographers ... this appears to be able to give me a calculated answer to the question "how many for how long" rather than my (current) SWAG's and "notepad of pain" ... so I appreciate all the help you can give!

Please try to answer each question carefully:

1. You are going to great lengths to categorize your images by relatively small differences in sky brightness (I know you call this SQM but I prefer the more general nomenclature).  I've asked this before. Why? Interpreting raw SQM readings is hardly straight forward. I need to know how you are interpreting the different SQM values that you get on different nights. Multiple choice below:

OK, "sky brightness" will work ...

a. Is this primarily about the sky background level on your images? You mentioned problems with different sky levels in processing. If so, please elaborate.

As we know, stacking is a necessary step to getting good images, and there are several products out there that will do stacking: I use CCD Stacker from CCDWare, PixInsight and recently have been experimenting with Astro Pixel Processor.  Each is good, but each has limitations in what they can process (and as they improve in areas they are weak I shift my focus from one to the other, that's why I never delete my raw data) but they ALL function better if the lights they are supplied are as normalized as possible ... that means the stars are all about the same size (no blooms), the level of detail is about the same (the seeing is consistent) and the sky brightness is about the same.  That's just (as you mentioned) "garbage in, garbage out" ... if half of your lights have blooming stars, more sky background, fuzzier pixels from seeing then you shouldn't be surprised if you don't get a good registration and stack (and in fact several of packages will pre-sort the lights and throw out those that just are too wonky) ... you know all this ...

By minimizing the aspects of a series of light that are going to vary I can get better stacking results; I can control the level of sky brightness by sorting lights based on the SQM meter readings for that night, I can sort for seeing based on the FWHM of my guide stars for that evening ... so I do that. 

Some of the artifacts I've seen with stacking software if I "poison" the stack with something that has a background SQM much more than .1mag beyond the sequence baseline is speckling in the background and "halo's" of darkness around stars; similarly, if I "poison" the stack with something taken at a different seeing (typically more than .5 arc-second) the details will develop a "fuzz" around them.  I've found my best results if I keep all of the lights within .2mag of SQM and .5arc-second of seeing ...

Note that these are "master lights" that I'm stacking AFTER a "nightly stack" ... so recall my sequence is to take the lights for the evening at a known SQM and seeing, take my flats in the morning, combine those with a master dark from my dark library for that temperature and that sensor, do some light postprocessing in PixInsight (PixelMath, DBE) and then stack that series into a "master light" for the evening.  That "master light" is zipped up and stored away (at that point I don't need the flats since I've processed out the dust motes and don't need to darks because I've already removed that noise, the stacking process took advantage of my dithering to get rid of the hot pixels so I'm left with a "pure" signal light ...

b. Is this a proxy for transparency. Are you assuming that higher SQM values mean that the sky is more transparent and thus you get more signal in addition to a lower sky brightness. If so, please elaborate on how you process your images to take this into account. Many people would simply toss the lower quality images.

Conceptually correct, with higher SQM values (lower sky brightness) the sky is more transparent and I can get more signal before it's overwhelmed by sky noise; that's why people image at dark sites and not in the center of Central Park, you can get more signal before the sky brightness overwhelms saturates the exposure.  I don't toss the lower quality images because a lower quality "something" is better than a high quality "nothing" and as stacking/ postprocessing technology evolves, those "low quality" exposures today have perfectly good signal tomorrow.  PixInsight's DBE and Drizzling technology over the last few years have shown that quite dramatically ...

To process things I physically sort the images based on the SQM and the seeing for that night; so, for object A I will have ten or fifteen folders containing the lights/ flats/ darks for the imaging evenings ... those are broken down by SQM and seeing (which also has different binning values).   Using the ST4 paradigm, for each object A I will have multiple Imaging Projects, one for each SQM gradation/ seeing gradation permutation, each one accumulating based on the conditions for that evening ...

Think of it like collecting state quarters; you eventually want to get all 50 in perfect condition in your collection, but they come in different quality grades off the street.  You have 50 states to collect, and three quality grades.  You don't want to just trash the lower quality grade because you may not have that state yet, so as the quarters come in you sort them by state and then by grade so over time you'll have some states with high and low quality, some with only low quality and some you're still waiting on.  Once you get enough low quality of a state you can sort them and get rid of the really bad ones ... but over days, months, years you'll eventually get all 50 states with high quality as well as all 50 with the lower quality (that maybe you can shine up someday!) ... 

With advances in stacking software and image processing software it's definitely a good idea to keep around the lower resolution lights ... 

c. Are you selecting different targets for the night based on the raw SQM value? In reading above, this seems to be what you are doing, but I'm not sure. So you would go after certain targets that you wish to exposure for fainter signals, such as the halo of a galaxy (what you are calling detail) only when the SQM is high?

Yeppers!  That's where the seeing comes in ... the SQM/ sky brightness value tells me how "deep" I can go, but the seeing tells me how much detail I can get for that object.  Some objects like planetary nebulae don't have that much detail, or if they do then it's tens of arc-seconds in size, some objects like galaxies have arms and dust lanes only a few arc-seconds in size; if your seeing is 2.0 arc-seconds and you're shooting an object that has detail only 1.5 arc-seconds in size then you're wasting your time. 

Look at it this way; suppose that you were at the North Pole observatory, where you could shoot for dozens of hours uninterrupted ... you could easily capture all of the lights you needed, and it would all be at the same seeing and SQM ... that's the best case, yes?  Well, by keeping lights taken under similar SQM values and seeing conditions I'm essentially duplicating that experience, which makes it easier in postprocessing and then the eventual stacking of all of those dozens of lights ...


2. I need to better understand your issue with regard to the pier flip. I want to work on this soon. Multiple choice below:

a. Are you trying to go all night without ever flipping?

Yes, each scope is designated "East" or "West" and I never want the OTA to get closer than 5deg from vertical on that side

b. Are you trying to get all images for a given target on the same side of the pier so they will be consistent?

No, the consistency is on the SQM for that evening and for the seeing value; as long as I'm taking it from the same class of scope/ imager then the pier placement is irrelevant.  It's not uncommon for me an object to come into range at the beginning of a season and I'll image it on one pier side, then once the object passes the zenith I'll finish up the season on the other pier side

c. Are you trying to minimize the number of flips on a given night? E.g. do everything you can on one side, then flip to the other for the rest of the night?

Nope, no flips whatsoever for that scope ... I literally have scopes designated "East" that are collimated, transported, stored and used in one orientation and others collimated, transported, stored and used in the other orientation.  It's a well known problem [https://www.cloudynights.com/topic/388456-mirror-flop-with-c11hd-how-bad/], just google "site:cloudynights.com mirror flop collimation" and you'll get page after page of people complaining about mirror flop throwing off collimations for SCT's larger than 9.25 ...

Thanks!