I can add a couple of list entries I have collected. I was asking about 32 and 64 bit linux and it seems as far as run times go there is little difference. These 2 messages cropped up
Code:
Hi -- I'm the author of Zerene Stacker and I have a fair amount of experience
with other common software. Let me take a shot at answering some of the
questions posed in this thread.
Dogs Afire asked:
> What things seem to help most when helping the image stacking programs
> create a quality output?
By far the most valuable thing you can do is to shoot clean images to start
with. By "clean" I mean low noise, well exposed, properly color balanced, and
as sharp as your optics can give but not oversharpened.
Most of the deep stacks that you see at photomacrography.net are shot as
JPEGs.
This is because 1) JPEGs are more efficient to shoot and store, and 2) the
conditions that allow deep stacks to be shot at all also allow the lighting
and
camera settings to be tuned so that the resulting JPEGs are high quality --
"clean" in the sense used above. The bad reputation of JPEGs is primarily due
to abuse -- too much compression, incorrect exposure or color balance
requiring
big corrections, excessive sharpening due to camera settings, and so on. To be
sure, the very highest quality results come from shooting raw and converting
to
16-bit TIFF for processing. But when JPEGs are clean to start with, the
difference is quite small. If you're not sure about your own equipment and
workflow, try it both ways.
By the way, there are no stacking programs that work directly with raw files,
contrary to what you may think from looking at the user interfaces. Some of
them just do the conversion to TIFF behind the scenes so you're not aware of
it.
> It seems that I might want to modify the imput images
> to help the software.
A few sorts of modifications can be helpful.
1. Color correction may work better before than after stacking.
2. Sharpening to emphasize the detail that you care about may help the
software
to distinguish detail from noise.
3. Preprocessing to remove dust spots will prevent them from turning into
trails
that may be difficult to touch out.
4. Noise reduction, again if it's properly tuned to preserve the detail you
care
about while reducing variation that you don't.
Dogs Afire suggested several ways "to indicate to the program not to use
information from certain areas". I have never seen this done effectively, and
I'm having trouble imagining a situation where it would be the method of
choice.
Certainly most users end up telling the programs TO use information from
certain
areas of certain frames. That's what retouching is all about. But those
decisions are best made after the program has already done most of the work.
Proactively editing the source frames in the hope that the edits will
cooperate
with the stacking algorithm is something that I've never seen done.
> Are there specific parameters for any of the programs
> that you find particularly useful?
In Zerene Stacker, the most popular stacking method is PMax. It has no
parameters at all, and it's also the best method around for finding and
preserving even low contrast or fuzzy detail. However, PMax also has the
downsides that it tends to increase noise, increase contrast, and may alter
colors. DMap is just the opposite -- it faithfully preserves contrast, colors,
and noise, but may miss low contrast or fuzzy detail and requires tuning to
give
the best result.
The default parameters for DMap are chosen to work well with images that are
sharp when viewed at 100% = actual pixels. Images that do not look sharp at
100% generally require larger settings for the two radius parameters. A good
strategy for setting those radii is to find a frame that contains the level of
detail you care about, reduce the display Scale until that frame appears sharp
on screen, then make the radii larger than default by the same ratio. For
example if you find that the image looks sharp when displayed at 50%, then
make
the radii 2X bigger than default. If it has to be reduced to 25% to look
sharp,
then make them 4X bigger. This same strategy works well in other programs that
use radii also.
> Is anyone familiar with the complex wavelet method that appears
> to be available for ImageJ?
That's one of the methods I studied before writing Zerene Stacker. The math is
different in its details, but the general approach and results are similar to
Zerene's PMax.
> One effect I notice in the stacks is a muddiness of the image
> and I would like to minimize that effect.
I'm not sure what the term "muddiness" means here. There is an effect we've
come to call "stacking mush" that results when the stacking method fails to
recognize low contrast detail and ends up using unfocused frames instead. See
http://www.photomacrography.net/forum/viewtopic.php?t=9335 for an extreme
example.
If stacking mush is what's being described, then the best fix I know is to use
Zerene's PMax method or CombineZP's Pyramoid Maximum Contrast. (The complex
wavelet method would probably give good results too, but I haven't
specifically
tested it.) Most of the other methods are vulnerable to stacking mush,
including Zerene's DMap, both methods A and B in Helicon Focus, and the depth
map methods like Do Stack in CombineZP. (The fact that Dogs Afire mentions the
interactive threshold setting tells me that he's using DMap, which is
vulnerable
to mush. PMax has no threshold setting.)
If "muddiness" means something else, then it would help if I could see an
example.
Alex Cummins asked:
> So my question is should you just move the focus as slightly as possible
> even if you don't see any change and then plow thru the photos.
The penalties for having more frames than you need are pretty mild, like
increased processing time and (for some methods) somewhat increased noise. The
penalties for having too few frames can be pretty severe, like focus banding
that essentially ruins the stack. When in doubt, err on the side of too many.
All of the rest of Alex's posting looks dead on target to me.
I agree with Paul Martin's observations and suggestions as well.
The depth of a focus step depends strongly on magnification. The interactive
calculator at http://www.microscopyu.com/tutorials/java/depthoffield/ is
pretty
good. For critical work, it's a good idea to step at say 70-80% of the value
shown there.
Regarding the time required to shoot stacks, be aware that automation
continues
to advance. See for example the data and method shown at
http://www.photomacrography.net/forum/viewtopic.php?t=11519 , using the
StackShot controller and a separate stepper motor to turn the fine focus knob
of
a microscope. There's an example at
http://www.photomacrography.net/forum/viewtopic.php?t=11464 of shooting with a
40X objective using the StackShot rail by itself (no microscope involved).
I hope this is helpful. Sorry I couldn't figure out how to use fewer words.
--Rik
Code:
> Are there stacker programs designed for transmitted light microscopy?
> I ask from a position of complete ignorance. Jim
Picolay fits that description.
Interestingly, as I read the Picolay manual, most of its stacking methods do
incorporate the "depth map" assumption that was bothering Don earlier in this
thread.
In a prior post, I wrote that "methods with that assumption were not designed
for transmitted light microscopy."
But really I should not have ended that sentence with a period. It would have
been more accurate as "...were not designed for transmitted light microscopy
of
subjects with overlapping structures at different depths."
I think it's important not to infer too much from the general theory of
various
methods. Many times what matters most is the details of how they're
implemented. Even if a method is based on the depth map assumption, it can
still work very nicely with overlapping multilayered subjects in many cases.
It's also important to remember that commonly used stacking programs all
provide
methods that are different from depth mapping. In Zerene Stacker, there's
PMax;
in Helicon Focus, Method A; in CombineZP, either of the Weighted Average's and
Pyramoid Maximum Contrast.
While I'm here, there's one more issue I'd like to touch on: handling of
out-of-focus regions.
It's fairly common in microscopy and extreme macro photography to encounter
stacks where some features never do come into sharp focus, although they are
definitely better focused in some images than others. The colonial algae at
http://www.photomacrography.net/forum/viewtopic.php?t=11753 are a good
example.
In general, stacks like these are handled better by one of the pyramid methods
such as PMax in ZS or Pyramoid Maximum Contrast in CZP. Methods based on
fixed-size neighborhoods are often unable to identify the best of several
out-of-focus versions, so it's common to end up with a result that is blotchy
or
more blurred than it needs to be in the never-focused regions.
--Rik
John
-