Another alternative to Stellarium is CARTES DU CIEL (often abbreviated as CDC). sourceforge.net/projects/skychart -- it has many of the same features as Starry Night, possibly even some more. It costs $0 with no strings attached. The display of the sky is a map -- not the kind of realistic rendering with twilight and atmospheric simulation you see in Stellarium & Starry Nights. This can be an advantage as it uses a lot less CPU power and won't drain a laptop battery so quickly when you run it during a nght of observations.
How does this work
The basic flow is like this
- you take a photo of the sky -- if the photo doesn't include EXIF date & timestamp, take a note roughly when it was taken.
- a blind plate-solver -- e.g. Astrometry / AstroTortilla -- will determine the coordinates of the center of that image
- AstroTortilla sends a command to the ASCOM-driver & the (virtual) telescope
- Starry NIGHT or CDC monitors the position of that (virtual) telescope and shows the matching sky chart. (set same date & time as photo)
This looks like a very complex setup -- but in most cases it works seamlessly when you follow the basic / default installation steps
ASCOM DRIVER -- unless you already use a telescope, this isn't a tool you have heard of. You can use this even without a mount and only use the SIMULATOR and the hub. That's the link to connect the Plate-solver & Sky-Chart. You can find the software for free at : download.ascom-standards.org
For this use case you don't need to download anything else -- if you have a telescope mount or cameras, you likely already have all that installed.
PLATE SOLVER -- my favorite solver is ASTROMETRY / ASTROTORTILLA. When you download Astrotortilla via sourceforge.net/projects/astrotortilla/files/latest/download you receive the entire Windows-based package plus the simple GUI interface and it will download the various maps needed to solve your images.
If you are a Linux-user, you can use Astrometry's original code and skip the window's adaptation.
SKY MAP -- currently I use Starry Night SE -- it works good and I have a "free" copy. It also is my tool to send slew commands to my telescope mount. In Cartes du Ciel / CDC you may have to manually use "Track Telescope", in Starry Night there's a checkbox "Follow Scope". Since I started playing more with CDC, I can see additional useful features.
Stellarium lacks the ASCOM interface and even StellariumScope did not provide the missing functionality. StellariumScope can send commands to the mount via ASCOM -- BUT in this setup, the important feature is to RECEIVE & continously MONITOR ASCOM-commands and use those to FOLLOW the telescope's position and show it on the map.
In effect you can use any program you like if it can connect to a ASCOM-compatible telescope. The map doesn't notice the telescope is a simulator.
Below you see a simple flow-chart -- after you've installed the tools
STEP 1 :
You launch Starry Night SE (or other tool of your choice). Connect to the ASCOM telescope via GENERIC or POTH HUB -- do not connect directly to "Simulator" !!
After choosing "Generic Hub" (or POTH) select "Properties" and there you should pick the "Simulator". The default settings of the telescope simulator good enough but you can select "Properties" to open the window with the options. I switch off the "always on top" option. Also enable "start tracking" option.
After you have connect Starry Night or CDC to that virtual telescope via a hub, you have to enable the option "FOLLOW SCOPE" option -- THAT makes it convenient ! If you forgot, you can enable it later or scroll around until you see the telescope's crosshair on the sky's map. If the mount is not tracking automatically, enable tracking from Starry Night directly or make your way through the ASCOM options.
STEP 2 :
Before you start analyzing your photos, review the EXIF-data to determine the time & date. If you travel frequently & wide distances, lookup where you took the night sky photos. Stop the real-time clock of your sky map and change the date, time & location setting to match your photo's timestamp ==> now the chart matches the sky you saw during the shot -- Especially when you aim at planetary objects, using the correct time is important as these elements are not on fixed positions in the sky. A star's RA- & DEC coordinates are fixed and the solver's position will show you the correct location. If the locaton or real time & observation time differ a lot, your target in the simulation may now be below the horizon, while you were able to see it in real life.
STEP 3 :
Launch ASTROTORTILLA and use the drop-down menu to connect to ASCOM. Since there already is an active ASCOM hub (Step 1), you should pick the same hub and click "OKAY" (you cannot modify the settings of the existing connection),
Be sure to set min- & max FOV to reasonable values and match the diagonal FOV of the lens(es) you've used. Also you may have to adjust "sigma" setting.
RECOMMENDATION : from my experience, I prefer to use "arcminwidth" as a basis to define the FOV -- one degree = 60 arc-minutes. (more later)
STEP 4 :
AstroTortilla has the option "SYNC SCOPE" -- THAT IS IMPORTANT. If you cannot enable SYNC (box is gray), your telescope (simulator) is not tracking and you need to enable that.
STEP 5 :
AstroTortilla has the option to directly connect to cameras or use previously saved images ==> right now, you want to use the latter. While you analyze images you took hours or days ago, you will have to adjust the date & time setting in the sky map program. CAREFUL !! use the EXIF setting "Shooting Date/Time" -- other timestamps may be inaccurate and reflect modification of the file, not the time it was captured.
RECOMMENDATION : All my photos are organized in folders starting with YYMMDD filename -- that narrows down the date. Additional sub-folder for different events or sky locations help to confirm if the Plate-solver's solution is reasonable. By dividing up results you simplify the task of stacking images -- each target of that night has its own sub-folder.
Small difference in time will result in small & acceptable mismatch in the display. Except for objects in the solar system, the coordinates are independent of time & date.
The two options (AstroTortilla's) "SYNC" & "FOLLOW/TRACK" in Starry Night / CDC are the key to make this work conveniently -- AstroTortilla solves the image's position and send the coordinates to the virtual telescope via a "SYNC" command. Starry Night (or CDC) monitor the (virtual) telescope's position and after receiving a SYNC, the position changes ==> with the "FOLLOW" or "TRACK" option enabled, the map will show the new location in the middle of the screen. CDC usually, but not always, will follow the changes in the telescope's position -- if not, you have to use the "Track Telescope" function.
At the moment, this combination of tools only will SYNC the center position of the image you've captured. You still need to manually look up the date and the (approx) time. And for better comparison, you want to have a frame depicting the FOV based on the camera & telescope/lens choices. Neither CDC no Starry Night will annotate the picture like you see in results from the Astrometry flickr group.
.
Improving the solver's performance & avoiding mistakes
A few words of caution -- steps you should follow when you want good results fast. There is no magic one-fits-all setting -- but there are some cardinal sins that can make any plate-solver a huge waste of time.
You should heed these commandments :
ACCURATE FOCUS is really, really important. If you have a bright star, your camera's autofocus might be usable. Even if you want to look at other parts of the sky, use that bright star to determine focus. After that, disable AF (clutch or switch on the lens) and preferably use a wrist rubber band to prevent zoom & focus position to change. Especially when pointing up, the weight of the lenses can drag the zoom & focus down.
Blurry, over-sized / out-of-focus stars is one sure way to throw off the solver and have it waste your time waiting for useful results that never come.
ROUND STARS -- You have to find a balance between high ISO and elongated startrails. Too high the ISO and the camera's noise may be mistaken for stars in the sky. Too long an exposure and you have trails and the plate solver cannot identify them as stars. A polar-aligned, motorized tracking mount makes this easier.
SUFFICIENT CONTRAST -- with a motorized mount you can extend the exposure time but that can get you into trouble when you are in or near a city, as the orange glow of light pollution will wash out your exposure. A LPS filter helps (but extends exposure time).
SIGMA -- this parameter in Astrotortilla defines the threshold between real stars & noise. If you set it high, you may not get enough stars to solve the position, too low and you overwhelm to solver and likely include many "fake" stars produced from camera noise.
REASONABLE SETTINGS -- you can download all the maps and define to search the entire sky and let the solver assume the lens' FOV is between 360°...0° -- just don't complain about how long it takes to come up with a solution. With a few minutes of online research you can determine the FOV of your camera + lens (CCDCALC, en.wikipedia.org/wiki/Angle_of_view and other sites & tables).
Starting with "SIGMA = 1" is the default but is asking for trouble. Instead, I'm starting with a much higher threshold and reduce it. Keep an eye on the "number of stars found". That result is briefly displayed in Astrometry's status bar. The official help-page recommends to have ~200 stars, in my experience having 30...60 stars yields higher accuracy and much faster solutions and therefore I start with a high SIGMA value. And if I cannot get a solution, I decrease the value by ~25% and try again. YMMV.
Similar, you will recognize, capturing a 10...30 MPix RAW image and send it to the solver is overkill and a waste of time while a 2MPix JPG image usually is more than enough.
After a few attempts / nights, you will gather s couple of (SIGMA) settings combined with ISO & exposure and those will quickly give to good plate-solver results. You need to experiment a bit on your own. There is no UNIVERSAL SETTING to fit all needs -- and the values I mention are starting points not the ultimate solution.
DO SOME SANITY CHECK -- especially while you're getting started and your flow is untested (and you include many high-res maps) it can happen that Astrometry finds an accurate match -- but it is in the wrong place. In that big wide sky, patterns are not completely unique and therefore Astrometry can make a mistake, especially when the parameters are very vague (wide). The better the settings match the actual setup, the lower the chance of misunderstandings. But in the end, YOU HAVE TO CHECK THE RESULTS -- and using the virtual telescope & sky-map helps.
Often you focus at a bright star to begin with. Or at a well known Messier object -- run the solver and use the virtual telescope mount + CDC show you the results.
I have observed failures of the Plate-Solver -- and usually it was my fault:
- a position was reported as NCP when it should have been UNSOLVED
- at times the "solved" position was way off -- the best way to identify the mismatch was to look at the sky map and compare it to the photo. For example, there was a huge, bright star in the photo and the "solved" position lacked any bright star.
- with a simple diary, you can document the INTENDED targets ==> I'm using APT to capture images and specify the target ==> APT creates sub-directories "YYMMDD" for each shoot plus individual "target" sub-directory trees. These targeted positions will help you check if the solver has gone off the reservation.
- My SUGGESTIOED PRACTICE : setting the min- & max FOV to be +-50% of the assumed diagonal FOV is not a very challenging constraint. Often I use a FOV of 15...900 arc-min (1/4°...15° FOV) to cover all lens + camera combinations and with proper SIGMA values get results in < 30s.
.
PC requirements :
The requirements aren't unusually high and naturally it helps to have a faster CPU. Having MORE CPU CORES DOES NOT HELP -- the solver wasn't developed for multi-core. High-end graphic GPUs have no impact. Vast amounts of RAM help a bit but not much -- use it to cache HD the helps. Faster disk helps, especially with large maps & high image magnification.
The volume of maps to solve your images depends on the maximum maginfication of your telescope + camera combo ==> Higher magnification, thus narrower FOV requires more details and that means larger volume.
AstroTortilla itself is tiny but it requires ~300MB "Mini-Linux" environment (Cygwin) to function. And you have to add the sky charts to that ... C:\cygwin\usr\share\astrometry and that volume can range from another ~200MB to over 28GB. For most users, ~1GB is sufficient. Enthusiasts with larger magnification, may require ~3.5GB maps.
For my astronomy & real-time use. I have an old-fashion laptop. 13" netbook LCD and a i5 CPU and it handles the plate-solving very well. A faster CPU helps but often is limited by the HD access to the many map images. Usually I get results from the solver within 30...60s. If it I have no result after waiting > 2 minute, I usually abort & reshoot with new settings (EXCEPTION : very first attempt and shots close to Polaris -- there, I wait ~3 minutes before I pull the trigger and abort). see uncut video in real-time : www.ipernity.com/doc/stargazer95050/28668501
If you don't define a deadline and your setup or parameters are bad, you can waste 30 minutes or more and AstroTortilla still won't come up with a result. (Yes, when I started, I did let it run that long out of curiosity ...)
.
© Copyright 2015, All rights reserved -- post a link to this page or contact me, if you want to use it in your blog or publication or if you want a (large) print.
Sign-in to write a comment.