Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Usage questions ..
#11
(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.

Hey Greg, here's a recipe I made up for how to accomplish this ...

Create locations:
[Menu] Setup:Locations
New: Add Location: Other: Park: Banff
Edit: Change Name to "Site A West SQM 21.0", OK (close dialog)
Select "Sky Brightness" button, goto advanced, change "Sky Brightness" text to 21.0, OK (close dialog)

Repeat as needed for "Site A West SQM 21.5", etc.
Repeat as needed for "Site A East SQM xx", duplicating each SQM value

Create meridian limits
From main dialog, select location to modify in middle drop combo (it doesn't matter what's in the Target List, as long as there is some object(s) in the main dialog listbox), here "Site A West SQM 21.0"
In the main dialog listbox, RClick on any object in the listbox, select "View Overhead Sky Chart"
In the "Visual Sky Simulation" dialog, verify that the "Site A West SQM 21.0" is selected and using the grabbers obstruct 175deg from 180deg (there's a way to do this with a text file that's easier, but I was unable to accomplish that so I use this method)
Close the dialog, the limits will be saved

Repeat this for each East and West location

Create target lists:
From main dialog, press "Target List" combo, opens tree dialog of object lists
New: Default folder, Title of "Site A Fine", description of "Seeing < .8"

Repeat as needed for Target list of "Site A Coarse" "Seeing .8 to 1.5", "Site A Binned" "Seeing 1.5 to 2.0" and "Site A HyperStar" "Seeing 2.0+"

Associate DSO's with target lists:
[Menu] ToolsBig Grinesignation search
Enter object name in "Quick Search", such as M42, Search
Search results will return list of object names, select the one you want, go to the drop combo "Target List" and select the Target List we want from the tree dialog, here "Site A Coarse", press "Add to List"
Enter another name in Quick Search, such as "Sombrero", Search
Search result will return object name, select it, select the Target List of "Site A Fine" from the tree dialog, press "Add to List"

Generate new target imaging projects:
Select the target list to work with from the "Target List" drop combo on the main dialog, here "Site A Coarse" (you should see a single object, M42)
RClick on object ID, select "Create New Imaging Project"
In the new imaging project dialog, "Basic Properties" tab
Change basic project name to "C Orion Nebula", this ensures that we know this project is for coarse level exposures
Select Imaging system appropriate to "Coarse" projects, Purpose of "Astrometry", Expose multiple nights
"Exposure Goals and Filters" tab
Define by SNR, expose for "Faint regions", "Arms", etc. (fine level of detail)
Total SNR per filter at 60, SubExposures Auto, Binning x1 (x2 if this was a "Binned" target group)
Minimum quality at A, "Clear" filter selected

Repeat for each object in the "Site A Coarse" target list

Repeat for each additional target list, such as "Site A Fine"

If there is a need to have an object appear in more than one seeing category, say M42 in both "Fine" and "HyperStar" then RClick on the "F M42" project, select "Edit Imaging Project", press "Duplicate" and change the basic name to "H M42", change the imaging system as needed and press OK

At this point we have ... "Locations" defined by geography, SQM value and pier side [Site A West SQM 20] [Site A East SQM 20],
"Targets" defined by site seeing [Site A Fine] [Site A Coarse]
Imaging projects for each object in each target list [M42 in Site A Coarse] [Sombrero in Site A Fine]

Generate schedule for evening:
Determine the SQM to be imaged at (SQM 20) and estimate the seeing expected (Coarse)
From the main dialog, select "Scheduler" to display the Scheduler
From the top combo group, select the appropriate date and select the Location appropriate to the SQM value and the pier side
Select the imaging system; this will display all imaging projects which utilize that imaging system (C M42, F Sombrero) without regard to target list placement
In the "Imaging Projects" group box, select the seeing conditions (1.25 for Coarse), the expected temp and RH values

Next, we select the projects you do want NOT want be scheduled, paying attention to the designator letter in front of the project name by going to the project wanted (here "F Sombrero" or "H M42"), selecting it and RClicking in the "S" column, selecting "Exclude".  Repeat as needed, for "Coarse" seeing we only want "C M42" unexcluded

Now we generate the schedule by pressing the "Auto Schedule" button ... it will generate an optimized list for the objects which have not been excluded, which completes the exercise of generating an optimize imaging schedule for a given target list at a given SQM on a given pier side with a given seeing ...
Reply
#12
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.

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:

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.

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.

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?


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?

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

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?

Thanks!
Clear skies,
Greg

SkyTools Developer
Reply
#13
(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/38845...d-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!

Hope this helps!  Dodgy
Reply
#14
If you're still thinking of putting meridian flip stuff into ST4, bear in mind a couple of things ...
- As far as I can tell, and I've chatted with several imagers through the years, I'm the *only* one who "solves" the issue of mirror flop by just "saying no" to meridian flips ... everyone else has mirror locks and crayford focusers, or just ignores the issue, or gets a Takahashi.  Most people image with a single scope, not a scope farm and the idea of giving up 50%+ of a nights imaging is beyond abhorrent ... and as ST4 is optimized for a single night session, watching their nice SNR 30 session turn into an "unable to schedule" wouldn't make many friends! ... I'm sure that people would much prefer you spend your time on an SGP tie-in instead ...
- You already do the scheduler and Night Bar calculations to take into account an obstructed horizon; you could add a drop combo to the Imaging Project characteristics for "Ignore meridian" "Force to East" and "Force to West" ... default is "Ignore", if they select either of the "Force to" options you would artificially add that more than 185deg, less than 175deg obstructed horizon logic to the various calculations (don't go right at 180deg, that's basically undefined behaviour as the mirror could swing either way.  Better to be sure one way or another) ...
Clear Skies!
Reply
#15
Wow! This has been very interesting. Although I have a lot of experience with the science of image processing, I don't have a lot of experience with the art of it. To see how you put it ll together is very cool. The ideas of stacking images that are each nightly stacks themselves is very interesting. Thank you for your detailed description!

I do want to find a way to help people better plan when flipping is something they want to avoid and minimize. I don't want something complex right now, but I need to do something. So I'm kicking around several ideas. Listening to people helps me think more clearly, so thanks!
Clear skies,
Greg

SkyTools Developer
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)