How Do You Use the Bahtinov Analyzer in N.I.N.A.? What Has to Be True Before You Start

The Bahtinov Analyzer in N.I.N.A. is a toggle in the image panel of the Imaging tab, and it reports nothing until four conditions hold at once: a Bahtinov mask is fitted, image looping is running so the frame refreshes, the star is bright enough to draw three separate diffraction spikes without saturating, and the analyzer's rectangle sits over that star. With those in place, N.I.N.A. crops the image already on screen, converts the crop to 8-bit grayscale, hunts for the six strongest straight lines in it, and displays one figure labelled Distance, in pixels, to two decimal places. Focus is then adjusted in small steps until that figure settles at its lowest stable value across several frames, after which the mask comes off and HFR or FWHM confirms the result on an unmasked exposure. The tool's own tooltip is modest: "Drag the rectangle over a star with the bahtinov spikes. NINA will try to detect the spikes and show the error."

What has to be true before the analyzer reports anything

The published source shows what the tool is looking for. `BahtinovAnalysis.cs`, in the N.I.N.A. repository maintained by Stefan Berg and the project's contributors under the Mozilla Public License, runs a Canny edge detector with a Gaussian size of 10 over the cropped region, then a Hough line transform, then asks for the six most intensive lines. The next line of code decides your evening: analysis proceeds only if exactly six lines came back. Those six become three centre lines, the outer two are intersected, a perpendicular is dropped to the middle line, and the length of that perpendicular is the number on screen.

Nothing in that chain measures brightness, star size or seeing. It measures whether six straight edges are present and where they cross.

Two consequences follow, and neither appears in the user documentation. First, the crop is taken from the displayed image, after N.I.N.A.'s auto-stretch has been applied. The stretch defaults live in `ImageSettings.cs`: an autostretch factor of 0.2 and a black clipping value of −2.8, which the interface tooltip defines as a "Black clipping factor in sigma units from the median". The screen stretch is the input, not decoration. Second, the crop drops from 16-bit to 8-bit, leaving the analyzer 256 grey levels rather than the 65,535 of the original frame.

Before the toggle is worth pressing, four things should already be true:

1. The mask is fitted and the mount is on a star bright enough to show all three spike sets.
2. Image looping is on. N.I.N.A.'s snapshot defaults, in `SnapShotControlSettings.cs`, are a one-second exposure with looping set to false, so looping is an explicit act.
3. The exposure leaves the spikes visible and unsaturated, checked against the Statistics panel rather than by eye.
4. The crosshair overlay and the aberration inspector are off. In the source, enabling the analyzer switches the crosshair off, and enabling the aberration inspector switches the analyzer off.

Bahtinov Analyzer or N.I.N.A. autofocus?

The N.I.N.A. documentation places these in different categories. The Imaging tab page describes the button as one that "Activates the Bahtinov Analyzer aid tool for manual focusing with a Bahtinov Mask", while the focusing quickstart calls Bahtinov Detection "our experimental feature". Auto-focus has its own page in the advanced documentation, covering curve fitting, backlash compensation and filter offsets.

| | Built-in Bahtinov Analyzer | N.I.N.A. native autofocus | BahtiFocus plugin | |---|---|---|---| | What it measures | Geometry of six spike edges inside one cropped region | HFR of detected stars, or image contrast, across the frame | Spike geometry, plus mask angle and line angles | | Figure reported | Distance, unsigned, in pixels, two decimals | HFR, and in 3.3 builds FWHM and eccentricity, in pixels or arcseconds | Focus error in pixels and an absolute focus error in microns | | Direction of correction | Not indicated; the value has no sign | Derived from the fitted curve, and the routine moves the focuser itself | Reported alongside a critical-focus status | | Mask required | Yes | No | Yes | | Electronic focuser required | No | Yes | No | | Runs unattended in a sequence | No | Yes | No | | Documentation status | Described as experimental | Full page in the advanced documentation | Third-party plugin by CanardConfit, requires N.I.N.A. 3.0 or later |

Both can coexist. The Imaging tab documentation describes the arrangement: a near-focus position found with a mask on a bright star goes into the focuser's Target Position field, so the focuser moves there before autofocus runs.

Setting an exposure that leaves the spikes readable

N.I.N.A.'s defaults bracket the range. The snapshot exposure defaults to one second; the autofocus exposure time in `FocuserSettings.cs` defaults to four seconds. Neither is a recommendation for a masked star, because the mask blocks much of the aperture and the right duration depends on filter, gain, aperture, sky brightness and the star itself.

The advanced autofocus documentation states a condition rather than a number: an exposure that "almost saturates the brightest stars, but keeps the majority under the saturation threshold". The Statistics panel is where that gets checked, since the Imaging tab page lists minimum and maximum ADU among its readouts. On a camera with a true 16-bit converter, such as the ZWO ASI2600MC Pro with its 3.76 µm pixels, the ceiling is 65,535 ADU, and a peak sitting there is a flat-topped star rather than a bright one.

Sources disagree here, and the disagreement is worth naming. Trevor Jones, the astrophotographer behind AstroBackyard and fifteen years of published work on the subject, advises maximum brightness for DSLR live-view focusing: "Make sure that your camera is set to its highest ISO when focusing via live view," because "slower shutter speeds will dim the star, and we want it as bright as possible for focusing." The documentation for AstroPhotography Tool's Bahtinov Aid says the reverse for software analysis, telling users to reduce ISO or exposure on bright stars, or adjust the histogram's black point, to prevent spike detection errors. Jones is describing a human eye on a live-view screen; the Bahtinov Aid guidance is describing an algorithm reading edges. N.I.N.A.'s analyzer belongs to the second category, and a saturated core with a blown-out halo hands the Canny detector the outline of a blob instead of six lines.

Where to put the analyzer region

The rectangle is created in `ImageControlVM.cs` at 200 by 200 pixels. On a 6248-pixel-wide sensor like the IMX571, that box covers 3.2 per cent of the frame width: generous for one star, tight for a star field. The same file caps the box at 80 per cent of the image dimensions and reserves a 10-pixel band at each edge for resize handles, with width and height also typeable beside the overlay.

Two placement mistakes account for most failures. A box that is too small clips the outer ends of the spikes, leaving the Hough transform short, inconsistent segments. A box that is too large admits a second star, whose edges compete for the six slots. Centre the star, grow the box until the spikes are enclosed with a margin of background, and stop.

What the Distance number is, and what it is not

`BahtinovImage.cs` defines the result class, and it holds exactly two members: the annotated image and a double called `Distance`. No sign, no micron conversion, no history, no confidence value. The interface file formats it to two decimal places and appends "px".

An unsigned magnitude cannot tell you which way to turn the focuser, so the first move after a reading is a probe. Move a known number of steps in one direction, watch whether Distance rises or falls across the next few looped frames, and only then commit.

Other implementations chose otherwise. The Bahtinov Aid in AstroPhotography Tool, which uses sub-pixel technology licensed from the Dutch engineer Niels Noordhoek, author of Bahtinov Grabber, reports signed values, and its documentation treats alternating signs as the signature of success: readings swinging between −0.12 and +0.12 indicate turbulence rather than focus drift. The BahtiFocus plugin reports a focus error in pixels alongside an absolute focus error in microns. N.I.N.A.'s built-in tool gives the magnitude and leaves the interpretation to you.

Why a reading near zero does not prove focus

A Distance of 0.05 px on one frame is not evidence of perfect focus, and treating it as such is the most common way to waste a night.

The analyzer measures the image in front of it. Because the value is unsigned it cannot fall below zero, so noise, turbulence and small centring errors all pile up on one side and produce readings that hover near the floor whether or not focus is optimal. The tool re-runs on every newly prepared image, so looping hands you a series rather than a verdict, and the series is the measurement.

There is also no universal threshold, and anyone publishing one has skipped a step. Distance is expressed in image pixels, so identical defocus produces different numbers on different systems. Take the ASI2600MC Pro's 3.76 µm pixels at 500 mm: at 206.265 arcseconds per radian, that is 1.55 arcseconds per pixel, and 0.30 px means something quite different at 2000 mm on the same camera. Pavel Bahtinov, the Russian amateur astrophotographer who published the design in 2005, described the method in terms of visible displacement direction rather than a numeric tolerance.

Take five to eight consecutive looped frames at a given position, note the spread as well as the lowest value, and prefer readings that are low and stable over one spectacular frame.

How far to move the focuser between readings

Step size cannot be copied from another imager's setup. N.I.N.A. ships with an autofocus step size of 50 and four initial offset steps, both in `FocuserSettings.cs`, and the advanced documentation gives two ways to derive a real value: move the focuser outward until star diameter grows by around 20 to 30 per cent, or take 80 per cent of the maximum detectable offset and divide by the initial offset steps.

What a step means physically depends on hardware. ZWO's Electronic Automatic Focuser manual states that "the EAF utilises a 35mm stepper motor which is subdivided into 5760 steps capable of being accurately positioned at any angle." The resulting linear travel is a property of the drawtube rather than the motor, and driving a 10:1 fine-focus knob instead of the coarse knob divides it again.

For manual work, N.I.N.A.'s 3.3 changelog records that the manual focuser step buttons take configurable multipliers, defaulting to 0.5× for the small step and 5.0× for the large, under Options, Imaging, Autofocus. Approach the final position from one direction, since backlash separates a repeatable result from a lucky one.

What to verify once the mask is off

Removing the mask is a state change rather than a software step, and a mask left in place ruins every light frame that follows. It alters the point spread function, so star-size metrics are wrong while it is fitted. Jones puts it flatly: "Do not use a Bahtinov mask if you are using the FWHM function," because "a real reading of the star size can only be obtained when the mask is off."

With the mask removed, star detection is the check. N.I.N.A.'s defaults enable star detection and auto-stretch, with star sensitivity set to High. The focusing quickstart states the criterion plainly: the lower the HFR value the better focused the image, though HFR varies with the telescope's focal length and the sensor's pixel size. The 3.3 changelog adds that the native star detector measures HFR from a centroid-refined curve of growth, reports FWHM from background-subtracted radial profiles and eccentricity from flux-weighted second moments, and can display those figures in either pixels or arcseconds based on the profile's pixel size and focal length. FWHM and eccentricity are listed under 3.3; imagers on 3.2 will find HFR alone.

Take two or three unmasked frames, confirm the HFR sits at or below what the system produced on previous good nights, and record the focuser position. The Imaging tab documentation recommends entering that number in the Target Position field for next session.

When the analyzer refuses to lock on

The six-line requirement in the source explains most silent failures. A dim star yields fewer than six detectable edges; a saturated star yields a blob with a smooth boundary; a cluttered box yields competing lines. Heavy noise reduction or an aggressive stretch changes what survives the Canny threshold, which is why the analyzer sometimes behaves differently after a display setting changed and nothing at the telescope moved.

Dragging the rectangle also does not re-trigger analysis while live view is enabled.

The N.I.N.A. changelog spanning versions 1.7 to the 3.3 nightly contains no entry for the Bahtinov Analyzer at all, and the documentation still calls it experimental. Imagers needing a signed error, a micron conversion or a critical-focus verdict have an alternative in BahtiFocus, CanardConfit's third-party plugin, which requires N.I.N.A. 3.0 or later and a star bright enough to draw the mask's lines.

Frequently asked questions

Why does the Bahtinov Analyzer fail to detect the spikes?

N.I.N.A.'s analyzer only produces a result when its edge detection returns exactly six strong lines inside the selected region. A dim star, a saturated star with a flat core, a region that clips the spike ends, or a second star inside the box will all break that count, and the tool reports nothing rather than an error.

How do I choose an unsaturated focus star?

Use N.I.N.A.'s Manual Focus Targets panel, which lists currently visible bright stars for your location and time; the 3.3 changelog notes 160 additional stars were added to cover more magnitudes. Then check the Statistics panel: the maximum ADU should sit below the sensor's ceiling, which is 65,535 on a 16-bit camera.

Should I use Bahtinov Analyzer or N.I.N.A. autofocus?

They answer different needs. The analyzer is documented as a manual focus aid requiring a physical mask and a human at the focuser. Autofocus measures HFR across detected stars, fits a curve and drives an electronic focuser unattended during a sequence. Many imagers use the mask once to set a near-focus target position, then let autofocus work.

Why does the focus error oscillate around zero?

N.I.N.A. reports Distance as an unsigned magnitude, so it cannot cross zero and instead bounces along a floor set by seeing and centring noise. AstroPhotography Tool's documentation, using Noordhoek's signed implementation, treats readings that alternate between −0.12 and +0.12 as evidence of turbulence rather than focus drift.

How do filter changes affect the focus result?

The N.I.N.A. autofocus documentation states that even parfocal filters can shift focus because of the filter glass itself, and provides per-filter offsets expressed in focuser steps. A Bahtinov result obtained through one filter therefore does not transfer to another without applying that offset, or refocusing behind the filter you intend to image with.

What should I verify after removing the mask?

Check HFR on two or three unmasked frames, since the mask distorts every star-size measurement while fitted. On version 3.3 builds, FWHM and eccentricity are available alongside HFR in pixels or arcseconds. Record the focuser position afterwards and enter it as the Target Position for the next session.