both pmap and dmap exhibit the noise, I don't see any noise in the originals.
newbie zerene stacker noise problem
Moderators: rjlittlefield, ChrisR, Chris S., Pau
newbie zerene stacker noise problem
I'm getting a lot of image noise periodically using zerene stacker and I'm not sure what I'm doing wrong. This was a 45 shot stack 1mm apart for each shot.
both pmap and dmap exhibit the noise, I don't see any noise in the originals.
both pmap and dmap exhibit the noise, I don't see any noise in the originals.
I'm sure Rik will be looking into this, if he isn't doing so already. Have no fear--he wrote Zerene Stacker, and will without doubt help you get to the bottom of your issue.
In the meantime, I have a stray thought that maybe a single, very overexposed image in your stack is throwing the whole thing off. Have you looked at the thumbnails for your set of images to see if there is a dud hiding somewhere within the set? Probably you have. In that case, do you by chance have a sub-folder within the folder that holds your 45 images? Does that subfolder happen to have outtake shots from when you were testing exposure, and perhaps contain a frame with strong overexposure? If so, could you have accidentally highlighted this folder when choosing your input frames?
You've probably guessed why I ask this. Once I got a very strange output from ZS, and the reason is that the program is smart enough to include images in subfolders that are included in a selection of input images. I, on the other hand, was dumb enough to accidentally include a subfolder full of outtakes when I highlighted, clicked, and dragged images into Zerene Stacker.
It's probably not the case here, but perhaps worth bringing up.
Cheers,
--Chris
In the meantime, I have a stray thought that maybe a single, very overexposed image in your stack is throwing the whole thing off. Have you looked at the thumbnails for your set of images to see if there is a dud hiding somewhere within the set? Probably you have. In that case, do you by chance have a sub-folder within the folder that holds your 45 images? Does that subfolder happen to have outtake shots from when you were testing exposure, and perhaps contain a frame with strong overexposure? If so, could you have accidentally highlighted this folder when choosing your input frames?
You've probably guessed why I ask this. Once I got a very strange output from ZS, and the reason is that the program is smart enough to include images in subfolders that are included in a selection of input images. I, on the other hand, was dumb enough to accidentally include a subfolder full of outtakes when I highlighted, clicked, and dragged images into Zerene Stacker.
It's probably not the case here, but perhaps worth bringing up.
Cheers,
--Chris
-
rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Yep, we've been talking by email too. I suggested underexposed, but I guess overexposed could do it also. To isolate the problem, I suggested putting a checkmark on "Show as adjusted" and looking for the image with weird colors.
That case of accidentally dragging in a subfolder hadn't occurred to me. Adding the subfolder's images is "by design" in the sense that dragging in any folder is supposed to add the images it contains, but I never thought about the case of dragging in images and a folder at the same time. Thanks for the heads-up.
--Rik
That case of accidentally dragging in a subfolder hadn't occurred to me. Adding the subfolder's images is "by design" in the sense that dragging in any folder is supposed to add the images it contains, but I never thought about the case of dragging in images and a folder at the same time. Thanks for the heads-up.
--Rik
Rik, I was certain this was by design, and appreciate it as a useful feature. I chalked my experience up to "user error," and ever since, have kept my outtakes in a folder that is not a subfolder of the folder containing the stack. It just had me scratching my head for a few minutes, once upon a time.rjlittlefield wrote:Adding the subfolder's images is "by design" in the sense that dragging in any folder is supposed to add the images it contains, but I never thought about the case of dragging in images and a folder at the same time. Thanks for the heads-up.
--Chris
Sorry for having 2 threads on this. One originally did not show up so I thought I might have refreshed the page before it got posted.
Anyway, it's definitely not an overexposed image. They were lit by studio flash and the photogenic lights I use are very consistent and the histograms are all very close. Now, I do think that images are all slightly overexposed in that some highlight detail is lost but I'm not seeing the noise in those areas. The noise is all in darkest shadow areas.
I didn't drag a folder in either. This is probably the worst example of this type of noise but I have been getting similar noise in some other images too that contained > 20 images though nothing as severe as in this one but it's not unusual for me to have to touch up 20-30 red or orange dots. At first I thought it was sensor dust but it shows up on any color background and I did a test sky shot at F22 and didn't see a significant dust problem and the noise, when it occurs is not in a predictable pattern. I think
Anyway, it's definitely not an overexposed image. They were lit by studio flash and the photogenic lights I use are very consistent and the histograms are all very close. Now, I do think that images are all slightly overexposed in that some highlight detail is lost but I'm not seeing the noise in those areas. The noise is all in darkest shadow areas.
I didn't drag a folder in either. This is probably the worst example of this type of noise but I have been getting similar noise in some other images too that contained > 20 images though nothing as severe as in this one but it's not unusual for me to have to touch up 20-30 red or orange dots. At first I thought it was sensor dust but it shows up on any color background and I did a test sky shot at F22 and didn't see a significant dust problem and the noise, when it occurs is not in a predictable pattern. I think
OK, I found the image that was causing the noise. It appears this image has a slightly lower histogram value than all the other ones. It looks like my fill flash did not trigger on this one. However, with "show as adjusted" checkbox filled in, the image has extreme noise when I click on the particular image in the stack but the original image looks fine other than being slightly underexposed compared to the rest of the stack. Is this the expected behavior?
Here is a picture of the image in question as processed by zerene next to the same image opened in photoshop.
Here is a picture of the image in question as processed by zerene next to the same image opened in photoshop.
-
rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Without seeing a good exposure also, I can't tell whether this is "expected" behavior. But I'm certainly not surprised. When your fill flash didn't trigger, it changed the distribution of light across the image, probably leaving a very dark background (full of RGB=[0,0,0] as shown by your screen capture). The ZS brightness correction algorithm does not look at distribution across the scene, only within the histogram. It does its best to match histograms, using an approach very much like a Photoshop levels adjustment, changing the center and right sliders so as to match mean and variance of the luminance channel. But with a lot of the background gone black, an extreme adjustment was required to match the statistics, blowing up noise in the background and causing the foreground to clip or maybe even wrap.
The best solution is probably to leave that one image out of the stack and accept the possibility of a blurred band where the bad image was focused. You could also leave the image in and turn off brightness adjustment by removing the default checkmark on Options > Preferences > Alignment > Brightness, but with DMap that's pretty much guaranteed to leave you with an obvious dark band where the dark image is focused.
It's hard to say whether a good stack will give you better results with Brightness checked or not. That depends on how stable your flash units are. If they're very stable, it's better to not brightness correct, but if they vary a little bit from flash to flash, it's better to correct because this avoid brightness banding. Typically there's a bit of variation, which is why brightness correction is turned on by default.
--Rik
The best solution is probably to leave that one image out of the stack and accept the possibility of a blurred band where the bad image was focused. You could also leave the image in and turn off brightness adjustment by removing the default checkmark on Options > Preferences > Alignment > Brightness, but with DMap that's pretty much guaranteed to leave you with an obvious dark band where the dark image is focused.
It's hard to say whether a good stack will give you better results with Brightness checked or not. That depends on how stable your flash units are. If they're very stable, it's better to not brightness correct, but if they vary a little bit from flash to flash, it's better to correct because this avoid brightness banding. Typically there's a bit of variation, which is why brightness correction is turned on by default.
--Rik
-
rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Thanks. The background here is much brighter, around [26,19,17] vs [0,0,0] for the one where the flash failed.
In more detail... Working from this last image and the failed-flash one shown earlier, here are the the images and corresponding histograms. Failed on the left, good on the right.
Actually the histogram on the left is more extreme than it appears from the graph. As shown by the cursor and the stats, over 60% of the pixels have value 0,0,0. If Photoshop had not clipped the top off the graph, there would be a spike at value 0 tall enough to stick through the roof.
Given this extreme difference in the shapes of the histograms, I'm not at all surprised that trying to match them ended up producing nonsense. I would have to revisit the math with the actual images in hand to understand why it's this particular nonsense and not some other, but that seems like a low-value exercise considering that there's no way to make these images actually match.
--Rik
In more detail... Working from this last image and the failed-flash one shown earlier, here are the the images and corresponding histograms. Failed on the left, good on the right.
Actually the histogram on the left is more extreme than it appears from the graph. As shown by the cursor and the stats, over 60% of the pixels have value 0,0,0. If Photoshop had not clipped the top off the graph, there would be a spike at value 0 tall enough to stick through the roof.
Given this extreme difference in the shapes of the histograms, I'm not at all surprised that trying to match them ended up producing nonsense. I would have to revisit the math with the actual images in hand to understand why it's this particular nonsense and not some other, but that seems like a low-value exercise considering that there's no way to make these images actually match.
--Rik
Thanks so much for the detailed explanation Rick. I think it'd be an interesting programming problem to look at and perhaps have a checkbox for correcting. I will try unchecking the brightness option and see if that achieves what I am asking for.
I have another question unrelated to this issue.
I have been using an online DOF chart to calculate the distance between exposures for my stacks. That's what I used to create the 1mm spaced exposures for this image in the first place. However, when I re-stacked this project using every 4th image, I was changing the spacing from every 1mm to every 4mm and still the focusing stack looks smooth to me. This is telling me that the DOF chart is showing me a more narrow DOF than what is actually required to create a good focusing stack.
Is there an article discussing this in any detail? Obviously, I'd like to make the minimum of exposures for a given stack in order to maintain a smooth and consistent focus.
I have another question unrelated to this issue.
I have been using an online DOF chart to calculate the distance between exposures for my stacks. That's what I used to create the 1mm spaced exposures for this image in the first place. However, when I re-stacked this project using every 4th image, I was changing the spacing from every 1mm to every 4mm and still the focusing stack looks smooth to me. This is telling me that the DOF chart is showing me a more narrow DOF than what is actually required to create a good focusing stack.
Is there an article discussing this in any detail? Obviously, I'd like to make the minimum of exposures for a given stack in order to maintain a smooth and consistent focus.
-
rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
Been using http://www.dofmaster.com/dofjs.htmlrjlittlefield wrote:There are a lot of articles on DOF, but since you've already done a calculation, I'd like to start there and understand what went wrong.
What calculator did you use, and what numbers did you stick into it?
--Rik
I plugged in 12", F8, 100mm, DOF = 1.5mm
-
rjlittlefield
- Site Admin
- Posts: 23034
- Joined: Tue Aug 01, 2006 8:34 am
- Location: Richland, Washington State, USA
- Contact:
That's a popular calculator, so it's probably not "wrong". But it's remarkably easy to plug in numbers that don't represent the situation you really have.
Let's walk through this and see what happens.
I've tried to reproduce your numbers here:
Multiplying 0.07 inches by 25.4 mm per inch, I get a calculated DOF of 1.8 mm, not quite equal to your 1.5mm but pretty close.
Now let me do the calculation independently, using what I believe are dofmaster's assumptions.
I think dofmaster uses a "thin lens" model in which "subject distance" means distance from the lens. In that case, 12 inches (305 mm) in front of a 100 mm lens implies that the image is formed 149 mm in back of the lens. That implies an image magnification of 0.49 (half life size).
Then I'll use the standard macro DOF formula that total depth of field is
TDF = 2*C*f_r*((m+1)/(m*m))
Plugging in C=0.019 (circle of confusion), m=0.49 (magnification) and f_r = 8 (F8 ), this calculation gives a result of 1.9 mm.
I think that my calculation of 1.9 mm is close enough to dofmaster's 1.8 mm to claim that I've reproduced their number.
The problem is, I'm pretty sure I haven't described your situation. At m=0.49, the subject field would be less than 2 inches across. But your flower appears to me quite a bit bigger than that. I'm guessing a subject field of more like 4 inches?
If the subject field is 4 inches wide, and you're using a crop-factor sensor as I've assumed above, then your actual magnification is only about 0.22 (=22.3/(4*25.4)). Plugging m=0.22 into the formula then gives TDF=7.66 mm, over 4 times as much as the dofmaster number. If the subject field is even bigger, say 6 inches, then the TDF would be over 16 mm.
You can see from the numbers that macro depth of field depends strongly on magnification.
I've always found that it's difficult to describe my setups in terms that really make sense to most DOF calculators, so I generally go with the basic formula for ballpark, then either a) be conservative and use a step that's smaller than calculated, or b) directly measure the required step by looking very close at LiveView images or by shooting a short test stack first.
There are other difficulties in trying to get an accurate number from calculation. It matters, for example, whether you're using Canon or Nikon, and even which Nikon lens, because at macro magnifications F8 simply doesn't mean the same thing on Nikon that it does on Canon. Canon uses nominal lens aperture, while new Nikons use effective aperture as corrected for the extension. There's a factor of 2 difference at 1:1. At higher magnifications pupil factor matters too. Again, these difficulties make me very skeptical of any DOF number that's been calculated and not confirmed by measurement.
Best recommendation: calculate for ballpark, measure for accuracy.
Is this helping?
--Rik
Let's walk through this and see what happens.
I've tried to reproduce your numbers here:
Multiplying 0.07 inches by 25.4 mm per inch, I get a calculated DOF of 1.8 mm, not quite equal to your 1.5mm but pretty close.
Now let me do the calculation independently, using what I believe are dofmaster's assumptions.
I think dofmaster uses a "thin lens" model in which "subject distance" means distance from the lens. In that case, 12 inches (305 mm) in front of a 100 mm lens implies that the image is formed 149 mm in back of the lens. That implies an image magnification of 0.49 (half life size).
Then I'll use the standard macro DOF formula that total depth of field is
TDF = 2*C*f_r*((m+1)/(m*m))
Plugging in C=0.019 (circle of confusion), m=0.49 (magnification) and f_r = 8 (F8 ), this calculation gives a result of 1.9 mm.
I think that my calculation of 1.9 mm is close enough to dofmaster's 1.8 mm to claim that I've reproduced their number.
The problem is, I'm pretty sure I haven't described your situation. At m=0.49, the subject field would be less than 2 inches across. But your flower appears to me quite a bit bigger than that. I'm guessing a subject field of more like 4 inches?
If the subject field is 4 inches wide, and you're using a crop-factor sensor as I've assumed above, then your actual magnification is only about 0.22 (=22.3/(4*25.4)). Plugging m=0.22 into the formula then gives TDF=7.66 mm, over 4 times as much as the dofmaster number. If the subject field is even bigger, say 6 inches, then the TDF would be over 16 mm.
You can see from the numbers that macro depth of field depends strongly on magnification.
I've always found that it's difficult to describe my setups in terms that really make sense to most DOF calculators, so I generally go with the basic formula for ballpark, then either a) be conservative and use a step that's smaller than calculated, or b) directly measure the required step by looking very close at LiveView images or by shooting a short test stack first.
There are other difficulties in trying to get an accurate number from calculation. It matters, for example, whether you're using Canon or Nikon, and even which Nikon lens, because at macro magnifications F8 simply doesn't mean the same thing on Nikon that it does on Canon. Canon uses nominal lens aperture, while new Nikons use effective aperture as corrected for the extension. There's a factor of 2 difference at 1:1. At higher magnifications pupil factor matters too. Again, these difficulties make me very skeptical of any DOF number that's been calculated and not confirmed by measurement.
Best recommendation: calculate for ballpark, measure for accuracy.
Is this helping?
--Rik