Other renderings#

The pyramid result (LAP) is lapstack's main output, but it is not the only way to turn a stack into one picture, and on some subjects it is not the best one. A run can produce two more images beside it, and then you can brush one into another.

All three are turned on in the Run ▾ menu before a run, and each is a layer of the Stack group afterward, a row of the Save step, a retouch target and source, and an image the stereo, rocking and 3D outputs can be built from.

Depth-map rendering (DFR)#

also render from the depth map in the Run ▾ menu. The Run button then reads Run LAP + DFR.

Instead of selecting pyramid coefficients, this renders a second stacked image straight from the depth map: every frame is decoded again, warped with the registration found during the run, and blended in with weight

1 − |frame index − depth|

at each pixel. So each pixel is the average of the one or two frames nearest its depth.

The run then opens a side-by-side compare with LAP on the left and DFR on the right.

When DFR wins#

DFR has no pyramid halo, because it never makes a per-band decision — it simply takes the frames that belong at that depth. It is smoother, and on subjects where the pyramid produces fringing along crossing structures it can be visibly cleaner.

When LAP wins#

LAP resolves fine detail better, and it handles a pixel that genuinely contains two things at two depths — a hair in front of a background — by letting different bands come from different frames. DFR has one depth per pixel and must choose.

The cost#

One more pass over the frames: about 6.7 s added to a 27.7 s run on a 25 × 45-megapixel stack, roughly 25 %.

Rendering from slabs#

from slabs in the Run ▾ menu, with slab size (default 10) and overlap (default 2). This is Zerene's slabbing used as a rendering mode.

The stack is cut into slabs of consecutive frames overlapping by a few, each slab is fused on its own with LAP, and then DFR blends the slab images instead of the individual frames — with weight

1 − dist(depth, [lo, hi])

per pixel: full weight for every slab whose frames span that pixel's depth, falling off over one frame outside it. A single frame is just the special case where lo = hi.

The point is to get both things at once:

• Fine detail and crossing structures come from LAP, within a slab.
• The far-out-of-focus frames that build up noise and halos over a whole stack never blend in, because a slab's frames all lie near the same depth.

Frames in the overlaps are decoded once per slab, so this costs more the smaller the slabs. A single slab covering the whole stack reproduces the LAP result exactly.

Weighted average (WAV)#

WAV (weighted average) in the Run ▾ menu, with contrast power and weight smoothing. --wav, --wav-power P, --wav-smooth R on the command line. This is Helicon Focus's method A.

Every frame's pixels are averaged, with weights that follow their local contrast — so the frame in focus at a pixel counts most, and the others fade in with their sharpness. No pixel is ever picked outright.

That has two consequences:

• The seams and halos a winner-take-all rule can leave cannot arise.
• Where nothing is sharp — a flat area — the frames simply average, and the noise drops by the square root of their number.

The cost is softness wherever a hard pick would have kept one frame's detail.

When WAV wins#

Short stacks, smooth subjects, low contrast, and noisy captures. It is the gentle tool; the pyramid is the sharp one. On a deep stack of a detailed subject, LAP will be better nearly everywhere.

The controls#

The contrast measure is the depth pass's own focus measure (the ring difference filter on luma), block-averaged to the depth pass's working grid, smoothed there, raised to the power, and taken back to full resolution bilinearly. Because of that, --wav needs the depth-from-focus pass; it does not work with --depth winner.

A floor keeps a flat pixel from dividing by zero, so in a featureless area every frame weighs the same — which is exactly the noise-averaging behavior you want.

WAV costs one more pass over the frames.

Choosing between them#

There is no wrong answer here; the images are cheap to produce together and comparing them in the viewer takes seconds.