Weird blue and red artifacts in Zerene but not Helicon

[perdu34]

I've been playing with my workflow in the last couple of weeks, which has involved getting Zerene for the first time.

I've captured a series of stacks and then set the batch processor to run in Zerene producing PMax and DMap images for later blending. Most of the exported images have come out great and can be edited just fine. BUT a handful have these weird red and blue artefacts that I can't seem to get rid of.

PMax from Zerene

DMap from Zerene


Helicon Method C



Has anyone seen this before and knows how to get rid of it?

[mjkzz]

wow, maybe you can put the original images on dropbox so others can check it out.

[rjlittlefield]

The streaky colors look like what happens when a severely underexposed frame gets brightened to "match" the others. Check your troublesome stacks frame by frame. If you saved the projects, then probably the best way to do the check is to re-open the troublesome project, put a checkmark on "Show as adjusted" at the top of the Input Files panel, then step through the list of input files. For a well behaved stack, nothing obvious will change except for focus. But with stacks that produce streaky colors in the output, one of the source images will show similar colors in the "as adjusted" form.

If that's not the problem, then I agree that we'll need to look at the source images to figure out what's going wrong. Send a note to me as support@zerenesystems.com and I'll be happy to take a look.

--Rik

[perdu34]

Peter,

I have made a DropBox folder and put the Zerene project and the original files in it. Everything it uploading at the moment but they should all be there by the time you read this.

https://www.dropbox.com/sh/1invppgqdy9a ... 3VnZa?dl=0

Rik,

There are some off Aligned images, but my quick check of the originals doesn't seem to show any big brightness differences. The problem starts at around -Aligned-3159 but I can't see an -Unaligned-3159. Could a skipped/missing file the problem?

[rjlittlefield]

Lucas, thanks for the upload! I've downloaded a copy and run some quick tests. It will be a very interesting test case for future development. (By the way, I think you've set a new record for the biggest test stack sent by DropBox, 1.91 GB in the downloaded zip.)

I will post more later, but as quick response, I suggest at Options > Preferences > Alignment, un-check all options except for Shift X and Shift Y. This is the standard recommendation when working with deep high magnification stacks, for the reasons that are discussed at http://www.photomacrography.net/forum/v ... 9878#79878 (linked from the Zerene Stacker FAQs page at How should I set the Alignment options? ).

The problem you're encountering is that one end of the stack looks so much different from the other end that "correcting" for apparent exposure differences across the whole stack actually ends up introducing harmful level changes. The problem creeps in gradually from one end to the other, as shown by this graph of one of the two brightness correction parameters:



Removing the checkmark on Brightness correction will prevent those harmful changes.

I think that you are intending to use these stacks as tiles in a stack-and-stitch composite, so I desperately want to say that you should turn off Shift X and Shift Y also. With Shift X, Shift Y, and Scale turned off, and with perfectly smooth and straight focus movement along the depth axis, the rendered image would end up with perfectly orthographic projection, ideal for stitching.

However, there are tradeoffs that prevent that recommendation for this stack. If the focus stepping is not perfectly smooth and straight, then turning off Shift X and Shift Y corrections can result in visible image artifacts such as softening or even clear "echos" if the frame-to-frame shift becomes large enough. The shift values that appear in your stack are quite large (Y shift averages 3.6 pixels between adjacent frames), and indeed when I turn off shift corrections the image degrades to junk.

The problem starts at around -Aligned-3159 but I can't see an -Unaligned-3159. Could a skipped/missing file the problem?

There's no skipped or missing file in this case. Your -Aligned- images have odd numbers and -Unaligned- images have even numbers. That's the usual case, when both sets of images are generated at the same time as by default. The mate for -Aligned-3159.jpg is -Unaligned-3158.jpg . You can see that in this piece of your 03.zsj file, which also shows the alignment parameters for this particular source frame 03IMG_0261.jpg.

Code: Select all

      <StackFrame>
        <ImageSource>
          <Source value="/Users/slblack/Desktop/Anomala dimidiata/JPGs1/00000Sorted/03/03IMG_0261.jpg" />
        </ImageSource>
        <RegistrationParameters>
          <XOffset value="0.002922014956159208" />
          <YOffset value="-0.012802272912975365" />
          <Scale value="1.0389695326859099" />
          <Rotate value="0.019167912707569512" />
          <LimitFlags value="0" />
        </RegistrationParameters>
        <BrightnessCorrectionParameters>
          <GammaAdjustment value="0.5967893634576555" />
          <Scale value="0.777453191617709" />
        </BrightnessCorrectionParameters>
        <CachedUnregScreenImage value="-Unaligned-3158.jpg" />
        <CachedRegScreenImage value="-Aligned-3159.jpg" />
      </StackFrame>

But to specifically answer the question, there would be no problem if any of those screenpreview images were to go missing. Those are just low quality images that are cached to allow rapid screen updates. If one goes missing, there's an automatic fallback to the original source image, and typically a new cached copy gets generated.

Bottom line, turn off all alignment options except for Shift X and Shift Y, and reprocess the stack.

--Rik

[perdu34]

Thankd Rik, that's very helpful!!!

The shift values that appear in your stack are quite large (Y shift averages 3.6 pixels between adjacent frames), and indeed when I turn off shift corrections the image degrades to junk.

Unfortunately I live in a house with wooden floors and two sets of neighbours who are digging out their basements. The joys of London I'm afraid. I've just (yesterday) got permission to move the camera to my lab at uni so this should get better.

(By the way, I think you've set a new record for the biggest test stack sent by DropBox, 1.91 GB in the downloaded zip.)

OOOH do I get a prize? Stuffed toy perhaps?

[mjkzz]

Lucas, thanks for those files, I did download them and VPN did not slow me down!!! Anyways, FWIW, I tried full stack with and without (per Rik's advice) brightness option turned on. And (of course) Rik's advice worked.

One observation though, I was stacking and it took at least 50 minutes on my computer (and I was stacking from the zipped file), so I was bored watching it, I did notice one thing that the in focus band does not seem to change much, at some point, I put a my finger at some feature and it does not seem to change for a couple of images. So I think maybe your step size is too small. Just my 2 cents

[mawyatt]

I confess I don't know how these stacking algorithms work, but how would using too small a step size have any significant effect, except to create a larger & longer than required overall file size & creation?

Best,

[Lou Jost]

I would think it would add noise to the final image. Every frame has a bit of noise, and especially in PMax, that noise tends to get into the final result.

[mawyatt]

Lou,

In standard signal processing co-adding similar waveforms actually reduces the random noise (non-correlated) and enhances the waveform similarities (correlated). This has the general effect of improving the resultant Signal to Noise ratio.

However I don't know how this behaves with regard to focus stacking algorithms, and as you say may very well increase the resultant noise levels.

Best,

[rjlittlefield]

I would think [using more frames than necessary] would add noise to the final image. Every frame has a bit of noise, and especially in PMax, that noise tends to get into the final result.

True, but the impact is a lot less than you're probably imagining. It is certainly a lot less than I imagined, when I first thought to look at the issue of noise accumulation.

Basically what PMax does is to retain in the output the worst absolute noise (either positive or negative) that appears in any frame of the stack, at each pixel position. In the stacks where I have looked closely, it has turned out that the distribution of noise values at each pixel position has a "short tail", with the result that the accumulated noise rises quickly from 2 frames to 4, rather less from 4 to 8, and so on, so that the difference from say 50 to 100 frames was detectable but not immediately obvious.

To quickly model this, we can look at the expected values of max(abs(normsamp)), where normsamp is random normal with mean 0 and stdev 1, and the number of frames N varies as 2, 4, 8, and so on. Evaluating this model with Excel and taking the average max value over 1000 runs of the experiment, I get:

Code: Select all

N           1     2     4     8    16    32    64   128   256   512  1024
Noise    0.77  1.14  1.48  1.77  2.07  2.34  2.59  2.82  3.04  3.24  3.45

Here's a graph:


If you want a quick heuristic you can think of noise growth as happening at a rate of log(N), but it's actually a bit slower than that, and much slower in a perceptual sense. Going from 1 frame to 2 frames adds 0.37 noise, increasing the single-frame noise by almost 50%, while going from 128 to 256 increases it by only 0.22, less than a 10% increase by that point. So, the more frames you have to start with, the less you care about adding more.

For DMap, noise accumulation is not a significant issue because DMap never increases noise level, only reduces it at a relatively few pixels by weighted averaging of consecutive frames on transition boundaries. Noise level for DMap matters only to the extent that noise can get confused with real detail, which you can handle by adjusting the noise threshold.

I used to worry about frame count as an important factor in PMax noise accumulation. These days I do not, and instead I just emphasize getting enough frames to be sure of not losing any detail.

That issue of "losing detail" becomes especially important when the shooting setup has issues with vibration, because vibration can affect focus point just as much as lateral framing.

In the current stack, it's easy to see that the image is bouncing around by 5-6 pixels or so, side to side. EXIF reports this is with a Canon 5D Mark III, so that's about 40 microns on sensor, about 4 microns on subject at 10X. Assuming that the vibration affects all axes equally, the focus vibration is something like half of the nominal DOF. In this situation, using a small focus step is a good defense against focus banding caused by environmental vibration. Empirically, when I reprocess the stack with only half as many frames (skip factor 2), it becomes trivial to detect places where detail is lost by using fewer frames.

co-adding similar waveforms actually reduces the random noise (non-correlated) and enhances the waveform similarities (correlated)

That's true also, but it's not relevant to current stacking algorithms because nothing except Helicon's Method A does a significant amount of averaging across frames.

Of course you can average source frames outside of any stacking software.

There's also an item someplace on Zerene Stacker's requested-features list to do averaging inside Zerene Stacker, for example to handle multiple exposures at each focus step, or to handle seriously over-sampled stacks such as might result from video input. Both methods could be expected to yield some effective improvement in resolution, certainly from pushing the noise down, and possibly from super-resolution (in combination with up-sampling).

--Rik

[mjkzz]

oh wow, I was merely pointing out the step size might be too small . . . on my computer, it took close to 50 minutes to do a full stack. Also, for me, the less time it takes to finish stacking, the less chance it is ruined by some external events

As for noise improvement, as far as I know, there is a stacking algorithm that smaller step MIGHT improve noise level, never thought about it this way, so I need to evaluate that to confirm it.

[perdu34]

oh wow, I was merely pointing out the step size might be too small . . . on my computer, it took close to 50 minutes to do a full stack.

The stacks process a little faster for me, maybe 35min each. Which isn't too bad as I can set them off at night to be touched up in photoshop the next day.

There is a reason for the small step size. I know my rig isn't exactly stable so over-sample in order to make sure I get sharp images. My depth of view is around 60um and I have a step size of 7um. Maybe my paranoia is a little strong in this case.