ChrisR, thanks for the further explanation of what Photoshop does. The approach of generating masks that fit into the standard Photoshop "layers" model is one that I played with back in 2004, as an
experimental modification to the Panorama Tools package. It was promising at first, but I never could figure out how to make retouching convenient, so eventually I went in other directions.
ChrisR wrote:Dmap "shrink the image until it looks sharp". Still scratching my chin over that. Sharp all over, or just sharp somewhere?
Sharp at the places you care about. The biggest drawback to all the depth map algorithms currently out there is that they use the same neighborhood sizes over the whole image. This works well if the subject has similar types of detail everywhere, not so well if some areas are rich in fine high contrast detail while others have only fuzzy smears. An exemplary "tough subject" for depth map algorithms would be something like a fuzzy-patterned cowrie shell on a pile of fishing net. In the area of the net, the evaluation neighborhoods need to be small in order to capture the overlapping layers of netting. But on the cowrie shell, those small neighborhoods will not be able to detect detail reliably and the depth map will have lots of mistakes. For the shell, larger neighborhoods are needed.
What's the downside of moving the slider too far to the right? Does it become like the PS "broad brush"?
There are three sliders: contrast threshold, estimation radius, and smoothing radius. Generally it is safe to just set smoothing radius = 1/2 estimation radius, so we can ignore that one. Yes, sliding estimation radius too far right gives big neighborhoods, and "broad brush" is a good description. Sliding contrast threshold too far right causes too many locations to become "unknown depth", at which point Murphy's Law implies that incorrect depths will be filled in and you'll get OOF blurs in those regions.
So why use Dmap at all? It's true that Pmax can boost the contrast rather, but everything goes through "Curves" anyway.
PMax boosts contrast by different amounts at different places in the image. Sometimes a PMax output will look like significantly different illumination was used. PMax also alters colors in ways that can be difficult to put back to the originals. PMax is always noisier at the pixel level than DMap. In general, DMap is more faithful to the original pixels, when it makes the correct determination of which frame is sharpest.
Tesselator wrote:I think the small detail in HF B is more resolved overall than in ZS.
That's definitely true for this test stack, and I'm looking into that to see what's going on. There are interactions between a lot of aspects: image alignment, perspective changes within the stack (due to entrance pupil movement), focus step spacing, and feathering of region boundaries. Brightness correction may play some role too.
I recently did a flower in just a few (10) slices
One common glitch is to underestimate the number of slices needed to get a clean result. In extreme cases, I have seen people shoot just a few slices, unevenly spaced, focusing on what they considered interesting detail. The resulting composites show the interesting detail, but they generally have some unpleasant halos as well. Best results are achieved by using a fine uniform focus step, so that the software gets to see subject details go out of focus gradually.
Note ChrisR's comment that the standard DOF calculation yields blur circles that are several pixels wide at the midpoints between focus planes. To get results that look uniformly sharp at the pixel level, it's necessary to shoot at what are often surprisingly small focus steps.
[brushes] I know these are somewhere on Rik's list!
True. It's a long list. I need never fear boredom.
...it's not doing high precision calculations.
The precision is higher than you might imagine. The best algorithms require substantially more bits than each pixel does, so 16-bit pixels turn into 32-bit arithmetic and storage. I don't know what Photoshop does. ZS does not discriminate between 8- and 16-bit input. Everything gets processed the same way. I believe that HF does the same thing. CombineZP does not handle 16-bit input at all, but even so, there are stages where it goes through 32-bit precision.
I couldn't decide if [Rik] was just a very ardent user and interested in teaching/spreading technique and limitations or if he was developing ZS or HF.
Most of the above. I was an ardent user and promoter of stacking software long before ZS was even imagined. I starting posting comparisons of stacking software back in 2004, with CombineZ4 and Helicon Focus 2.03. Things were fairly crude back then -- if I recall correctly, HF had no image alignment until version 3. I started developing Zerene Stacker in late 2008, when my situation changed so that that made sense. ZS got released as a basic-functionality beta in early 2009 and has been slowly expanding since then. Obviously I know the guts of ZS pretty intimately. I've read a lot of CombineZP and contributed some of its key algorithms. About HF, all I have is "outside information" -- whatever I can glean from its documentation and behavior.
Regarding technique and limitations, I'm afraid that I have incurable "truth in advertising" syndrome. The group I used to work for quickly discovered that I was not the best person to write proposals, if you catch my drift...
elf wrote:Currently saving a ZS project saves the aligned (and unaligned) images in a compressed format with a file size of 200 bytes. It would be nice to have an option to save the full size aligned images.
A clarification... ZS does save a
description of each aligned image in about 200 bytes, as part of the project file. The actual high quality aligned images are recomputed on the fly as needed. ZS also saves very low quality JPEG copies of the aligned images, solely to provide fast navigation when retouching. Those images are typically 100-400 KB, depending on image size and complexity. Exporting high quality aligned images is on the to-do list.
--Rik
