On the performance of Zerene Stacker

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

Moderators: rjlittlefield, ChrisR, Chris S., Pau

NikonUser
Posts: 2693
Joined: Thu Sep 04, 2008 2:03 am
Location: southern New Brunswick, Canada

On the performance of Zerene Stacker

Post by NikonUser »

A few years back I upgraded my Dell XPS with a Pentium 4 (bought in 2005) to a HP laptop with an Intel i7 and 6GB RAM.
The XPS took a long long time to process Zerene stacks. The HP was a lot faster but some stacks still took up to 40 minutes to process.
Only knowing that more RAM is "good" and being bothered by a slow computer I recently upgraded to a fast computer with Windows 8 and 32GB RAM.
Zerene stacks are now lightning fast, so far all have taken less than 1 minute to process.

Admin edit (RJL, 1/8/2016): to change the title. It was "In praise of 32 GB RAM", but the thread quickly morphed far away from that aspect.
NU.
student of entomology
Quote – Holmes on ‘Entomology’
” I suppose you are an entomologist ? “
” Not quite so ambitious as that, sir. I should like to put my eyes on the individual entitled to that name.
No man can be truly called an entomologist,
sir; the subject is too vast for any single human intelligence to grasp.”
Oliver Wendell Holmes, Sr
The Poet at the Breakfast Table.

Nikon camera, lenses and objectives
Olympus microscope and objectives

Chris S.
Site Admin
Posts: 4037
Joined: Sun Apr 05, 2009 9:55 pm
Location: Ohio, USA

Re: In praise of 32GB RAM

Post by Chris S. »

NU, hurray that your stacks are now moving "lightning fast" with your new computer. :D Yay!

I would suggest, though, that a forty-fold improvement in stacking speed was likely brought about not by the memory increase alone, nor even primarily.

In your recent computer upgrade--if I understand correctly--you changed not only the amount of RAM, but also moved to a faster processor, new motherboard, new operating system, and perhaps other things. And of course, in changing computers, you also may have left behind any parasitic software or other errors that might have been slowing down your old computer.

My own stacking computer, which I built, also has 32GB of RAM, but Zerene Stacker only uses about 3GB of it. Since I recently had the privilege of building a new, extremely high-performance computer for Rik Littlefield (who of course wrote and supports Zerene Stacker), we discussed Zerene Stacker's use of RAM. If I understand correctly, ideal allocation of RAM to Zerene Stacker depends largely on the size of the input image files--and beyond a certain allocation, additional RAM dedicated to Zerene Stacker does little or no additional good. (This said, Rik is always improving Zerene Stacker, and these details may change.)

So NU, while I'm delighted to hear that your computing experience has greatly improved, I'd be cautious in implying to other members of the PMN community that simply adding more RAM will greatly increase their stacking speed. I'd expect that large time savings will not be typical for most such users.

Cheers,

--Chris

--edited typos
Last edited by Chris S. on Tue Feb 11, 2014 12:27 am, edited 1 time in total.

dolmadis
Posts: 897
Joined: Wed Dec 07, 2011 1:51 pm
Location: UK

Post by dolmadis »

Hi Chris

Could you give us some idea of what spec you might suggest for stacking processing?

Thanks


John

NikonUser
Posts: 2693
Joined: Thu Sep 04, 2008 2:03 am
Location: southern New Brunswick, Canada

Post by NikonUser »

Chris: Thanks, fair comment.

Title should read "In praise of 32GB RAM coupled with a (maybe) powerful computer"

Knowing nothing useful about computers I simply bought what appeared to be a fast system from Dell.

FWIW:
32GB Quad Channel DDR3 at 1600MHz
Intel Core i7-4820K Proc (4 cores, 10MB Cache, Overclocked up to 4.2 GHz w/Turbo Boost)
NVIDIA GeForce GTX 770 with 2GB GDDR5
Windows 8
Plus other stuff that may/may not have any effect on performance?

Looks as though Zerene is using 3GB RAM.

ID-ing bugs is so much simpler.
NU.
student of entomology
Quote – Holmes on ‘Entomology’
” I suppose you are an entomologist ? “
” Not quite so ambitious as that, sir. I should like to put my eyes on the individual entitled to that name.
No man can be truly called an entomologist,
sir; the subject is too vast for any single human intelligence to grasp.”
Oliver Wendell Holmes, Sr
The Poet at the Breakfast Table.

Nikon camera, lenses and objectives
Olympus microscope and objectives

ChrisR
Site Admin
Posts: 8662
Joined: Sat Mar 14, 2009 3:58 am
Location: Near London, UK

Post by ChrisR »

I wonder if we can usefully quote an approximate per-image stacking time, to make comparisons?

When I changed from an old Pentium 2 running XP with 3GM ram to a 2.7GB i7 Laptop with I think 8GM ram, (18MP fine jpegs) it went from about 60 seconds to 3 seconds.

Olympusman
Posts: 5090
Joined: Sun Jan 15, 2012 12:31 pm

More RAM is good

Post by Olympusman »

I have a stand alone computer (no Internet) dedicated solely to stacking and imaging with loads of RAM and a faster microprocessor and it made a huge diffeence over my older computer. Before I got Zerene I was using Combine ZP and a stack of 30+ images could take half an hour or more. The problem was that the computer didn't have enough RAM and was going to the hard disk drive to use virtual RAM. I could hear the HDD cycling all during the stack. Plus, I was (and still do) save the stack as a TIFF file, so the stacking process was dealing with a huge file. Not very healthy for a HDD. Those of you have SSD drives must be in heaven.
Michael Reese Much FRMS EMS Bethlehem, Pennsylvania, USA

TheLostVertex
Posts: 317
Joined: Thu Sep 22, 2011 9:55 am
Location: Florida

Post by TheLostVertex »

ChrisR wrote:I wonder if we can usefully quote an approximate per-image stacking time, to make comparisons?
We would likely need to have the same images to perform the test for it to be accurate. I imagine image dimensions, image bit depth, number of images int he stack, and maybe even image format play a role in the speed. I also know from testing that the option "use external tiff reader" has a small but measurable impact on stack time on mac(only a couple seconds difference in 30 image test stack I was using).

But it would be interesting to see some performance stats. I wonder if Rik knows off hand what the most limiting factors are to stack performance. I have a cpu usage graph that I notice certain patterns of cpu usage during different stages of stacking(alignment, building depthmap, constructing dmap image, etc). My gut reaction is that an SSD for storage of images to be stacked and temp project storage would make a noticeable improvement on my system.

NikonUser
Posts: 2693
Joined: Thu Sep 04, 2008 2:03 am
Location: southern New Brunswick, Canada

Post by NikonUser »

I just ran a stack of 51 images of an ant's face on my new system, specs. above.
Single uncropped image below, before stacking I cropped out the empty space on the left.
Nikon D90, DX sensor, Nikon 10x objective, 51 NEF images=493MB (after cropping)
Adobe Camera RAW took 108 seconds to convert these to TIFFS, 51 TIFFS=1.45GB
ZS PMax took 93 seconds to process the 51 TIFFS to give me PMax and UDR images.
Image
NU14-02-10
NU.
student of entomology
Quote – Holmes on ‘Entomology’
” I suppose you are an entomologist ? “
” Not quite so ambitious as that, sir. I should like to put my eyes on the individual entitled to that name.
No man can be truly called an entomologist,
sir; the subject is too vast for any single human intelligence to grasp.”
Oliver Wendell Holmes, Sr
The Poet at the Breakfast Table.

Nikon camera, lenses and objectives
Olympus microscope and objectives

Chris S.
Site Admin
Posts: 4037
Joined: Sun Apr 05, 2009 9:55 pm
Location: Ohio, USA

Post by Chris S. »

dolmadis wrote:Could you give us some idea of what spec you might suggest for stacking processing?
I’ll be happy to do that, John. But let me take a little time to write it up, and I’ll put it in a thread of its own.
NikonUser wrote:ID-ing bugs is so much simpler.
Ha! :D But it sounds as if you acquired a pretty nice system, NU.
TheLostVertex wrote: My gut reaction is that an SSD for storage of images to be stacked and temp project storage would make a noticeable improvement on my system.
Steven, I also thought this might be the case, but a recent test I ran indicated otherwise. Using an SSD as the image source and storage drive for Zerene Stacker saved only about 5 seconds—total—during stacks of 603 images. So the difference was measurable, but trivial.

Details: This was with one Samsung 840 Pro Series SSD for the operating system and applications, and either a second Samsung 840 Pro Series SSD or a Western Digital Black (high-quality standard hard drive) as the source and storage drive for Zerene Stacker.

I do strongly recommend using an SSD for the operating system and applications. And data and certain user directories should be placed on a second drive—physical if possible, logical if not; this makes for much easier backups and--especially--recoveries. It's probably also worth mentioning that some other photographic tasks would probably see much more benefit from the use of an SSD for temporary files—a Photoshop scratch disk is a likely candidate.

--Chris

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

Post by rjlittlefield »

"What affects performance?" is a really messy question.

Let's start with some fairly clear aspects.

1. Paging is always bad. If your disk is rattling ferociously and your cpu utilization is below 15%, then your computer is thrashing and you need either more memory or a better allocation. When people report atrocious performance, this is usually the problem.

2. The total time to process a stack is almost directly proportional to the total number of pixels handled: Width * Height * NumberOfImages. (Hint: if you're shooting in raw, then cropping in conversion like NikonUser describes would be a really good idea.)

3. Within certain thresholds, the amount of memory allocated to Zerene Stacker itself doesn't make much difference. Example: I just now ran a set of 20 images, 12 megapixels each, in memory ranging from 975 MB up to 10,000 MB. The times varied only between 23.3 and 25.2 seconds. A good allocation is 100-200 megabytes per megapixel. This will give enough memory for Zerene Stacker to run efficiently, while reducing the odds that it will conflict with other programs that also need memory. Sometimes you can get by with less (as in this example), but it's taking a risk. When allocating more, the key thing is to avoid contention with other programs. There's currently no advantage in giving Zerene Stacker huge amounts of memory, hence the suggested upper bound of 200 megabytes per megapixel.

4. If performance matters, then turn off functionality you don't care about. This applies especially to "Cache unaligned screen images" and "Cache aligned screen images", found at Options > Preferences > Caching & Undo. If you seldom or never want to detect movement by playing a stack as if it were a filmstrip, then remove the checkmark on "Cache unaligned screen images". If you don't plan on retouching from source or you're prepared for frame selection to be sluggish, then remove the checkmark on "Cache aligned screen images". In one test I ran just now, un-checking both options reduced stack processing time from 36 to 24 seconds. Un-checking Options > Preferences > Alignment > Rotation and Brightness can help too, if your setup does not allow rotation and has stable illumination. If you're currently using the External TIFF Reader (at Options > Preferences > Preprocessing), then try de-selecting that option; if you still get correct results, you'll get them a little faster.

5. For best throughput, run multiple copies of Zerene Stacker simultaneously. Example: in the test I ran just now, a single stack processed in 35 seconds; two copies run simultaneously finished in 48.5 seconds; and three copies run simultaneously finished in 55 seconds. Total throughput (stacks per hour) was almost doubled by running three stacks at once.

6. Faster I/O helps, especially with 16-bit TIFF, and especially when you don't have enough DRAM to cache the data produced by an earlier step such as raw conversion. To highlight the difference, I generated 16-bit TIFFs on SSD and HDD, then tested immediately after a system reboot so that the disk caches would be empty. The results were HDD 31.5 seconds, SSD 28.2. To evaluate consistency, I repeated the process (including the reboot). That produced HDD 34.9, SSD 24.4. Clearly there's a lot of variation but the SSD was significantly faster. However, I then repeated the process once more (including the reboot), but this time I copied the folder of images first and ran ZS on the copy. The result then was HDD 20.7, SSD 20.6. In this last case, most likely the image files weren't actually coming off the disk at all, but just being refetched out of memory buffers left over from copying the folders.

Using Steven's question as a segue to what happens "under the hood"...
I wonder if Rik knows off hand what the most limiting factors are to stack performance.
It's dominated by CPU performance, with components of both per-processor speed and aggregate system speed. The processing essentially alternates between "serial" phases where one processor does all the work, and "parallel" phases where all available processors share the work equally.

My current system has 6 physical processors (cores), which pretend to be 12 through the fantasy of hyperthreading. The test stack in front of me at this moment completes in 69 seconds with Options > Preferences > Multiprocessing set to use 1 processor. When set to use 6 processors, it completes in 22 seconds; and set to use 12 processors it completes in 21 seconds.

The improvement of 3X with 6X more resources is due to those "serial sections" where one processor does all the work while the others twiddle their thumbs. The lack of improvement in going from 6 (real) processors to 12 (hyperthreaded) processors is typical in my experience, and that's why I say "pretends to be 12 through the fantasy of hyperthreading".

The advantage of running multiple stacks at once (point 5 in the list above) is that when one stack happens to be in a serial phase, the other processors can be reassigned to do productive work on another stack in a parallel phase. I've heard of people routinely processing half a dozen at a time. Note that at present I/O is always done in a serial phase, so processing multiple stacks at once also allows I/O for one stack to be overlapped with lots of computation for another stack. [Update: as of April 2014, there's a Pro-only option to overlap I/O with computation, given sufficient memory.]

As for graphics card performance, that probably has no effect. At present ZS doesn't use the graphics card for anything except a place to put pixels.
TheLostVertex wrote:I also know from testing that the option "use external tiff reader" has a small but measurable impact on stack time on mac(only a couple seconds difference in 30 image test stack I was using).
This is surely true. The option to "Use External TIFF Reader" involves copying the original tiff file to a different file format that's guaranteed to be readable by ZS. The remarkable thing about that process is that it's cheap relative to everything else that goes on.

--Rik

Edits 9/16/2014:
1. Clarify good settings for memory allocation in point 3, consistent with recent improvements discussed later in the thread.
2. Mention turning off the External TIFF Reader in point 4.
Edit 4/15/2015
3. Mention new option to overlap I/O and computation.
Last edited by rjlittlefield on Wed Apr 15, 2015 10:25 am, edited 3 times in total.

dolmadis
Posts: 897
Joined: Wed Dec 07, 2011 1:51 pm
Location: UK

Post by dolmadis »

dolmadis wrote: Could you give us some idea of what spec you might suggest for stacking processing?
Thanks as always for excellent information and analysis.

For one who is needing to upgrade from an old 'ish desktop, which does not perform well on any graphics processing, is it possible for anyone with the technical knowledge to stick their neck out for me. No liability !!

Cheers

John

TheLostVertex
Posts: 317
Joined: Thu Sep 22, 2011 9:55 am
Location: Florida

Post by TheLostVertex »

Chris S. wrote: Steven, I also thought this might be the case, but a recent test I ran indicated otherwise. Using an SSD as the image source and storage drive for Zerene Stacker saved only about 5 seconds—total—during stacks of 603 images. So the difference was measurable, but trivial.

Details: This was with one Samsung 840 Pro Series SSD for the operating system and applications, and either a second Samsung 840 Pro Series SSD or a Western Digital Black (high-quality standard hard drive) as the source and storage drive for Zerene Stacker.

I do strongly recommend using an SSD for the operating system and applications. And data and certain user directories should be placed on a second drive—physical if possible, logical if not; this makes for much easier backups and--especially--recoveries. It's probably also worth mentioning that some other photographic tasks would probably see much more benefit from the use of an SSD for temporary files—a Photoshop scratch disk is a likely candidate.
rjlittlefield wrote: 4. If performance matters, then turn off functionality you don't care about. This applies especially to "Cache unaligned screen images" and "Cache aligned screen images", found at Options > Preferences > Caching & Undo. If you seldom or never want to detect movement by playing a stack as if it were a filmstrip, then remove the checkmark on "Cache unaligned screen images". If you don't plan on retouching from source or you're prepared for frame selection to be sluggish, then remove the checkmark on "Cache aligned screen images". In one test I ran just now, un-checking both options reduced stack processing time from 36 to 24 seconds. Un-checking Options > Preferences > Alignment > Rotation and Brightness can help too, if your setup does not allow rotation and has stable illumination.
So it is good to see that tests have been done, and that and SSD is not a significant factor in performance of stacking. But the question occurs to me, is it for retouching? Are aligned and stacked imaged cached to disk, and then read at the time they are selected for retouching? I ask because when retouching between images there is a short delay for switching. For me this is the part of stacking performance that I wish to improve the most, since it is the only part that I have to sit around and watch :D

It is also nice to know that running multiple copies of zerene will yield an over all gain when multiple stacks need to be done. The serialization of some task also nicely explains the CPU usage I see during stacking stages.

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

Post by rjlittlefield »

TheLostVertex wrote:Are aligned and stacked images cached to disk, and then read at the time they are selected for retouching? I ask because when retouching between images there is a short delay for switching.
At this time aligned source images are not cached anywhere. The reason for this approach is that, in the past, every time I've tested it has been faster to re-read an original image file and computationally transform it to retouching format, than it was to do the additional I/O for images that were stored on disk in format already ready for retouching. That would be 32-bit floating point at least, and 4 values per pixel for pyramid representation, so 384 megabytes for a 24-megapixel image. This large size also explains why to date I have not bothered to write code to cache images in memory.

In coming months I plan to re-evaluate issues like this. My current machine actually has two SSD's -- a small one to hold the operating system and a larger one specifically for test and development. But at the moment I certainly would not encourage anybody else to reproduce that configuration in hopes of getting performance improvement for stacking. It's completely unclear how the re-evaluation will go, and in the meantime SSDs get cheaper every month.

Getting a bunch of DRAM is a much simpler decision, and I definitely do recommend being sure you have plenty of that. I recently upgraded another machine from 4 to 16 GB to avoid paging. The total bill was under $200. Having lots of DRAM available also opens the door for effective caching in memory. This is also something that ZS currently does not do, but definitely will in coming revisions.

Specifically regarding the delay in retouching, I can suggest two changes to your configuration. First, try setting the brush type to Pixels instead of the default Details. That will avoid a relatively expensive reformatting of the image that is otherwise required to support the Details brush. Second, consider avoiding expensive interpolators such as Lanczos 8 (16x16) while retouching.

--Rik

marceppy
Posts: 102
Joined: Thu Jan 05, 2012 8:05 pm

Post by marceppy »

Here is my experience with a recent computer and memory upgrade. I upgraded from Windows XP to Windows 7 64bit on 2 computers. One computer has a SSD hard drive. Noticing that RAM memory prices were dropping, I did some research on RAM for these computers and found good prices on Ebay.

1. I upgraded and maxed out my RAM (50gb dell ram on the new computer and 24gb on the old). I bought the RAM very cheap on Ebay. If you are thinking about upgrading your RAM, you need to look closely at your service manual for your computer to understand the RAM configuration and the order each RAM stick is placed in the memory slots on your computer. You also need to know the exact RAM cards that will be compatible with your computer. Your service manual will show the order in which each card and size (memory, 4gb, 16gb, or combination, etc.) must be installed. As far as installing the RAM cards – it is very easy once you have the right cards and know the order in which they have to be placed. Your computer service manual will show this.

2. I did look at the Dell site for my computers and talked to a service tech, but actually, the best information I got was from an Ebay sales person that I bought the RAM from. I might still have the name of the company that I bought the RAM from if anyone wants to check prices; they were Excellent in helping me find the right RAM cards and had a good price. They let me exchange my existing RAM cards for a discount on the new ones that I received from them. They were in good working condition, just smaller memory cards.

3. After the upgrades (old and new computers), the difference was amazing but let me qualify that: the computer runs much much faster for programs like photoshop, bridge, Canon DPP, Excel, etc. – resolving speed of the images was greatly improved on these programs. I don’t know about limits of Zerene Stacker, it seems to run a little faster but I will take Rik’s advice, as it is not as fast as the others. Let me say this though, my experience is that the speed of the programs are only as fast as the external drives they are linked to. The SSD drives are small and will hold your primary programs, but will fill up fast. I keep data on external drives and run the programs from the SSD. I have noticed that the programs will only run as fast as the external drives that the computer is linked or hooked to. I have a fast external drive and it processes at high speed, however, if I am working directly from a flashcard, it is very slow.

4. If you want to know what your system configuration is, there are a couple of ways to determine this (PC Windows): 1) type dxdiad into the Start window, which will display the System tools and system display and sound configurations. 2) For a quick check, click Start, right click on Computer, then click Properties – it will display your system information.

5. If you want to clean your hard drive of unwanted programs that may be using memory, this is one that I used: REVO Uninstaller. There is a free download on Cnet and other sites. A Microsoft technician recommended it to me. It will display most if not all programs and they set up levels of removal from the computer and registry.

I hope this information is useful.

marceppy
Posts: 102
Joined: Thu Jan 05, 2012 8:05 pm

Post by marceppy »

4. If you want to know what your system configuration is, there are a couple of ways to determine this (PC Windows): 1) type dxdiad into the Start window, which will display the System tools and system display and sound configurations. 2) For a quick check, click Start, right click on Computer, then click Properties – it will display your system information.
A typo - use dxdiag ... not dxdiad, sorry.

Post Reply Previous topicNext topic