Review focus stacking autofocus brackets with Affinity Photo, Helicon Focus, Picolay, and Zerene Stacker

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,385
This is a review of four commonly used focus stackers. It’s based on a few years’ experience of applying combinations of Helicon, Picolay, and Zerene to autofocus brackets collected using Panasonic’s 4k post focus. Control of linear stacking rails and raw workflows are therefore not considered here. Affinity Photo’s focus merge is also included but evaluation was limited to Affinity’s 10 day trial. As of this edit, the versions reviewed are Affinity 1.7.3, Helicon 7.6.1, Picolay 2019-08-31, and Zerene 2019-10-07.

In summary,
  • Affinity Photo (docs, 2016–present): US$ 50 per major version (also a $20 iPad version), pyramids only, 8.3x slower than Helicon, essentially blind retouching with slow source selection becomes unavailable once a focus stack is closed, no batch processing or canceling stacking
  • Helicon (help, 2004–present): US$ 30–52 per year or $92–192 for no update charges (20% holiday discount), most likely to crash or hang of the stackers tested, fastest among the stackers tested here (0.90 4k frames/core-second from i5-4200U giving 24.0 MP/s benchmark), quickest source access in retouching, retouching not supported from batch processing but available with semi-batch use pattern plus sufficient RAM, only stacker with GPU acceleration
  • Picolay (Heribert Cypionka, at least 2009–present): free, depth map only, 2.4x slower than Helicon, non-aligned by default and relatively limited in alignment skill, prone to comparatively noisy output, no retouching, single threaded but multiple instances can run in parallel, somewhat quirky user interface in English with messages in German
  • Zerene (Rik Littlefield, 2009–present): US$89–289 for free updates (10–20% holiday discount, $39 student license), 5.8x slower than Helicon, retouching brushes slightly more capable and potentially 60% cheaper than Helicon, only stacker with aligned substacking, user interface prone to unnecessary notification popups
The internet has already many blog posts and threads comparing focus stackers. If you’re unfamiliar with focus stacking and tradeoffs between depth mapping and pyramid algorithms, Carlson 2017, Berdan 2017, and Zerene’s documentation are suggested background.

All four stackers here are capable of good alignment and good image quality. So, when stacking at low magnifications, image quality differences between them tend to be minor. The relatively low number of frames at low magnification also means speed differences between stackers are of little importance. With complex subjects and macro magnifications it’s increasingly likely the optimum stacking method will vary across a subject. In such cases image quality tends to be controlled by the amount of time one’s willing to spend producing different stacks and merging them with source frames in retouching (Figure 1, 2). This favours Helicon and Zerene. As macro stacks often use hundreds to thousands of frames, performance differences between stackers become measured in hours, which favours Helicon and Picolay.

SR P1070716.JPG
Subscribe to see EXIF info for this image (if available)

Figure 1: Comparison of SOOS (straight out of stacker) results across programs and algorithms on stems of a lithophytic moss colony. I retouched this image in both Helicon and Zerene by sourcing pyramid pixels to remove the depth map halos around the moss leaves and, in this particular case, found Zerene slightly preferable at the pixel peeping level. 191 frames at 2.3x from an EL Nikkor 75 f/4 N reversed on the Panasonic 45–175 mm f/4–5.6. (Helicon’s legacy depth mapping is not included in this comparison as it is deprecated.)​

Despite the long development times of the other three stackers, only Affinity is a reasonably complete software product in the normal sense. Stackers often lack routine things like accelerator keys, keyboard shortcuts, and autosaving. Features may be incomplete or broken and end results tend to be somewhat better when a stacker is used within its original design domain. Zerene was developed for photomacrographic stacks, particularly of insects, which emphasizes management of stacking artifacts (Littlefield 2011a). Picolay was very likely developed for stereo photomicrography, primarily of microbes, where alignment is less important (Littlefield 2011b). Helicon has long been a general purpose stacker and I personally suspect Affinity’s motivation for adding focus merge was to compete with Adobe’s align and auto-merge layers in Photoshop.

Code velocity among stackers is typically low, with months between minor changes and years between major features (Cypionka, Helicon, Littlefield). Picolay is a one person part time project, Zerene is a one person company, and it would be normal software development practice for Affinity to have one developer who’s responsible for a number of things besides focus merge. However, a restricted change rate is surprising for Helicon as the company has about 10 employees and does nothing but stacking. Photographers have historically favoured Zerene for control and other users have favoured Helicon for speed (Brecko 2016). Despite the slow release rate, tradeoffs between focus stackers do change appreciably over the years. This review is partly a response to other investigations and discussions gradually becoming dated. And partly it’s an interim investigation of focus stacking’s gradual shift away from linear motion rails towards autofocus bracketing.

SR P1020002.JPG
Subscribe to see EXIF info for this image (if available)

Figure 2: SOOS colour shifts, contrast enhancement, and blown highlights in pyramid versus depth map stacks of crystalized red gum eucalyptus (Eucalyptus camaldulensis) sap. Whilst Affinity is a pyramid only stacker it appears Serif recognized pyramid stacking’s limitations and made a greater effort to control them than Helicon or Zerene. 57 frames at 1x with the Panasonic-Lecia 45 mm f/2.8 Macro-Elmarit supported by beach rocks since I hadn’t a tripod along.​

All four tools reviewed here provide different stacking workflows to their users. The distinctions are mostly driven by how work is saved.
  • Other than writing aligned files and outputting stacked images to disk, Picolay has no concept of saving. The files in a stack have to be re-opened and settings reconfigured each time Picolay is run.
  • Affinity treats stacked images as it treats any other image. After a stack completes the input images are available as retouching sources for Affinity’s clone tool but they are forgotten once an .afphoto file is saved and reopened. Affinity’s retouching model is therefore once and done. Forum posts show users have been asking Affinity to remove this limitation since focus merge was released in Affinity Photo 1.5.
  • In Helicon, a project is a set of input images, a stacking method, and one output file. Helicon is unusual in that many projects can be open simultaneously and the outputs of matching projects are made available as retouching sources. Provided retouching work in progress has been captured by resaving project files, retouching can be resumed without restacking by reopening all of the relevant projects. Each project has its own alignment and Helicon produces different alignments with different stacking parameters. This usually prevents retouching from substacks (Ingles-Le Nobel 2018) and sometimes requires just the right sequence of image loading, project creation, and project reopening be followed to enable retouching between outputs.
  • Zerene defines a project as an alignment of input images, stacking preferences, and a set of outputs. This is how projects work in most programs and all of the Picolay, Affinity, and Helicon difficulties just mentioned are avoided. However, Zerene lacks Picolay and Helicon’s adaptive depth map contrast threshold and defaults to interactively prompting the user to set a contrast threshold. In some cases this produces much smaller halos than Picolay but Helicon often betters Zerene without requiring user input and Picolay is usually competitive with if not better than Zerene. The threshold prompt can be exchanged for a fixed value (or set of fixed values) and Zerene’s batch processing run entirely without user interaction.
In my experience, these workflows and the stackers themselves are largely interchangeable for stacking at magnifications below about 0.5x (Figure 3). I do have occasional near-far ultrawide compositions where Picolay requires alignment support from other tools. The other stackers handle these on their own.

SR P1030670.JPG
Subscribe to see EXIF info for this image (if available)

Figure 3: 50% crops of a particularly difficult interlacement of Pacific yew (Taxus brevifolia) needles. All of the stackers get this reconstruction about equally wrong. In this case I would rate Picolay slightly better than the others. Needle positions and size vary somewhat between stackers due to differences in alignments.​

For more complex subjects at higher magnifications, such as moss and lycopods, Zerene and Helicon’s support of pyramids and retouching abilities are valuable. Helicon’s colour sensitive retouching partially replicates Zerene’s intelligent merging during retouching but lacks Zerene’s brightness and contrast management. Helicon’s faster selection of retouching sources and faster stacking more than compensate for this and Helicon is often less costly for nonprofit use. For strictly personal use Zerene may be cheaper but, if one’s regularly doing lots of stacking, the savings may not be worth waiting for Zerene’s slower stacking speed.

As usual for closed source software, none of the stacker authors provide details of their implementations. Causes of performance differences between stackers are therefore uncertain even though they’re implementing essentially the same algorithms. Helicon is clearly using SIMD with 16 bit colour and OpenCL so it appears likely Helicon’s greater speed is simply the result of greater optimization. I suspect this relates to choice of programming language for Picolay (Delphi) and Zerene (Java) along with lack of use of SIMD intrinsics. The size of the .zsy files Zerene generates also suggests Zerene uses single precision floating point internally. If so, it would be expected to be at most half the speed of Helicon. It appears both Affinity and Picolay make a single pass over the input frames where Helicon and Zerene both perform double passes. This is potentially an additional factor of two difference in work performed and may explain some of the differences in output images. A range of other considerations influence speed—the figures at the start of this review control for these within the authors’ decisions about feature availability—and Helicon may also be better at maintaining parallel execution efficiency (Littlefield 2014). Over the years I’ve been stacking Helicon has consistently given higher priority to performance than other stackers and improvement in its relative CPU performance has resulted in addition the to limited GPU support provided from April 2019 (Helicon 7.5.4). It’s possible other stackers may make an effort to catch up but, as of this writing, I’m not aware of any evidence suggesting this will occur.

SR P1070727.JPG
Subscribe to see EXIF info for this image (if available)

Figure 4: SOOS depth map comparison of combining overlapping autofocus brackets to extended stacking depth from 1.4 mm to 3.5 mm. Retouching of the four intermediate stacks would improve the final results (it wouldn’t, however, be SOOS). These stacks of stacks total 895 frames from four stacks of 171, 212, 266, and 246 frames individually. With Affinity and Zerene first stage alignment could be left on where, for Picolay and Helicon, it needed to be disabled for successful second stage alignment. Zerene pyramids also succeeded but second stage alignment of Helicon pyramids wasn’t entirely correct and required retouching to repair. Frames collected with an Olympus MPlanFL 5x 0.3 infinity microscope objective on a Panasonic 45–175 at 4.7x magnification.​

In addition to influencing performance, stacker configuration can affect image quality (Figure 4). Affinity provides no configuration options and is therefore cryptic. As far as I can tell, Picolay does not try to match brightness across frames where Helicon and Zerene perform brightness adjustment by default. It’s often helpful to turn this off as it creates gamma differences of several percent in constantly lit stacks and Helicon is prone to spurious warnings about variable brightness. Additionally, Picolay’s alignment ranges are not configurable and are smaller than Helicon or Zerene. Whilst Picolay improved considerably over 2019, it may still need multiple alignment passes and produce worse results on stacks which stress alignment, such as plants moving in wind or handheld captures (Figure 4, 5). Also, alignment accuracy controls stacked image quality. All four stackers provide at least some ability to review aligned frames for troubleshooting, Picolay and Zerene write aligned frames to disk, and Zerene can generate alignment reports. F9 source frame loading in Helicon is usually the quickest way to check alignment, though.

SR P1020776.JPG
Subscribe to see EXIF info for this image (if available)

Figure 5: SOOS depth maps of a Tolmie’s onion (Allium tolmiei) umbel vibrating over a ±15 pixel range in wind with rolling shutter distortions from 4k capture. When I collected these 114 frames with the Panasonic-Leica 45 mm f/2.8 in 2017 Picolay could not align the stack at all and Helicon’s results were unusuable. The best pixel peeping here is Zerene which slightly betters Helicon. This subject and lighting are better suited to depth mapping than pyramids but Affinity is still preferable to Picolay.

SR P1070359C.JPG
Subscribe to see EXIF info for this image (if available)

Figure 6: SOOS handheld focus stacks of fall colours with the Panasonic 45–175 at 117 mm (left column, 28 frames) and Panasonic 100–300 f/4–5.6 II at 300 mm (right column, 17 frames). For the pine on the left Helicon is a slightly more effective than Zerene. On the right Picolay produces somewhat better pixel peeping than Helicon despite the difficult alignment. Lens OIS on, non-IBIS body, Affinity not tested because its 10 day trial period expired a few hours before running these stacks.​

In general, as noted in the introduction, choice of a particularly stacker is usually not critical since differences in stackers’ capabilities are mostly minor. Since all four stackers are either free or have trial periods, my suggestion is the approach taken here of investigating all of them to see which combinations are most effective for one’s workflows. If you’re reading this because you’re curious to try off camera stacking and have a Windows machine Picolay may be the most useful starting point. It’s a bit more manual than the other stackers, which encourages thinking through what one’s doing a bit more carefully, and there’s no time pressure in learning to use it. If you have already Affinity or have other reasons to purchase Affinity the main things it’s missing are depth mapping, retouching, and stacking speed. This may be fine. If stacking’s a primary purpose, however, I would select Picolay, Helicon, or Zerene over Affinity. If I had to choose between a Zerene personal or Helicon lite license I’d probably go with Zerene. Helicon pro versus Zerene prosumer isn’t a choice I like but I’d favour Helicon for most things. I do enough stacking to license both Helicon and Zerene.

Personally, I stack primarily macro and photomacrographic images with 200–300 frames per stack. I routinely stack thousands of frames in a day and assemble around 15,000 frames on busy days. Helicon and Picolay are my primary stackers because Zerene and Affinity are too slow to handle this workload. This is unfortunate as Zerene is the most carefully thought out and best designed stacking software currently available and it’s not uncommon I use Zerene as a backup for images where Helicon or Picolay wasn’t entirely successful. As such, I don’t feel I can recommend any one stacker in this review. Rather, it’s probably best to understand the differences between them and be able to select whichever stacker is the best tool for the image of the moment.

SR P1070760.jpg
Subscribe to see EXIF info for this image (if available)

Figure 7: An example of stacker diversity: this moss colony is best suited to pyramids but Affinity somehow lost track of the two main stems and Helicon was being cranky enough about allowing a depth map to retouch pyramids I ran the stack in Zerene as well. Despite being a depth map, Picolay’s output would be a better starting point for retouching than Helicon or Zerene pyramids if cross output retouching wasn’t available. Retouched image is cross-posted with a larger size here.​
 
Last edited:

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,385
Addendum: Stacker Workarounds and Integration Techniques
Since the conclusion of this review is it’s most useful to be able to combine stackers I feel I should include some how to information that’s not usually present in reviews. A limitation of using multiple stackers is none of the stackers considered above can interchange data directly. So, by default, they all work independently as you can’t, for example, open a Helicon project in Zerene or a Zerene project in Helicon the way you could with a lot of other kinds of files. Fortunately, there are a few ways to mitigate this.
  • Since both Picolay and Zerene write aligned frames to disk other stackers can pick up their alignments by opening the frames. For example, if Picolay’s alignment is failing one can align in Zerene and go back to depth mapping in Picolay.
  • As noted above, Helicon has a tendency to produce slightly different alignments with different stacking parameters. A workaround when doing stacks of stacks is to add all the Helicon outputs to a Zerene project, jointly align them (Stack ⇢ Align All Frames), and do the second stage stacking and retouching in Zerene. Since second stage stacks have around 1% as many frames as first stage stacking Zerene’s slow stacking speed isn’t significant. A similar approach of giving Zerene Picolay’s pysharp files also allows use of Picolay as a more performant depth mapping frontend for Zerene. This idea generalizes to any second stage stacker but I’ve found Helicon to be somewhat less successful in second stage alignment than Zerene. Picolay isn’t particularly attractive in this role as it lacks retouching.
  • Zerene will happily treat other stackers’ outputs as its own. It’s easy to set this up. Create a suitable Zerene project, copy it, replace Zerene’s outputs with the other ones, and open the project in Zerene. If one knows XML it’s also easy to modify the OutputImages element in Zerene’s .zsj project file to add or replace outputs. Source and cross output retouching work as usual when all the files are aligned and have the same pixel sizes, so it’s useful to turn off automatic cropping in Helicon.
I’ve had something of a love-hate relationship with Helicon since I first used it. It’s so fast. And so buggy. So it gets its own special section here. As of Helicon 7.6.1, my most commonly employed workarounds are
  • Avoiding depth map and pyramid alignments which are identical except for a scaling factor. Like Zerene, Helicon looks at both ends of a stack and makes a decision about which stacking direction will work best. Unlike Zerene, Helicon doesn’t have an option to turn this off and Helicon manages to introduce inter-stack alignment dependencies even though each project has its own distinct alignment. As of 7.6.1, the most common trouble point is when Helicon decides to reverse the source frame order. The first time it does this the first frame loaded, which becomes the last frame of the stack, gets a scale factor of 1.0. If subsequent stacking operations are done it’s instead the last frame loaded—now the first frame of the reversed stack—which has scale 1.0. So it becomes necessary for the user to pay attention to the frame order shown and not initiate stacking from reversed frames. Mostly this means reopening all the images again and then clicking render. Instead of just clicking render on the already loaded images like the user interface encourages you to do. This problem is easiest to spot if you’ve turned of Helicon’s autocropping but, since Helicon still tends to autocrop in its user interface, I’ve often found the best check is to compare outputs directly in GIMP or some other tool.
  • Even if you do everything right by the above it’s common for Helicon to still not allow cross output retouching until you restart Helicon and reopen both projects. After which it happily links up the exact same outputs from the exact same projects that it couldn’t link up just a few seconds before. Why, Helicon? Why?
  • Helicon implements retouching undo by undoing every retouch you’ve done since the project was last saved and then replaying all them except the one you just undid. I’ve never suffered all the way through it but, on retouch intensive images, my estimate is it would take Helicon over a minute to perform a single undo by the time I’d worked all the way across an image. The workaround is to commit retouches by saving the project whenever Helicon starts getting slow about undo. Given Helicon’s flakiness, frequent saving is probably a good idea anyway. Since I usually retouch in a methodical boustrophedon I make a point of saving when I’m halfway across an image. Or when I’ve gotten another third or quarter of the way if it’s going slowly.
  • All of the frames in all of the stacks you’ve run stay in memory by default. Helicon has an upper limit to its memory consumption (Edit ⇢ Preferences ⇢ Performance ⇢ Memory cache limit) but, at least on Windows, it seems to look at the amount of virtual memory rather than the amount of physical RAM that’s installed. As a result, it’s likely Helicon will initiate swapping to disk and cause poor performance instead of shedding memory. A partial workaround is just to turn down the limit but, since it’s only adjustable in 10% increments and can’t consider the amount of memory being used by other programs, somewhat awkward compromises may result. So I often end up just monitoring system memory pressure with Task Manager and restarting Helicon once it’s gotten too big. With my current hardware the practical limit is usually around 1000 4k frames, which consume about 6.6 GB of RAM, so this is a routine issue when I’m using Helicon in semi-batch mode and queuing up lots of stacks.
Picolay and Zerene both avoid all of these problems, Zerene entirely by better software design. Affinity 1.7.3 doesn’t have these troubles either, but that’s because of the small size of its feature set.
 

retiredfromlife

Mu-43 Hall of Famer
Joined
May 15, 2016
Messages
3,794
Location
Sydney, Australia
Thanks for the very in depth article, i will no doubt come back to this a few times as stacking is somthing i would like to try one day, but my understanding is rather lacking at this stage of how the software works. This is apart from trying to work out how to hand hold a camera to get stacks of insects when i have trouble hand held single shots
 

Stanga

Mu-43 All-Pro
Joined
Oct 16, 2016
Messages
1,029
A few things to note about Helicon. Version 7 is far better in alignment than 6. I also like the option on the right hand side of the interface where you can enable or disable any loaded image quite easily and run the stack again to see which image exactly is causing a particular error in a stack.
An i7 processor and SSD is preferred when working with large amount of images.
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,385
This is apart from trying to work out how to hand hold a camera to get stacks of insects when I have trouble hand held single shots.
I think @gardenersassistant does some of this kind of stacking, so when you're ready you might try searching photomacrography.net and maybe DPR for that user name.

I also like the option on the right hand side of the interface where you can enable or disable any loaded image quite easily and run the stack again to see which image exactly is causing a particular error in a stack.
I used this method with older versions of Helicon but haven't needed it recently. Picolay and Zerene can also be used this way but I've found it rare there's need. Unfortunately, Picolay and Zerene aren't any better than Helicon about implementing normal user interface functionality which would make turning frames on and off efficient. Helicon's faster to show images than Zerene (especially if Zerene's aligned image cache isn't populated) but is still slow for reviewing if frames aren't already in memory. Picolay and Affinity load all images when they're added to the stack, which exchanges one major wait for subsequent prompt access. I find this approach preferable to Zerene's slowness and, in some ways, Helicon as well.

I'm much more likely to check frames by playing post focus video. It's a couple orders of magnitude faster than going through a stacker and catches motion problems or compositions less inspiring than they looked in camera before time is spent on source frame extraction, frame trimming, and stacking. For checking once frames are extracted, I usually use Irfran (though any other performant viewer which doesn't skip frames should be fine) that's also faster than reviewing in stacker or waiting or watching during stacking.

An i7 processor and SSD is preferred when working with large amount of images.
I think SSDs are preferred for everything. Except sometimes price. ;) Not sure I follow the reasoning behind an i7, though. Helicon is fast enough on my older i5 that Amdahl's law indicates for improving stack capture, SD card copying, frame extraction and trimming, and especially retouching (first in Helicon or Zerene and then usually again in GIMP) over faster hardware. Similarly, a Helicon license is probably a better investment than applying more compute power to Affinity or Zerene. And, if the stacking itself is a limiting factor, Helicon's benchmarks (linked early in the first post of the thread) are several times faster on GPUs that are perhaps half the price of an i7.
 
Last edited:

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,385
It would have been helpful, as a baseline, to include an Adobe PS example.
Hi, Helicon and Zerene are usually taken as baselines for stacking ability, though I would argue for Picolay as a distinct, noncommercial baseline. Photoshop probably isn't something one purchases (or not) based on its stacking abilities and its stacking is relatively well described elsewhere, including in some of the reference links provided in the first part of the first post of this thread. I considered including a trial of Photoshop here anyway but Adobe's pricing isn't competitive with any of the other stackers. So putting even more hours of work into this volunteer effort in support of someone else's website in order to incorporate a fifth set of stacks isn't something that happened. Photoshop's exclusion is also partly due to Adobe's one week trial rather than 10 days (Affinity) or 30 days (Helicon and Zerene), which makes Adobe uncompetitive on a trial basis too. ;)

Pragmatic considerations aside, I agree it's kind of an interesting question, perhaps particularly for wind motion at the moment. To uplevel a bit, something that's missing from the focus stacker assessment is a set of open benchmarks. With some collaboration between tool licensees that wouldn't be difficult to change but it's not something I anticipate making a priority to coordinate as there are quite a few other things I'd like to pursue. If it's an idea someone else wants to pick up I could provide some support, though.
 
Last edited:

Bushboy

Mu-43 All-Pro
Joined
Apr 22, 2018
Messages
1,027
Location
Aotearoa
Real Name
Charlie
Interestingly, I bought, affinity, solely, for the focus stacking program.
I did not realise that there were other alternatives. However, I am glad I got it, because it is much more than I bargained for!
Well done on a in depth review Archterex, very thorough. As usual most of it flew over the top of my head. 15,000 frames.... !
300 shot stacks! O M G!
 

Stanga

Mu-43 All-Pro
Joined
Oct 16, 2016
Messages
1,029
Oddly enough, I got Affinity for it's stacking feature as well... I wanted to take shots of locations in London that are however crawling with people most of the time. I found out that Affinity can easily remove the moving crowd if you have enough base images. I just couldn't get the hang of doing that in any of the other programs I tried.
 

peterwgallagher

Mu-43 Rookie
Joined
Jun 7, 2017
Messages
12
I heartily recommend Zerene Stacker: not only for the quality of the results (which is most important) but also for the fantastic support Rik Littlefield, the developer, CEO and bottle-washer at Zerene offers. In 2017, Rik spent many hours fixing a Mac problem for me, including making several trial versions to track down an obscure bug. He was successful in the end. I'm still impressed and still grateful.
 

robcee

Mu-43 Top Veteran
Joined
Jan 10, 2016
Messages
566
Location
New Brunswick, Canada
Real Name
Rob Campbell
Awesome posts. Thanks for these. I plan on coming back and re-reading.

I’ve used Zerene, but only briefly. I tried evaluating it as an astrophotography tool, but didn’t spend a lot of time with it. I should revisit that.
 
Links on this page may be to our affiliates. Sales through affiliate links may benefit this site.
Mu-43 is a fan site and not associated with Olympus, Panasonic, or other manufacturers mentioned on this site.
Forum post reactions by Twemoji: https://github.com/twitter/twemoji
Copyright © 2009-2019 Amin Forums, LLC
Top Bottom