A forum to ask questions, post setups, and generally discuss anything having to do with photomacrography and photomicroscopy.

Moderators: ChrisR, Chris S., Pau, rjlittlefield

Posts: 1005
Joined: Tue Sep 06, 2011 7:39 am

Re: Sub-stacks

Post by johan »

pierre wrote:For information, the last Version of Helicon Focus 6.2.2 now includes the capability of sub-stacking.
Sort of - no settable overlap between slabs though. Ie you can divide a stack of 100 into 1-10, 10-20, 20-30 etc but you can't generate a 1-10, 5-15, 10-20 sequence :(
My site, a learning site. Your comments and input there would be gratefully appreciated.

Site Admin
Posts: 20987
Joined: Tue Aug 01, 2006 8:34 am
Location: Richland, Washington State, USA

Post by rjlittlefield »

It's more different than just no overlap. As far as I can tell each of the splits gets processed independently, with no attempt to maintain alignment between different splits. This contrasts with slabbing in Zerene Stacker, where all the source images get aligned with each other in the usual way and then the substacks get computed using that same alignment.

I think the Helicon "split stack" feature is actually intended to handle things like time lapse stacking, such as described at ... p?p=125814.

It can be also used for slabbing, by letting the program realign the outputs from the various slabs (splits).

The risk then is that the alignment between slabs may be a little less accurate than the alignment between individual frames would have been, due to the much larger difference in appearance of adjacent slab outputs compared to adjacent source inputs.

I don't know how to predict whether that would be an issue with any particular stack. In the two test stacks I tried, it was not a problem with one of them, but in the other one a small bit of fly's antennae suffered a clean break at a slab boundary. There were also some generally interesting differences in geometry. Here's an animation that just alternates between two images, both produced by Helicon from the same stack, but one processed by a single run of 167 images and the other by splitting into groups of 10 and then combining the resulting 17 partial outputs. Both runs used exactly the same alignment settings (auto-adjust everything), so what you're seeing here is a difference caused by order of alignment, 1 through 167 consecutively in one case, versus (1:10), (11:20), (21:30), (31:40), and so on in the other.



Posts: 278
Joined: Sun Jan 27, 2013 10:29 am
Location: Madrid - Spain

Post by ofarcis »

Respect this comment of Rik, you can see more details in high image resolution of sub-stacks experiments here: ... a3f420b36e

You can see the high resolution imagen of 100 or 400 images stack and the use of sub-stacks to compare. Can press zoom in images to see with all details.

I don't aprecciate differences with Zerene but some important differences with Helicon. Even I think that Zerene works more better with insect that Helicon!!!

For example for solid objects like minerals, this problem not is very important because normally the minerals haven't hairs. In this case, the used of method B of Helicon is better than Zerene. For this reason, depends of elements that take a picture.

The unique difference of use the sub-stacks or not is the total time to process sub-stacks. In zerene need more time that a normal stack, in Helicon need less time.

Regards, Oscar.

Posts: 266
Joined: Mon Jan 04, 2010 12:37 pm
Location: France, Var, Toulon


Post by pierre »

Even if I found it useful, Rik & Johan are right there: since HF does not manage the overlapping part yet, it has to be considered has a different way of sub-stacking.


Posts: 1005
Joined: Tue Sep 06, 2011 7:39 am

Post by johan »

Rik - yes, and the outcome is the same when doing the Helicon in-stack slab workaround (making an in-set slab by picking up a subimage range together with the first in the range) - the resulting slabs are just a slab which isn't aligned or scaled to a completed stack. The scale is really the showstopper - you could pick it up with 'use different output source' and use the groovy clone brush to compensate and put it where it should be, but when the outputs render the elements that you're trying to brush in, in different sizes, that doesn't work so well...
My site, a learning site. Your comments and input there would be gratefully appreciated.

Post Reply Previous topicNext topic