Actual misprints and errors in the first printing:
(p. 15) Choosing the Computer:
|change||8 megabytes of RAM|
|to:||8 gigabytes of RAM|
I thank William Shaheen for finding this misprint.
(p. 47) Nikon Manual Movie Settings:
|to:||1/60, 1/50, or 1/30|
This bug has not been fixed in D5300 firmware 1.01, 1.02, or 1.03. Manual Movie Settings still needs to be turned off when you are doing still photography with Live View.
(p. 165) INDI and Windows:
|change||as well as Windows.|
|to:||and can be bridged to ASCOM under Windows.|
(p. 212) DeepSkyStacker calibration:
|change||On subsequent runs, it uses the master frame to save time.|
|to:||On subsequent runs, you can select the master frames rather than the whole set of calibration frames, to save time.|
(pp. 230-231) Lights, Darks, Flats, and Flat Darks (PixInsight):
Although not an actual correction, the note to pp. 230-231 below is too important to ignore.
(p. 271) Matching Focal Length to Pixel Size:
|to:||"||in 6 places.|
(p. 302) Formulae for dynamic range:
|change||Bias = the average (or preferably median) of the dark frame|
|to:||Bias = the average (or preferably median) of the flat dark|
There is no dark frame other that the flat dark already mentioned.
(pp. 336-7) Exposure Tables:
|to:||m"||in table headings where it is not already in italics.|
(p. 341 lower right) Index:
shopping strategy should be indented 2 levels, to line up under manufacturer.
(p. 16) Transferring files from one computer to another: One method I use is to copy them to a 32-GB SD card. However, the default file system (FAT32) will not accommodate files larger than 4 GB, so you must format the card as exFAT or NTFS instead (which also makes it faster). With exFAT there is a further problem that some Linux systems do not timestamp the files correctly when Daylight Saving Time is in effect. NTFS works reliably, but then the card cannot be used in digital cameras, only computers.
(p. 19) Ethical issues: I wrote, "some people are likely to be put off by a picture of anything, no matter how beautiful, if it is astronomically false or impossible, such as a combined image of two separate nebulae or an eclipsed sun in front of clouds."
The latest thing is even stranger — motion pictures with fake and unrealistic movement in them, made from still pictures. I've just seen a motion picture of a well-known nebula in which the gas clouds are swirling around (not in any physically realistic way) and, some of the faint stars are running around in circles, as if something were chasing them. Very disconcerting, especially since people are going to see it and think the motion is real.
(p. 25) dcraw: See note to p. 228.
(p. 82) Dark frames: When taking dark frames indoors, particularly for sensor testing, note that your lens cap may not be perfectly opaque to infrared light; also, a tiny amount of light can enter through the eyepiece. It is best to take dark frames in the dark.
(p. 85) Acquiring flat fields: There are two problems with using the daytime sky as the light source. One is that the color is so bluish that one risks overexposing the blue pixels while inadequately exposing the others. The other is that when first set up in the daytime, the telescope is not focused on infinity, unless you can focus it on the moon or a very distant terrestrial object.
Ten years ago, it was common to decolorize the flats by binning (averaging) pixels 2×2. We now know that one of the important functions of flats is to compensate for differences between individual pixels, not just dust motes and vignetting, so this is no longer recommended.
Currently I'm using an LED-illuminated, USB-powered artist's light box as a light source for flats. If you use an 8-inch (20-cm) telescope, bear in mind that some "A4 size" light boxes are slightly more than 20 cm wide, and some are slightly less; you'll need one that is bigger than the telescope objective, of course.
(p. 108) Lens quality: One of several good sites for published tests of newer lenses is www.lenstip.com. Their plots are not MTF curves, but rather the resolution at which 50% MTF is achieved, plotted versus f-stop. You want the center and edge readings (red and blue dots on the graph) to stay close together so that star images will be round. Most lenses nowadays are sharpest wide open or nearly so, and resolution falls off at higher f-numbers; that is normal. The publishers of this site are harsh critics of lens quality (just like us), and they share my impression that many of the best lenses are made by Sigma.
(p. 152) Polar scopes: I found that when I tilted my head to look through my polar scope, I often misjudged the orientation of the reticle. The cure is to use the altitude adjustment of the mount to establish exactly what direction is vertical. Center Polaris, then use the altitude knob to move it to the very bottom or very top of the circle, and then go from there, using software or the chart on p. 153 to find out where to place Polaris.
(p. 158) A futile quest: See note to p. 160.
(p. 158) Noises from mounts: One aspect of mount performance that I didn't mention is noise. Computerized mounts with servo or stepper motors can make strange noises and move in irregular jerks when slewing. Noises mean nothing unless there is actually a problem with tracking performance and the noise is correlated with it. Some mounts squeal, hum, buzz, creak, and alternately fall completely silent at unpredictable times while tracking. As for irregular jerks, when the mount slews from one place to another, an algorithm manages the motor acceleration, and sometimes the criterion for using a higher speed is fulfilled for only a fraction of a second. As long as the telescope ends up pointed correctly, the noises it made getting there are of no significance.
(p. 160, bottom) Unguided subs: The length of unguided exposure that you can make with a particular mount is not inversely proportional to focal length. For example, if you can go 2 minutes with a 100-mm lens, that doesn't mean you can necessarily go 1 minute with a 200-mm lens.
The reason is that periodic error is periodic. It is an oscillation, not a steady drift. As you expose longer, the error doesn't keep increasing; it reverses itself and the tracking swings back and forth around the correct position. The error in a 2-minute exposure is anywhere from 1 to 2 times that of a 1-minute exposure, depending on the waveform. At shorter focal lengths, the error can be completely invisible no matter how long you expose, and then, at a particular focal length, it suddenly starts to make a difference even in short exposures.
The proportionality does work in the opposite direction. If you can expose 1 minute with a 200-mm lens, then you can expose at least 2 minutes with a 100-mm lens, possibly more.
How much periodic error you can ignore:
Here is a formula how long you can expose without corrections,
with a given amount of periodic error. It assumes (falsely) that the periodic error
is a pure sine wave. Then:
Max. exposure time (seconds) =
Worm period (seconds) × (Tolerable error / Total PE) / π
The tolerable error is probably about 1.5 to 2 pixels, given that not all of the subs are affected to the same extent. (The formula is for the worst case; in parts of the cycle, the tracking is appreciably better.) Both tolerable error and total PE are peak-to-peak, in arc-seconds.
Example: My iOptron SkyTracker has a worm period of 552 seconds of time. (We know that because it has a 156-tooth main gear, which rotates in one sidereal day, which is 86164 seconds, and 86164 / 156 = 552.) I'm using a 200-mm lens on a Canon 20Da, which gives 4.5 arc-seconds per pixel, and my tolerance is two pixels, or 9". The total PE of the SkyTracker is 60". How long can I expose?
Max. exposure time = 552 × (9" / 60") / π = 26.3 seconds
And in fact I get good results with 30-second exposures. Not all are perfect, but most are good.
Derivation: The factor of π in the formula arises as follows. The slope of the steepest part of a sine curve is 1 with the angle measured in radians, or 2π with the angle measured in cycles. The peak-to-peak amplitude of the sine curve is 2. Scaling this down to a peak-to-peak amplitude of 1, we scale the slope down to π.
(p. 161) Backlash: Celestron tells me there can easily be 60 arc-seconds of backlash in the gearbox (not the worm gear); this is normal, and no adjustment of the worm gear will affect it. They also say that when the mount is deliberately unbalanced for better tracking, it is acceptable for the unbalance to be so large that the telescope actually moves when brakes are released.
Celestron's specification for total backlash on a mid-sized German equatorial mount is 60 to 180 arc-seconds. Zero backlash is not the goal.
(p. 165) Communication with the mount: Regarding INDI see second note to p. 189.
You may be wondering why so many telescope mounts still use RS-232 serial ports instead of USB. There are two reasons. First, RS-232 signals are much better at traveling over long cables through electrically noisy environments. Second, unlike USB, the RS-232 standard does not require a device driver. Mounts tend to last longer than computers and may be used with computers that were not foreseen when the mount was designed. If the interface is RS-232, then instead of needing a device driver for the mount, the unforeseen new computer merely needs to emulate the old RS-232 standard.
(p. 166) When autoguiding with a color camera, bin the pixels 2×2 if possible, to eliminate the Bayer matrix.
(p. 169) Choosing a Guide Star: Strange things can happen if your guide star is a double star and you don't realize it. If your autoguider seems to be jumping back and forth or just not acting normal, try a different star.
(p. 172) Interpreting Guiding Graphs: Yet another cause of sudden jerks is electrical — a dew heater that turns on and off with a thermostat, causing a fluctuation in the voltage. You may be unaware of the thermostat action. This is a good reason to power the mount from a different battery than the dew heaters.
(p. 176) How Roundness is Measured: PixInsight has moved SubframeSelector from Scripts to Process, ImageInspection, and it runs much faster. If all you want to know is eccentricity, and FWHM in pixels, then you need not tell it the scale of the image or the gain of the camera.
(pp. 185-6) Alternative to lamp cord: The ideal power cable would be the same size (of wire and insulation) as lamp cord, but more flexible thanks to silicone insulation (rather than PVC) and wires made of many very thin strands. I've found a supplier of such wire, BNTECHGO, in China, and their product is available on Amazon at this link. Do not confuse it with other BNTECHGO products, nor with red and black "zip cord" from other sources.
(p. 189) Linux is better supported with every passing day: For greater long-term stability, many amateurs (including me) are migrating to Linux for telescope and camera control (a process I have nicknamed "defenestration"), and the available software is getting better rapidly. Open PHD Guiding (PHD2), FireCapture (for video), and KSTARS (for star maps), and especially Ekos (for camera and telescope control) have free Linux versions. PixInsight supports Linux and macOS as well as Windows.
(p. 189) Telescope controller need not be a laptop: If you're going to have a dedicated computer for your telescope, autoguider, and camera, it need not be a laptop. The latest trend is to use a very small computer that rides on the telescope and is accessed remotely.
The small computer may be a Raspberry Pi or an Intel Compute Stick, but ready-to-use solutions are becoming commercially available. One is the Stellar Mate, much cheaper than a laptop. The computer is small enough to ride on the telescope, runs on 5 volts, comes pre-configured with suitable software, and totally frees you from worrying about whether your main computer will remain compatible with your equipment-control software. Stellar Mate runs as an INDI server, which interfaces with your equipment and enables you to control it with Ekos or other software from the computer you are sitting at.
(p. 202) PixInsight dark frame optimization should not be used if the sensor has appreciable amp glow. It assumes the dark frames are genuinely dark.
(pp. 230-231) Lights, Darks, Flats, and Flat Darks (PixInsight):
There is a more straightforward way. For "The simplest way... This is Method 1 from Section 11.2.6" substitute:
The simplest way to proceed is shown in [the new figure below]. Put in the lights, darks, and flats in the usual way. Put in the flat darks as bias frames. You are free to use "Optimize dark frames" or not. This is Method 2 from Section 11.2.7.
(p. 281, p. 298) www.sensorgen.info is apparently defunct.
(p. 295-297, 302) Dynamic range as reported by PhotonsToPhotos is not the same as reported by DxOmark (even when derived from DxOmark data). PhotonsToPhotos uses a different SNR limit and produces values that are about 2.5 stops lower.
(p. 304) Here is Table 16.1 with a third-generation Canon added, the 200D.
I don't plan to keep adding to the table indefinitely, but this step in technological progress is noteworthy. The Canon 200D is ISOless but seems to have more read noise than the Nikon D5300. However, it has become evident that the Nikon performs considerable noise reduction by preprocessing the image file in the camera, while Canon raw images are "rawer." Thus, the numbers are not directly comparable.
(p. 308) Filter modification can bring out chromatic aberration in lenses. This point needs to be emphasized. With my Nikon 180/2.8 ED IF (non-AF) lens on a modified camera, the stars have bright red haloes. With some other lenses, it is necessary to "focus out" the red haloes, and the star images are not quite as compact as with an unmodified camera.
(p. 309) Benefit from filter modification: Here is a more dramatic example than the one shown on p. 309 and on the back cover.
These are the nebulae NGC 7822 (top) and Cederblad 214 (bottom) (conflated with NGC 7822 in some older catalogues), very thin red emission nebulae. Both are stacks of ten 2-minute exposures, taken in town (not at a dark-sky site), with the same 180-mm lens at f/4. Because the sensors had different size pixels, the scale does not match exactly.
Left: Nikon D5300, unmodified; right: Canon 60Da, which comes from the factory with a special filter for greater hydrogen-alpha sensitivity.
(p. 324 Fig. 18.5) Incorrectly reported orientation in Astrometry.net: This problem seems to have been corrected in the version of the software that is now on the nova.astrometry.net server, but I still advise caution. It has not been corrected in the versions that are available for you to run locally. The problem apparently arises from some ambiguities about the orientation of FITS files, and other files are converted into FITS for processing. What you really want, of course, is to identify objects and determine the arc-seconds per pixel, and those always come out correct.
(p. 324) Unreliability of astrometry.net web site in November 2018: As this is written, the web site is dealing with hardware failures and is only partly functional. New York University, which hosts it, plans to restore full functionality, but you may want to run the software locally (see below).
Running Astrometry.net locally under Linux:
The following is how I got it working under Linux Mint; the
same procedure works under Ubuntu, Debian, and Windows Subsystem for Linux (Bash on Windows).
(1) Acquire and install the Debian package:
sudo apt update
sudo apt install astrometry.net
(2) Install the index files of star positions:
sudo apt install astrometry.net astrometry-data-2mass-08-19
sudo apt install astrometry.net astrometry-data-2mass-07
sudo apt install astrometry.net astrometry-data-2mass-06
(3) Example of solving an image:
solve-field --downsample 2 -L 0.1 -H 180 myfile.jpg
Here --downsample 2 means to downsample the image before solving (this will not affect pixel size calculations; omit it if the image is small, and change it to 4 if the image is large). The parameters-L 0.1 -H 180 tell the software the field is between 0.1 and 180 degrees wide; you can save time by giving a more precise guess.
You'll get dozens of messages saying that a certain set of objects at a certain scale "did not solve" — that is normal. Eventually, if successful, the program will write out several files. The most important are myfile-ngc.png (the annotated image) and myfile.wcs (coordinate information). You can render the latter into readable text using the command:
The other files are disposable. Most of them are FITS format data files but do not contain viewable images.
See also /etc/astrometry.cfg for configuration settings that you can change, and use the command man solve-field for very concise instructions.
Note that the Debian-packaged version does not identify NGC or Messier objects, only bright stars. That is because of copyright problems with the NGC catalogue that is bundled into Astrometry.net — the Debian repository system does not consider it legal to distribute. Simply adding the files does not help; the software compiled for Debian does not use them. Instead, you can go to https://github.com/dstndstn/astrometry.net, get the source code, and build the software yourself, or use one of several Windows plate solvers that use Cygwin and include the full set of files. I hope to add more information about this.
Back cover: See note to p. 309.