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

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
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, basic retouching that's a bit difficult to discover (see YouTube tutorial), 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 more capable 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, effective 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.​

Edit 2020-09: link Picolay's YouTube channel launched in August 2020.
 
Last edited:

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
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 couple 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.
  • 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.4, my most commonly employed workarounds are
  • Arranging my plans so I can complete a stack and its retouching while leaving Helicon running. In an utterly monumental design fail, prior to Helicon 7.6.3 could include references to temporary output files its projects. Since those files are deleted when Helicon exits, the project becomes unusable if you make the mistake of saving them after beginning cross output retouching. 7.6.3 adds checks to prevent this, which at least avoids corrupted project files, but also means you can't save after beginning the most common form of retouching.
  • 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. Once undo gets slow it can be faster just to rebuild an undesirably retouched area from the relevant source frames.
  • 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. Whenever possible, I try to structure my workflow to complete one or maybe two stacks at a time as a workaround.
Zerene avoids these problem by better software design. Picolay and Affinity 1.7.3 don’t have these troubles either but that’s because of the small size of their feature sets.

Edit 2020-09: updates for Helicon 7.6.4
 
Last edited:

retiredfromlife

Mu-43 Hall of Famer
Joined
May 15, 2016
Messages
4,538
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,360
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,557
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:

Jrsforums

Mu-43 Rookie
Joined
Mar 13, 2019
Messages
23
Nice write up and examples. It would have been helpful, as a baseline, to include an Adobe PS example.
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
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 focus stacker assessment is a set of open benchmarks. With some collaboration between tool licensees that wouldn't be difficult to change. However, 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,510
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,360
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 Regular
Joined
Jun 7, 2017
Messages
41
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
671
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.
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
Quick retest as Helicon, Picolay, and Zerene have all released incremental updates in the last eight months. This a 72 stack of a lodgepole (Pinus contorta) seedling, again G7 4k post focus and with Panasonic-Leica 45 f/2.8 macro. I find conifers often make good test subjects since all stackers have a hard time correctly reconstructing the depth order of needles, they don't require magnifications greater than 1x, and most of us can probably find one or some similar vegetation to test on without too much difficulty. I didn't use diffusion, so reflection off the leaves' cuticles creates some highlight management challenges. Also didn't retest Affinity as I didn't see anything in the release notes up to 1.8.4 (2020-08-03) about stacking changes.

Zoom to fit SOOS (straight out of stacker) comparison. As in previous tests, Helicon has the lowest levels of depth halo and pyramid highlight bloom and Picolay the greatest amount of haloing.
P1080642 45 comparison fit.jpg
Subscribe to see EXIF info for this image (if available)


100% crop SOOS comparison. As expected, all of these outputs require retouching due to depth halos and pyramid detail bleed through. I usually retouch pyramid edges on to depth SOOS and deal with remaining artifacts in GIMP and would apply that workflow to this image. Depending on the specific detail any one of the three stackers might be best but, overall, retouching from Helicon is probably the least work and I'd personally rate Helicon's handling of blown highlights as slightly more natural looking (EDIT: more about this in the following discussion).
Subscribe to see EXIF info for this image (if available)
 
Last edited:

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
I can't help but notice the striking lack of textural detail even aside from highlights in that [...] pyramid crop...
The contrast enhancement of pyramid stacking is why pyramid stacks are usually done with diffusion, often quite heavy diffusion and multiple light sources, and why I was careful to note it's an undiffused test stack in my previous post. The eucalyptus sap up thread for another undiffused example. Overall, I would say Helicon's a bit better than Zerene (or Affinity) there, too, and it's my experience that little bit of extra tolerance can be helpful in the field. It gives a little more latitude for using sanded P95 acrylic if 2447 is looking overdiffused or if lighting for shutter speed is an issue.

Here's some SOOS crops from the other side of the stem.
Subscribe to see EXIF info for this image (if available)


To the extent it reduces contrast, depth mapping halos also benefit from diffusion. However, haloing is more driven by the color difference across an edge, so light objects on dark backgrounds halo even when well diffused. As with pyramid blooming, it's a property of the algorithm and all stackers behave similarly (as noted above, Zerene often does a bit worse even with it's interactive threshold setting). Here's a SOOS example of depth haloing from another stack that didn't pursue due to the combination of not underexposing quite enough for the black trunk and the amount of retouching that was going to be involved.
P1080021 web unedited.jpg
Subscribe to see EXIF info for this image (if available)
 
Last edited:

junkyardsparkle

haunted scrap heap
Joined
Nov 17, 2016
Messages
2,481
Location
Brennschluss
Here's some crops from the other side of the stem.
Again, it looks to me almost as if the Helicon version was subjected to aggresive denoising of the midtones, compared to the Zerene copy. Mind you, I'm not asserting that this means the Zerene version is "better" for any kind of normal viewing purposes... I just find the difference surprising (I've never actually used Helicon). Interesting stuff. :D
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
I just find the difference surprising (I've never actually used Helicon).
That's partially on me and partially the stackers. Helicon provides more granular control over radius and smoothing than the switch for Zerene's grit suppression. I'd tested 7.6.1 and concluded Helicon's defaults (radius = 8, smoothing = 4 for depth mapping and just radius = 4 for pyramids) looked close to optimal to me for 4k post focus (Helicon's suggestion is to start with the 3-5 range). However, I just checked and Helicon was running radius = 8 pyramids for the stacks I'd posted. I've reset to defaults and updated both sets of pyramid crops above to radius 4 but, in terms of picking up the stomatal rows and such here, some 300% pixel peeping suggests to me the closest Helicon equivalent to Zerene is probably around radius 1.5. I don't have a fresh Pinus contorta sample at the moment but, based on my experience viewing stomata through a 10x hand lens, Zerene looks a bit noisy to me. My subjective assessment for the moment is radius 3 or 4 is probably more honest about detail.

Another factor is the alignment processes aren't identical, so some difference in pixel level calculations exists. I suspect this drives some of difference in the colour shifts pyramid stacking introduces and, in this case, Helicon's output is 3% smaller (3230 x 2422 versus 3328 x 2496 pixels) with a less steep perspective than Zerene on the needles I've checked so far. So, in addition to using less noise filtering, Zerene can present more apparent stomatal detail just because it's making the stomata a little bigger and tending to display them from a slightly more dramatic perspective. Rik has stated Zerene uses frame to frame least squares on highlights for alignment but I'm not sure Helicon's ever disclosed what they do.
 

junkyardsparkle

haunted scrap heap
Joined
Nov 17, 2016
Messages
2,481
Location
Brennschluss
I don't have a fresh Pinus contorta sample at the moment but, based on my experience viewing stomata through a 10x hand lens, Zerene looks a bit noisy to me. My subjective assessment for the moment is radius 3 or 4 is probably more honest about detail.
That makes sense... I suppose if I ever get around to working with Zerene again, it would make sense to try some different degrees of heavier-handed denoise than I normally would at the RAW processing stage (probably would have already realized that if I did more of this kind of thing).
Another factor is the alignment processes aren't identical, so some difference in pixel level calculations exists
Yeah, this is where I would intuitively expect to see some differences... maybe more than are actually apparent in your comparisons. I guess improvements on all sides tends towards convergence here...
 

archaeopteryx

Gambian sidling bush
Joined
Feb 25, 2017
Messages
1,557
I guess improvements on all sides tends towards convergence here...
Broadly, yes. However, it wouldn't surprise me if Helicon, Picolay, and Zerene all occupy somewhat different local optima for their specific alignment algorithms. It's tempting to describe this as one of many minor differences between stackers where the basic thing is don't worry about the details, just grab a stacker and get it done. And, pragmatically, I think that's pretty valid in that it would take some pretty specialized tools and a fair amount of effort to identify which alignment algorithm most accurately recontructs telecentric perspectives across a range of endocentric and hypercentric inputs from single and coupled lenses.

One thing which makes me hesitate with this, though, is alignment isn't a done thing. All three stackers have improved substantially since I started working with them and will now stack things they couldn't align in 2016, 2017, 2018, and even 2019. My personal experiences with sending Katherine (Helicon) and Heribert (Picolay) problematic stacks for investigation have been quite positive. Rik (Zerene) is also well regarded for being responsive but as, I don't use Zerene as much, I haven't personally sent him stuff. While don't have speific insight into how Affinity or Photoshop compare I've low expectations for Adobe and Serif's lack of investment in stacking seems to signal they view it more as a checkbox compete with Adobe.

The other comment I would make is Picolay is historically the most photomicrographically oriented stacker and, while Heribert's been moving more into photomacrography and pushing Picolay's alignment since he retired, Picolay's alignment is more clearly distinct than Helicon and Zerene are from each other. Rik wrote Zerene because he wanted a better photomacrographic stacker than what Helicon offered 16 or so years ago and that shows to some degree as well. Zerene's user base is probably dominated by studio photomacrographic stackers and it doesn't look to me like that generates the same demand for versatility as Helicon gets. Personally, what I notice is Helicon will handle subject rotation and sway from wind motion that Picolay has a hard time with and Zerene isn't as successful with.

I suppose if I ever get around to working with Zerene again, it would make sense to try some different degrees of heavier-handed denoise than I normally would at the RAW processing stage
As at least an investigation thing, probably. Both depth mapping and pyramiding generate noise. Helicon, Picolay, and Zerene's developers all definitely know this and implement mitigations. While there's some discussion of raw setups for stacking over at photomacrography.net I'm not sure anyone's looked at the noise budget closely enough for there to be much of an understanding of how input noise relates to stacker output noise. To the extent there's gain on existing noise denoise in raw conversion will help but I strongly suspect there's a nontrivial additive component which varies noticeably from stacker to stacker.

I think the main reason this hasn't been more explored is most stacking happens under studio lighting at base ISO and even that user base is limited. Field stacking where higher ISOs are more likely was a very niche, battery powered rail thing until Olympus introduced autofocus bracketing in September 2015 (E-M1 and E-M5 II firmware 4.0) followed by Panasonic in November 2015 (G7 and GX8 firmware 2.0). Nikon started support in September 2017 (D850 release), Fuji in June 2018 (XT-2 firmware 4.10, X-H1 firmware 1.10), and Canon in March 2019 (RP release) but Olympus and Panasonic are still the only ones with general availability. Nikon provides autofocus bracketing on the Z6 and Z7 but the Z5 didn't get it. Fuji's included it on the XT-30 as well as the XT-3, XT-4, X-Pro3, and GFX but so far as I know not in any of their less expensive models. The 90D, M6 II, and R shipped with focus bracketing last September and October and then the R5 and R6 last month but Canon's EF lens support is restricted.

It's been a few months since I last looked but I'm aware of three people who are regularly collecting deep stacks in the field. All of us are Panasonic post focus based and using lighting to regularly make the 1/30 shutter speed requirement. So, even though we're the people who'd probably benefit the most from stacking at higher ISOs, we're usually at base ISO or close to it and raw isn't part of our toolchains.
 

junkyardsparkle

haunted scrap heap
Joined
Nov 17, 2016
Messages
2,481
Location
Brennschluss
Interesting insights... nice of you to keep up with the comparisons despite seemingly having a pretty good idea which ones work best for your purposes. :D
To the extent there's gain on existing noise denoise in raw conversion will help but I strongly suspect there's a nontrivial additive component which varies noticeably from stacker to stacker.
Huh... I was laboring under the delusion that the noise was "generated" only by digging up any tiny amount that was latent in the sources... I'll have to look further into that at some point.
So, even though we're the people who'd probably benefit the most from stacking at higher ISOs, we're usually at base ISO or close to it and raw isn't part of our toolchains.
Welp, good to know there's a shadowy corner left to explore if I ever get inspired...
 
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