Zerene Stacker - input appreciated with handheld stacking

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

Moderators: rjlittlefield, ChrisR, Chris S., Pau

Slinkytreekreeper
Posts: 49
Joined: Fri Feb 04, 2011 7:52 pm

Zerene Stacker - input appreciated with handheld stacking

Post by Slinkytreekreeper »

Well most things I have wanted to know are documented extremely comprehensively here but searches for zerene stacker technique comes up a little short in comparison. I know many of you use ZS to stack handheld shots but transitioning from PS to ZS is not proving to easy.

Where I have a few frames close, often I will test a stack in both programs and ZS comes out way worse, although through using the excellent retouching tool it is possible to bring it back to some degree. I have used braketeer for a few 100+ stacks but I can't get close enough for the fine focus not to have too much overlap. I will get there and there is definite progress but I want to be able to nail 10 frame stacks easily before raising the bar

My problem is, I do not have consistent overlap in frames and sometimes just part of an antennae or eye in focus yet they all have an OOF version. This duplicates antennae or creates so much noise around edges from shift in perspective and each frame sharing lots of semi blurred parts.

So I was wondering:
Is there anyway to choose an output frame from the entire stack as my background to work on rather than having to produce a rendering of Pmax first? Or better yet, no background?
I have tried stacking the frames is PS, cropping to the same size as originals and inputting to ZS with the original frames that made it. This of course just produces more noise instead of giving me a base to work from.

This would be preferable when I have just 2 or 3 shots that are a less than a perfect stack when stacking them creates a mess but lots of retouching gets me there.

I have a few ZS questions and wasn't really sure whether to post them here, beginners forum or to ZS directly. Thanks in advance for any input

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

Re: Zerene Stacker - input appreciated with handheld stackin

Post by rjlittlefield »

I have a few ZS questions and wasn't really sure whether to post them here, beginners forum or to ZS directly.
Posting here is fine, or email to support@zerenesystems.com. I end up answering them either way, so mostly it depends on how public you want the discussion to be.
I know many of you use ZS to stack handheld shots but transitioning from PS to ZS is not proving to easy.
Not sure about that word "many". I think it's more like a handful, maybe one per finger. Handheld stacks are difficult under the best of conditions, and they're definitely not the sort of work that ZS was designed to do.

The problem is what you mentioned -- shift in perspective. Whenever the lens moves sideways, it changes the way in which foreground and background features line up. This makes it impossible to properly align the in-focus and out-of-focus versions of each feature.

The PMax method handles this situation particularly badly. PMax is relentless about preserving detail wherever it finds it. If a feature appears at three different places in three different frames, you're likely to see all three of them in the final image. PMax is a great general purpose tool for dealing with mechanical stacks, but not for handheld shots where the lens is drifting around.

For handheld stacks that involve shifts in perspective, you really need a "depth map" method that will pick one image at each pixel and show you just that. This eliminates the smearing & echoing effect that PMax will give, giving instead clean renditions in all areas of the image except where the depth map transitions from one source image to another. If things don't align in those areas, you'll still get some smearing or discontinuities, but at least they're contained in fairly small areas so they're easier to fix up.

In ZS, the depth map method is named DMap. Unfortunately for your purposes, in ZS DMap is considered an advanced method and has a much more complicated user interface than PMax does. PMax has essentially no parameters; it just does what it does. In comparison, DMap has a "contrast threshold" selection that many people find hard to learn, and in addition it has some "radius" parameters that may have to be adjusted for different classes of images.

My usual recommendation for new stackers is that they start with PMax, learn how to shoot clean stacks, then gradually shift over to DMap and to combining DMap and PMax for subjects where DMap has advantages.

So, what you're doing by starting with handheld is exactly the opposite of what I usually recommend. That's not to say it's bad, just that I'm not surprised you're having some problems.

You mention that you "want to be able to nail 10 frame stacks easily before raising the bar". That sounds like a good approach if the 10-frame stack is not laden with perspective shifts. If it is, then you'd probably be better off either continuing to work with the 100-frame stacks, or figuring out how to shoot a clean 10-frame stack, perhaps using either a focus rail or turning the focus ring manually (see for example HERE), or simply loading into ZS only every 10th frame of the overly dense 100-frame stack that you physically shot. If you do continue with all 100 frames, consider using Options > Preferences > Pre-sizing to cut the image size to something that will run faster.
So I was wondering:
Is there anyway to choose an output frame from the entire stack as my background to work on rather than having to produce a rendering of Pmax first? Or better yet, no background?
I'm not sure what you're asking for here, but maybe you're wanting to use one of the source images as a base for retouching, instead of the usual approach of using an output image. If that's the case, then here's a trick that may be helpful. Stack using whatever method you're more comfortable with, either PMax or DMap. Start retouching the output, and immediately make a huge brush and just paint over the whole thing with whatever source image you want to start with as "background". Now you have a working copy that's equal to one source image, and you can paint over it piecemeal from any other source image or from the un-retouched output that you started with.

I hope this is helpful. Sometimes it's difficult to figure out where to start. :?

--Rik

Slinkytreekreeper
Posts: 49
Joined: Fri Feb 04, 2011 7:52 pm

Post by Slinkytreekreeper »

Here seems like a good place, your answers may be of help to others also.
Be gentle though, i'm still in the asking stupid questions stage.

I realize I have far from perfect stacks and ZS wasn't designed for this but your 'trick' does indeed produce exactly what I was looking for, I feel a tad silly not seeing that one now :oops: My excuse is I was in tunnel vision mode.

This image is the 2 frames stack in ZS where I just had an eye and part of the raptorial in one frame and the rest of the mouth in another - with no crisp data for it to work from everywhere else.
Image

I am a bit confused ta the term handstacking and manual stacks. Are they the same or does one refer to PS non automated methods. I hope this makes sense. Maybe a basic definition of handstacking would help me here.

I had also missed the second tutorial page on your site as I presumed the second tutorial was referring to the second video tutorial. I think it will be a useful exercise for me. May I suggest a nav bar of some sort so any page can be got to from any page?

This is a 9 frame stack that I managed in PS that is less than perfect but I'm satisfied with my progress so far, this is the type of handheld stacks I am aiming at transitioning across to ZS to do unless you suggest this is not a bright idea...

Image

I actually have a few more questions but the two relating to ZS technique are:
I realize that ZS works with layer masks, would it be possible in anyway to add a mask to parts of a frame or three from say a ten frame stack, that I did not want ZS to include into the initial render prior to any retouching?

Do you plan on adding any additional controls to the retouching brush such as a soft brush or feathering or is it limited to a hard edge here for some technical reason?

This isn't really a question, more of a request. Please consider adding a backstep to the retouching tool if at all possible, even if we have to add more memory and it is slow, pretty please.
:D

Seriously though, thanks for providing such an satisfying and interesting place to learn, your input is golden when the learning curve is this challenging.

Liam

LordV
Posts: 1571
Joined: Thu Nov 22, 2007 10:28 am
Location: UK

Post by LordV »

Liam - I might be partially responsible for confusion on hand stacking.
I do two things.
I actually shoot all my stacks handheld and so should correctly be called Handheld focus stacks.
Secondly I often do the resulting focus stacks in PS by hand using the healing brush to transfer in focus parts from one shot to another. This is normally because either my handheld stacks have too much movement to stack well using say zerene or there was some movement of the subject. (or both).


Brian V.
www.flickr.com/photos/lordv
canon20D,350D,40D,5Dmk2, sigma 105mm EX, Tamron 90mm, canon MPE-65

AndrewC
Posts: 1436
Joined: Thu Feb 14, 2008 10:05 am
Location: Belgium
Contact:

Post by AndrewC »

Slinkytreekreeper wrote:....

This isn't really a question, more of a request. Please consider adding a backstep to the retouching tool if at all possible, even if we have to add more memory and it is slow, pretty please.
...

Liam
yes the Cntrl-Z option would be nice but you can always go back and retouch the retouch with the original.
rgds, Andrew

"Is that an accurate dictionary ? Charlie Eppes

Slinkytreekreeper
Posts: 49
Joined: Fri Feb 04, 2011 7:52 pm

Post by Slinkytreekreeper »

I realize you can pick any image to retouch from of course but an edge to touch up is always a decent way from the background it sits on, especially in large stacks. Then you have the issue of waiting for the retouch tool to load up that image before you can actually work.

I know you can save at any point also but that also takes a while before being able to carry on again. This brings me on to a couple of performance questions with ZS but i'll ask those after Rik has a chance to answer.

Maybe this isn't an issue with practice? Am I on my own here or is it not possible due to the way the back end works?

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

Post by rjlittlefield »

I am a bit confused ta the term handstacking and manual stacks. Are they the same or does one refer to PS non automated methods. I hope this makes sense. Maybe a basic definition of handstacking would help me here.
There is no ironclad terminology in this area, so sometimes it's necessary to read between the lines to figure out what's actually meant.

Brian has made a good distinction between shooting stacks by hand and assembling focus stacked composites by hand. The former is often called "handheld", the latter something like "manually stacked" or "stacked by hand". If it's not clear from context, the safest thing is to ask.

As a matter of practice, there are even finer distinctions that can be worth thinking about. For example the alignment process can be automatic or manual, independent of the process of selecting sharp bits to appear in the composite.

One extreme manual approach is to load two or more images into Photoshop, align the relevant parts using Free Transform, then use layer masks or cloning to expose or assemble the sharp bits. This approach has the advantage that selection and alignment essentially happen at the same time, so the alignment process concentrates on the subject and does not get misled by, say, a busy background.

A less extreme manual approach is to use automatic alignment, but mousework to select all the sharp bits.

An extreme automatic approach is to load all the images into ZS, click on Align & Stack All, and save the output image.

In between, there are various semi-automatic approaches.

I tend to be a perfectionist, so it's rare for me to use a fully automatic approach. I almost always run both PMax and at least one DMap, sometimes another DMap or two with different parameters, then use retouching to identify and combine the best bits of the various outputs. Sometimes I end up going all the way back to source images in isolated areas. If the subject presents big problems with "transparent foreground", say with facial texture of an ant showing through a foreground antenna, then maybe I'll do a Stack Selected of just the foreground part and use that "stacked slab" as input for retouching.
This is a 9 frame stack that I managed in PS that is less than perfect but I'm satisfied with my progress so far, this is the type of handheld stacks I am aiming at transitioning across to ZS to do unless you suggest this is not a bright idea...

It's quite possible that ZS could do this stack well even on full automatic. That mostly depends on whether automatic alignment ends up putting things in place so that the transitions can be clean from frame to frame.

The alignment that ZS does is based on all the pixels in the image, not just the sharp ones, and it's limited to shift/rotate/scale for each entire frame at once. In your image, the body of the mantis covers many times more pixels than the antennae do, so the body gets more weight in the alignment process. If the subject and/or camera moves, then ZS is likely to keep the body lined up across frames and let the antennae end up wherever they want to. At this time there are no controls over the alignment process, for example no way to mask out the body so that the head gets aligned better.

Assuming the alignment process works pretty well, then the next thing to consider is which stacking method to use. As mentioned in earlier post, PMax is probably not the best choice because it will happily preserve several versions of the same feature from different frames, leading to a smeared or echoed appearance. When the camera drifts around, a better result is usually provided by DMap.

The trick to using DMap in this case is to set its parameters so that it makes "broad brush" decisions rather than tracking too closely to fine details. If your source images are high resolution, say 4500 x 3000 pixels, then I would try something like Estimation Radius = 20 instead of its default 5, and similarly Smoothing Radius = 10 instead of its default 2. Remember also to set the contrast threshold so that most OOF and featureless regions are marked as "irrelevant noise". The panels should look something like this:
Image
I realize that ZS works with layer masks,
Not quite. "Layer masks" are a Photoshop concept, not used by ZS. The depth map used by DMap acts kinda sorta like the combination of all PS layer masks in the sense that it determines which one or two frames each pixel value comes from. PMax does not use anything like a layer mask. PMax output pixel values are determined in a complicated way from numerous source frames, such that output pixel values can even lie outside the range of all source pixel values.
would it be possible in anyway to add a mask to parts of a frame or three from say a ten frame stack, that I did not want ZS to include into the initial render prior to any retouching?
In the current version there is no way to tell ZS to ignore part of a frame. Technically such a feature could be added, but it is so low priority that for practical purposes it's not "on the list".
Do you plan on adding any additional controls to the retouching brush such as a soft brush or feathering or is it limited to a hard edge here for some technical reason?
Yes, other forms of brushes are on the list for future enhancements, including traditional feathered paint-the-pixels brushes.

I say that carefully to emphasize that the current tool is not a traditional paint-the-pixels brush, nor it is uniformly "hard" in the sense that you're probably imagining. It's actually a multiresolution blending brush that takes the image apart into different levels of detail on a fine-to-coarse scale, paints each level with a hardness appropriate for that scale, then puts the results back together again. It's optimized for doing seamless retouching on well aligned stacks with PMax output used as either source or target. Traditional brushes have some problems there. But the current tool is definitely not optimal for other uses, particularly when things are not well aligned and you're trying to pick, choose, and blend to cover that up.
Please consider adding a backstep to the retouching tool if at all possible, even if we have to add more memory and it is slow,
"Undo" for retouching is on the list too. Due to the complex nature of the current brush, undo involves keeping track of a lot of data and/or redoing a lot of computation. I did a trial implementation early in development, and its performance was so bad that I decided I'd rather have people complaining about the lack of capability than the apparent incompetence of the developer. But the increasing availability of lots of memory and 64-bit systems is gradually changing the picture, and at some point it'll get done.

The potential value of undo definitely does become less with practice. It never goes away completely. I still find myself wanting it from time to time.
I realize you can pick any image to retouch from of course but an edge to touch up is always a decent way from the background it sits on, especially in large stacks. Then you have the issue of waiting for the retouch tool to load up that image before you can actually work.
I'm not sure what all you're saying here, so I can't tell if there are perhaps better ways to do what you're trying to accomplish. If "decent way from the background it sits on" refers to the number of stack frames, and you're bothered by the time to find the right frame, then be sure that you're using the up/down navigation process reached by pressing Shift and rolling the mousewheel or dragging the mouse up and down. Using this process taps into fast preview images and bypasses preparing an image for retouching until you're sure you have the right one. This is illustrated in the first video tutorial for retouching, HERE
May I suggest a nav bar of some sort so any page can be got to from any page?
Yep, that's on the list too.

--Rik

Slinkytreekreeper
Posts: 49
Joined: Fri Feb 04, 2011 7:52 pm

Post by Slinkytreekreeper »

Wow, what a lot of information :D Thank you.

Had to read a few times throughout the day and a couple after tea for it to sink in but you answered a couple of other things for me too. I have used a mix of those stacking techniques but it is useful to draw those finer distinctions. That muddy terminology is a lot clearer now.

I stand corrected in regards to layer masks and the hard brush although when zoomed in and retouching you can tell it's more than sympathetic to the edge in an intelligent way.

I had a fun evening and reran both the 2 frame and the 9 frame stack a bunch of times with various parameters from the jpg and the tiff and it was a much faster learning experience than I had anticipated with images to compare side by side.

Dmap is crazy powerful but ONLY when the parameters are 'just right', even more so with the large .tiff files - very impressive. I do kind of see why you don't recommend to start with it. Every time I had a darker background and lighter subject it munched away at that retaining the background, until estimation was at 40 and smoothing at 20 and the percentage slider at 62 - 78 tuned it that last bit - not a bit of retouching and the background noise from the jpeg version was actually gone! :shock: Totally unexpected trick learned there.
It took me a while to get there but knowing how ZS processes things makes it way less hit or miss and I can imagine rather quick with daily stacking practice instead of an entire evening for a 3 frames stack.

Along with your suggestion of tackling really tricky sections, specifically in various retouched versions and partial stack, then combining those, it's actually a little easier to see how those halo-less deep stacks are actually possible and not just some mean internet trick to haunt me.

I was not using the scroll wheel as you suggest also and after a bit of practice the hotkeys are really slick too but it was the time loading the image to then retouch that I was aiming to decrease if possible. I was presuming that it was a data flow issue and set up a very similar system as my main machine but with a perky raid set at work with a couple of 36gb 10,000rpm drives mirrored and did a couple of runs. It was quicker but not anywhere near as something relying on just the hdd bottleneck would be. Loading those images up however was really quick after the first image. I have not yet compared a 32 and 64 bit sytem but I expect that to have a bigger impact.

Was this because ZS was also calling on files stored on the same HDD so the sata channel had to share the load or more likely a cpu or ram crunching job?
If I was to assemble a rig dedicated to stacking, where best to put the power here?

Sorry for all the questions but I think I have enough ammo to crawl back into my cave and tinker for a few months now, thanks for taking the time to answer them so comprehensivley - you have saved me weeks of fumbling already. I will take the time out to learn how to use thw quote feature next time also, I realise this would probably help.

I wonder if there are enough advanced member round here willing to submit small tutorials on how they dealt with tricky stacks or aspects of stacks rather than just a stunning finished image.

Time for bed, maybe just one more stack....

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

Post by ChrisR »

would it be possible in anyway to add a mask to parts of a frame or three from say a ten frame stack, that I did not want ZS to include into the initial render prior to any retouching?
Couple of small things you've probably already found..
- sometimes you might want to take a frame or more through PS to make awkward areas more blurred so ZS doesn't try to get detail out of them an splat it onto the bit you actually want,
- ZS doesn't put foreground detail on top of rearward detail, so they can mix in an unfortunate way. In that case do (a) sub-stack(s) of the detail in each part. Then it's much easier to retouch the foreground onto the rear. When doing that, you might find that some depths are less distinct because of out of focus stuff overlapping, so you need to go through PS to pump up the contrast in Curves, and maybe increase Saturation.

AndrewC
Posts: 1436
Joined: Thu Feb 14, 2008 10:05 am
Location: Belgium
Contact:

Post by AndrewC »

rjlittlefield wrote:....
The trick to using DMap in this case is to set its parameters so that it makes "broad brush" decisions rather than tracking too closely to fine details. If your source images are high resolution, say 4500 x 3000 pixels, then I would try something like Estimation Radius = 20 instead of its default 5, and similarly Smoothing Radius = 10 instead of its default 2. Remember also to set the contrast threshold so that most OOF and featureless regions are marked as "irrelevant noise". ...
Hi Rik, do you have a cheat sheet of estimation / smoothing radius values based on images size ?
rgds, Andrew

"Is that an accurate dictionary ? Charlie Eppes

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

Post by rjlittlefield »

Slinkytreekreeper wrote:thanks for taking the time to answer them so comprehensivley - you have saved me weeks of fumbling already
You're very welcome -- I'm glad the explanations helped.
...it was the time loading the image to then retouch that I was aiming to decrease if possible. I was presuming that it was a data flow issue and set up a very similar system as my main machine but with a perky raid set at work with a couple of 36gb 10,000rpm drives mirrored and did a couple of runs. It was quicker but not anywhere near as something relying on just the hdd bottleneck would be. Loading those images up however was really quick after the first image. I have not yet compared a 32 and 64 bit sytem but I expect that to have a bigger impact.

Was this because ZS was also calling on files stored on the same HDD so the sata channel had to share the load or more likely a cpu or ram crunching job?
If I was to assemble a rig dedicated to stacking, where best to put the power here?
Typically the bottleneck is cpu, not I/O. Beyond a fairly low threshold, adding memory is little help. I have been told of systems where putting in a new disk or upgrading the operating system made things a lot faster, but I'm never sure how much to believe those because it's so difficult to set up a good before/after test. Likewise 64- versus 32-bit is not a big improvement, typically a few percent. The main advantage of 64-bit mode is that it eliminates the hard memory limits that can prevent working with large images in 32-bit mode.

Here are some more things you might want to know about how ZS works, especially when you're concerned with performance.

All file I/O is streaming, not random. There are no scratch files except for the special case of "Use External TIFF Reader", which is a workaround for certain TIFF files that cannot be read by Java on some systems. All other files are retained in the project tree when you Save Project.

If you look in a project tree, what you'll see are a bunch of "preview images" (typically two per source file, one aligned and one not), plus a few "generated images" (one for each output). The preview images are highly compressed low quality JPEG files that are used for quickly updating the screen during navigation. When you press-and-drag to scroll through source images, what you're seeing are actually the preview images. If you are retouching, then the on-screen display will be updated to show the original high quality source file before the brush becomes active, but if you are not retouching then usually the source window will be left showing the preview image. This can be misleading if you "pixel peep" to compare source and output while not retouching, because the output window will be showing full quality while the source will be showing low quality preview.

The general flow of data is that each source image is read, converted to a common internal form, processed, and released, while the data structures for each output image are retained in memory until stack processing for that image is completed. The internal data structures are fairly memory intensive, currently up to around 73 bytes per pixel, but they depend only on image size and not on stack depth.

Except for the screen preview images, there is no "caching" of image data and thus increasing the memory allocation has little effect once there's enough to avoid too-frequent garbage collection. Allocation beyond 150 bytes per pixel is really just a waste of memory. The Java garbage collector will happily "use" whatever you give it, but actually most of memory will just be filled with released garbage waiting to get collected.

Most cpu-intensive operations are parallelized, though typically at well under 100% efficiency due to implicit serialization in the memory manager. Reading image files is serial, but translating from external to internal representation is parallel. The balance between those depends on file format and is essentially impossible to predict a-priori although it is pretty repeatable on any given system.

Perhaps the best way to get a handle on performance is to fire up your own system's performance monitor and watch I/O bytes and cpu utilization. On my system, if I add a bunch of TIFF files to a project and just press-and-drag to see them on screen, then my disk pretty much maxes out at around 30 MB/sec, but at the same time cpu utilization runs around 40-50% of 4 cores. On the other hand when I light off an Align & Stack All (PMax), I/O drops to around 5 MB/sec on average while cpu rises to around 70% average. Adding a faster disk will not help in this situation.

On the other hand, if you have spare memory and multiple stacks to run, you might benefit from running a couple of them simultaneously. In one experiment that I ran just now, one job running by itself completed in 2:20 while two jobs running simultaneously in sufficient memory completed in 3:10 (1:35 average). The reason for this improvement can be seen in the performance monitor, which showed cpu utilization averaging over 90% with two jobs running at once.
AndrewC wrote:do you have a cheat sheet of estimation / smoothing radius values based on images size ?
It depends on what you want to do.

For well behaved mechanical stacks, I usually choose initial settings based on image sharpness. The default value of Estimation Radius = 5 works pretty well for images that still look sharp even when you zoom in to a display scale of 100% (actual pixels). For images that do not look sharp at 100%, then a good strategy is to see how far you have to scale down until they do look sharp, then increase Estimation Radius by the corresponding factor. For example if an image does not look sharp at 100% but does at 50%, then try Estimation Radius = 10. If you have to go to 33%, then try Estimation Radius = 15, and so on.

For all other stacks -- examples including handheld, subject moving, or very contrasty edges and highlights that tend to halo -- the process is rather more try-it-and-see. In this case, I generally think in terms of Estimation Radius as a fraction of frame width. In the case of Slinkytreekreeper's mantis, that value I suggested of Estimation Radius = 20 was actually frame width divided by 200, and the 200 was a rough guess based on experience from previous try-it-and-see exercises. One reasonable approach is to run some sequence like ER=5, 7, 10, 15, 20, 30, 40 and compare the results. You can save some time by doing this on images that have been pre-sized smaller, say to 50%, but in that case remember to adjust the ER's accordingly when going back to full sized images. (It's been suggested that ZS might include some way to do this automatically, to save some interaction and help out new users. That's "on the list", but like most other items on the list, it's probably not going to happen in the next few months.)

For Smoothing Radius, I recommend just half of Estimation Radius. There are special cases where other values work better, but they're so uncommon that probably your time is better spent working on other ways to improve the image.

I hope this helps -- thanks for the questions.

--Rik

DQE
Posts: 1653
Joined: Tue Jul 08, 2008 1:33 pm
Location: near Portland, Maine, USA

Post by DQE »

Rik,

As I'm trying to configure a new PC, hopefully well-performing for a range of stacks as well as for assorted Photoshop tasks, I found your comments on PC parameters vs performance most interesting.

Please comment on what might constitute a semi-optimal PC configuration for a range of Zerene tasks, in terms of CPU parameters (e.g., the current Intel 6-core 980x seems to lead the pack), max useful RAM, and unconventional "hard drives" (including various SSD configurations).

An interesting site to explore the higher end of PC configurations includes the Falcon Northwest site, and an exotic new parallel SSD card.

http://build.falcon-nw.com/

The details of the new "hard drive" are here:

http://www.ocztechnology.com/ocz-revodr ... s-ssd.html

I found its 740 MB per sec spec for reads or writes to be most impressive, although its price is a little on the high side at larger capacities. One thing's for sure, one would be much less I/O limited if one used such a device for one's photography work!
-Phil

"Diffraction never sleeps"

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

Post by rjlittlefield »

DQE wrote:Please comment on what might constitute a semi-optimal PC configuration for a range of Zerene tasks, in terms of CPU parameters (e.g., the current Intel 6-core 980x seems to lead the pack), max useful RAM, and unconventional "hard drives" (including various SSD configurations).
The most important parameter is aggregate cpu capacity: number of cores times speed per core. Total memory bandwidth is also important, but that probably scales with cpu capacity anyway.

I/O performance is much less important. Adding to comments in an earlier post, I'll mention that I had a chance to do some limited testing with SSD a couple of months ago, using a borrowed Christmas present in place of 7200 rpm disk in a laptop. I was contemplating buying an SSD for myself, but decided I had better uses for the money. The performance when stacking was measurably better but not very big.

The main advantage to SSD in my tests was faster booting and launching of various apps. Even booting and launching were not nearly as much faster as I had expected. I remember commenting at that time that "Hhmm, I guess all those long pauses when my laptop's disk light was not on actually did mean something!" Note that this was running a hefty dose of anti-virus software (both ZoneAlarm and MalwareBytes). Turning off anti-virus software makes everything run much faster and might very well increase the difference between SSD and regular hard disk also. But it's not something that will affect stacking very much. I just now ran a stack from TIFF with and without antivirus running, and the improvement was only from 125 seconds down to 120.

For RAM, 120 bytes per pixel is a safe number. Double that if you want to run two copies of Zerene Stacker at once. Add in generous allowances for PhotoShop etc. if you plan to run those at the same time. The one thing you definitely do not want is to be paging a gigabyte here, a gigabyte there.

So, if you're thinking of running two ZS on 25 megapixels plus PhotoShop, something like 8 GB would be appropriate. My development system is still 4 GB. It gets a little snug with big images in ZS plus Photoshop, and for sure I wouldn't run two ZS and Photoshop all at once.

By the way, if you do want to run two ZS at once, be sure to manually set its memory allocation. Default allocation on 64-bit systems is currently 3/4 of physical memory, and running two of those is guaranteed to trigger paging.

Graphics card performance comes in dead last. Unlike Photoshop and of course games, Zerene Stacker makes essentially no use of the gpu (graphics processing unit). That's on the list to explore for future enhancements, but it's pretty far out -- definitely Version 2 stuff.

--Rik

Edit: to clarify default memory configuration.
Last edited by rjlittlefield on Sat Feb 26, 2011 11:07 pm, edited 1 time in total.

SONYNUT
Posts: 635
Joined: Sat Jan 22, 2011 2:27 pm
Location: Minnesota USA

Post by SONYNUT »

I've run 3 at once so I guess im good...
..............................................................................
Just shoot it......

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

Post by rjlittlefield »

SONYNUT wrote:I've run 3 at once so I guess im good...
Hhmm... Perhaps you're running 32-bit Windows? In that case, it maxes at 1.6 GB per process, no matter how much physical memory you have. If it's 64-bit Windows, then I'd definitely be interested to know what Task Manager says for memory consumption when all three are running.

--Rik

Post Reply Previous topicNext topic