Question regarding duplicates
This is rather a question than a feature request. Especially, when doing handheld brackets with a non-OM1 camera, there is no constant/accurate movement of the focus plane along the Z-axis. Naturally, this results in duplicate focus planes. Sometimes, there are even backward movements.
I’m just wondering how such situations affect the overall stacking result. Rumors say, when using PMax it doesn’t matter a lot, but for DMap a continuous shift of the focal plane in one direction is essential.
Now, if it would matter, would there be an easy way to identify duplicates - or nearly duplicate - frames in advance? Or is that handled anyway already by the stacking and/or alignment algorithms. On the other hand, getting rid of duplicate images might result in a speed improvement, wouldn’t it?
BTW: What programming language are you using? As a software developer, I have to know that 😄 .
Log in to comment and vote
Comments6
Ryan Cush
Jul 24
Great question, and that is essentially right. Macro Studio's engine is in the general PMax family. There's no assumption that the focal plane moves monotonically through the stack. Duplicate planes, uneven steps, and backward movements shouldn't affect the result. A duplicate frame just splits the "win" with its twin, which produces essentially the same output.
Alignment is order-agnostic too: each frame is aligned independently against a central reference frame, not chained through the sequence. Handheld shift, rotation, and scale change are exactly what it's built for. So nothing needs to be cleaned up in advance for quality.
On speed, it would have some benefit, as stacking time grows roughly linearly with frame count, so culling obvious duplicates saves roughly proportional time, but probably wouldn't be a huge effect unless you have a LOT of duplicates. There's no automatic near-duplicate detection today, as reliably spotting them before alignment is surprisingly hard on handheld stacks, since every frame differs by hand motion. And after alignment, you've already spent most of the cost you'd hoped to save.
Wolf Amri
Jul 24
@Klaus Cinibulk, don’t think that you don’t get duplicates with an OM-1 - perhaps you get even more as the frame rate is higher 🤣.
And @Ryan Cush if you remember, I once had a similar request as it is often the case that these duplicates create for example two hair. In my experience they are the one thing that make stacking results bad (apart from the subject moving).
I have lately experimented with shooting at a focus differential of 2 (rather low) and then only using every second image, which sometimes created a better result.
Perhaps if the software can’t automatically find duplicates, it might be a good idea to either manually deactivate images while scrolling through them doing retouching, or by masking specific areas out of specific frames.
I’m using PTgui Pro for milky way panoramas and you can do that there. Then it would take the overlap for that part of the final pano from a different image.
Klaus Cinibulk
Jul 24
Thanks for the explanations Ryan! I‘m just thinking about situations like the eyes in the robber fly comparison I sent you recently. I think in such scenarios, when there are fine details like facets, such “problematic“ frames can generate artifacts. Removing one of the nearly identical frames from the bracket then often solves the issue. Interestingly, the result of ShineStacker didn‘t have these ghosting artifacts at all.
Ryan Cush
Jul 25
It’s true that if two frames legitimately have an item in focus, but in slightly different orientations, then it makes it harder for the algorithm to pick just one, so it picks both, which can lead to ghosting. That might be what’s happening in the Robberfly eye. I wonder if I could let the user paint a custom mask over any “problem spots” and then re-run the algorithm and have it ignore ONLY those spots during the restack. If you pulled entire frames out, then you might lose a good in-focus area elsewhere in the image.
Klaus Cinibulk
Jul 26
I have to keep asking stupid questions 😅. Actually, is the algorithm aware of such overlapping areas? Like, when blending a new frame into the accumulated result so far, does it know that parts of the target area are already in focus? Hmm, on the other hand, a new frame might have a sharper variant of the already existing area in the target…
Ryan Cush
Jul 27
Not stupid questions at all! The algorithm doesn’t keep a running "this area is already done" state. Frames aren't pasted into a canvas one after another, where the first sharp frame claims a region and later ones fill in the gaps. Instead, every frame is scored independently against the same fixed criterion (local detail energy) and the winner at each location is decided from all frames together, at the end. But if several frames are comparably sharp, it does some blending rather than arbitrarily picking one. I’m not entirely sure if the robberfly eye is related to this part of the algorithm or possibly the alignment algorithm. I need to carve out some quiet time to go deep on that one (and thanks to you, I have the frames to do it with!)