Focus Step calculator WAS: DOF change table for bellows

[elf]

Here's a little Excel worksheet that generates a table for bellows draw change per focus step: http://www.efrench.members.winisp.net/p ... Macro.xlsm
Please note that it does have a macro in it, so your virus checker may complain when downloading it.

Here's a screenshot of a small section of it:


Hopefully there is enough documentation in the commented cells to understand it, if not, please send PM or reply to this thread.

The defaults are set for 4/3rds sensor (Olympus e330) and El-Nikkor 50mm enlarger lens.

[ChrisR]

Nice! It works after, as you say, overriding the warning.

I think I follow it all, needs more chin-scratching.

Do you find you need to use a figure for DOF as shallow as 1.5 times pixel size?
I don't, which probably means I'm introducing enough blurs from elsewhere that I can't tell the difference!

[rjlittlefield]

Do you find you need to use a figure for DOF as shallow as 1.5 times pixel size?

Are you talking about cell D7, the one named "COC" but labeled "COC * COC Multiplier", whose definition is =(SensorWidth/Pixels)*COCMultiplier ?

That cell feeds into the DOF calculation, but the actual value for DOF will end up much larger, depending as usual on magnification and f-number.

The spreadsheet seems to be using the standard DOF formula from Lefkowitz.

Lefkowitz writes it as TDF = 2*C*f_r*(m+1)/(m*m).

The spreadsheet has it as

=2*COC*Fstop*((ChangeTable[[#This Row],[Magnification]]+1)/(ChangeTable[[#This Row],[Magnification]]*ChangeTable[[#This Row],[Magnification]]))

which looks like it does the same thing given the way elf has the names defined.

Formula-reading aside, the spreadsheet also produces the same result that I get when I plug the spreadsheet's numbers into Lefkowitz's formula. With C=0.0082749, m = 0.1533, and f_r=5.6 as shown in elf's spreadsheet, Lefkowitz's formula produces 4.5482, where elf's spreadsheet shows 4.5488 (column I, row 17). The difference seems to be caused by rounding in the displayed values.

--Rik

[elf]

I've uploaded a new version because Chris has already found a bug The spreadsheet uses new features in Excel 2007 and the macro breaks in Excel 2002. I've added a single step macro that processes a row at a time by pressing <CTRL f> that should take care of the problem.

Do you find you need to use a figure for DOF as shallow as 1.5 times pixel size?

Are you talking about cell D7, the one named "COC" but labeled "COC * COC Multiplier", whose definition is =(SensorWidth/Pixels)*COCMultiplier ?

That cell feeds into the DOF calculation, but the actual value for DOF will end up much larger, depending as usual on magnification and f-number.

The spreadsheet seems to be using the standard DOF formula from Lefkowitz.

Lefkowitz writes it as TDF = 2*C*f_r*(m+1)/(m*m).

The spreadsheet has it as

=2*COC*Fstop*((ChangeTable[[#This Row],[Magnification]]+1)/(ChangeTable[[#This Row],[Magnification]]*ChangeTable[[#This Row],[Magnification]]))

which looks like it does the same thing given the way elf has the names defined.

Yes, that's the formula I'm using. I haven't started experimenting with a larger COC, or to put it another way, a larger focus step. I think the 1.5x COC combined with the 20% overlap will give you close to the theoretical minimum focus step size. It will give you more images per stack, but will also have more tolerance for errors in single frames. If one image out of a stack of 100 had camera movement , and you were using the maximum focus step size, the entire focus stack may be bad (but this would depend on the quality required). For me the processing time to do a few more or even double the number of images is much less than shooting an entire new stack, especially when doing panoramas of plants which tend to move over time.

Formula-reading aside, the spreadsheet also produces the same result that I get when I plug the spreadsheet's numbers into Lefkowitz's formula. With C=0.0082749, m = 0.1533, and f_r=5.6 as shown in elf's spreadsheet, Lefkowitz's formula produces 4.5482, where elf's spreadsheet shows 4.5488 (column I, row 17). The difference seems to be caused by rounding in the displayed values.

It could be that I'm using a double instead of a floating point to store the values. This could lead to rounding errors. I suspect that sub-micron errors probably won't bother too many people

[rjlittlefield]

elf, I'm a little confused here. Bear with me, please.

First off, let me make sure I understand the situation you're trying to handle.

I think you're working with a bellows setup that focuses by moving the camera, that is, changing the camera-to-lens distance. With that kind of setup, magnification onto the sensor changes along with focus. As you draw the camera back, the magnification gets greater, hence the DOF gets smaller. Thus in order to get a constant percentage overlap, you need to move the focus plane a smaller amount also. The challenge is to determine exactly how much to change the bellows draw -- the camera-to-lens distance -- in order to maintain constant percentage overlap of the in-focus slabs.

Have I got that right so far?

Assuming so, then I gather that the purpose of the spreadsheet is to calculate bellows draws that maintain that constant percentage overlap.

Further complicating the issue is that it's physically difficult and error-prone to set the bellows draw to arbitrary values. Hence, I gather you've decided that a good approximation is to change the bellows draw by easily set amounts that correspond to nice fractions of a full turn on some dial. Those amounts (in the current spreadsheet) range from 0.025 mm at 1/32 turn, up to 0.400 mm at 1/2 turn. Each of the easily set amounts is assigned a color code, and the table of computed draws is correspondingly color-coded in big blocks.

Now I'm trying to imagine the workflow.

I choose my parameters and plug them into the table at the top of the spreadsheet. For the sake of experiment, I choose f/4. Then I push the "Recalculate the Table" button and wait until the table is recalculated. This requires 9-1/2 minutes on my 1-year-old quad-core 2.4 GHz processor using Excel 2007. When the table is completed, it contains a list of ScaleReadings.

Then I guess I set the bellows to the first ScaleReading and take my first picture. To advance from picture to picture, I look at where the bellows is currently, find the closest ScaleReading, look at the color of the corresponding change, and advance the dial by the appropriate part of a turn. This process continues, using a constant step size, until the bellows has advanced into a different color block, at which point the step size changes. Then the process continues, using that new step size.

Am I still on track? I ask because if I'm not, then I'm seriously confused, and if I am, then I'm still pretty confused because the color codes seem wrong. At the top of the table, the steps are around 0.0615 and they're coded green, but the green intervals are 0.100. So if I make a "green" step (0.100 mm), then I've moved too far and lost my overlap. Likewise, much farther down, the steps get big enough to transition from green to yellow, but that happens at a point where the required step as computed is 0.100 but the new physical step will be 0.133.

Obviously I'm missing something here. Can you clear up my confusion?

--Rik

[elf]

elf, I'm a little confused here. Bear with me, please.

First off, let me make sure I understand the situation you're trying to handle.

I think you're working with a bellows setup that focuses by moving the camera, that is, changing the camera-to-lens distance. With that kind of setup, magnification onto the sensor changes along with focus. As you draw the camera back, the magnification gets greater, hence the DOF gets smaller. Thus in order to get a constant percentage overlap, you need to move the focus plane a smaller amount also. The challenge is to determine exactly how much to change the bellows draw -- the camera-to-lens distance -- in order to maintain constant percentage overlap of the in-focus slabs.

Have I got that right so far?

Assuming so, then I gather that the purpose of the spreadsheet is to calculate bellows draws that maintain that constant percentage overlap.

Further complicating the issue is that it's physically difficult and error-prone to set the bellows draw to arbitrary values. Hence, I gather you've decided that a good approximation is to change the bellows draw by easily set amounts that correspond to nice fractions of a full turn on some dial. Those amounts (in the current spreadsheet) range from 0.025 mm at 1/32 turn, up to 0.400 mm at 1/2 turn. Each of the easily set amounts is assigned a color code, and the table of computed draws is correspondingly color-coded in big blocks.

Now I'm trying to imagine the workflow.

I choose my parameters and plug them into the table at the top of the spreadsheet. For the sake of experiment, I choose f/4. Then I push the "Recalculate the Table" button and wait until the table is recalculated. This requires 9-1/2 minutes on my 1-year-old quad-core 2.4 GHz processor using Excel 2007. When the table is completed, it contains a list of ScaleReadings.

Then I guess I set the bellows to the first ScaleReading and take my first picture. To advance from picture to picture, I look at where the bellows is currently, find the closest ScaleReading, look at the color of the corresponding change, and advance the dial by the appropriate part of a turn. This process continues, using a constant step size, until the bellows has advanced into a different color block, at which point the step size changes. Then the process continues, using that new step size.

That's right. I'm not so much concerned about having equal steps or overlap as making sure each step is smaller than the DOF for that image. Live View is definitely not good enough to judge DOF accurately.

I'm mystified why it would take so long on your computer. It usually only takes a minute or two on mine. (Dual Core X86 with 4gb of memory)


My workflow is usually:
1. Select the magnification or closest focus point on the subject. This also sets the composition.
2. Verify there is enough camera movement to get the farthest desired point in focus.
3. Set the bellows draw to ScaleReading for the focus point selected in step 1.
4. Enter the table to find the focus step. Usually I just use the color code to decide how far to step.
5. Snap the shutter.
6. Move the camera the specified amount.
7. I have the points marked on the bellows scale where to switch to the next focus step size. The scales just slip in and out so it's real easy to create a custom scale for each lens and aperture setting. I also have the dial that drives the leadscrew marked with the same divisions as the color coded table.
8. Repeat steps 5 and 6 until the frame is done.

There are several advantages to moving just the camera instead of the camera and lens as a unit or moving the subject.
1. The movement is a lot larger for each step at higher magnifications. For example at 2X the step would be 0.222 or 90 degrees compared to .0692 or 22.5 degrees. At higher magnifications this would be a much larger difference.
2. Having the lens in a fixed spot allows panoramas to easily be stitched

The table will work for determining the focus step where the camera and lens move as a unit or the subject is moved. Just use the setting in the DOF column for the magnification desired instead of the Change column to set the focus step.

Am I still on track? I ask because if I'm not, then I'm seriously confused, and if I am, then I'm still pretty confused because the color codes seem wrong. At the top of the table, the steps are around 0.0615 and they're coded green, but the green intervals are 0.100. So if I make a "green" step (0.100 mm), then I've moved too far and lost my overlap. Likewise, much farther down, the steps get big enough to transition from green to yellow, but that happens at a point where the required step as computed is 0.100 but the new physical step will be 0.133.

Obviously I'm missing something here. Can you clear up my confusion?

--Rik

You're right, I used a less than instead of a greater than symbol in the color coding section. My excuse was it was late at night I've updated the online copy.

[rjlittlefield]

I'm mystified why it would take so long on your computer. It usually only takes a minute or two on mine. (Dual Core X86 with 4gb of memory)

Yeah, that's definitely mysterious. The behavior on my quad-core Q6600 is that it hangs two cores solid, no page faults, no I/O, straight computation. I tried on an older machine and it runs much faster. If I get a chance, I'll try it later today on some other configurations.

We may never get to the root of the performance problem. I've noticed before that Excel macros can run at quite different speeds on different machines and different versions of Excel.

Back in 1996 I programmed up a slick little animation using a macro to update the coordinates of a few points on a graph. That worked like a charm -- right up until Microsoft did something to the guts of Excel that made it run about 30X slower. Boom! I never did figure out a way to work around that problem, just had to wait for machine speeds to catch up. Then came Excel 2007, and now the simulation won't run at all due to some compatibility issue that I haven't bothered to figure out yet.

Too many experiences like that have taught me to think carefully about the tradeoffs of spreadsheet macros. They tend to be fragile and they're much less transparent than spreadsheet formulas.

In the current spreadsheet, I can't see that you're actually getting much value from the macro. Your computational strategy is to Goal Seek for the next setting needed to provide the proper DOF overlap. But there's a direct computation that does the same thing:

newObjectDistance = previousObjectDistance - previousDOF*DOFOverlapPercentage
newExtension = 1/(1/FocalLength - 1/newObjectDistance)

For edification, I tried replacing your formulas for ObjectDistance, Extension, and ScaleReading with spreadsheet formulas based on the direct computation. The resulting table reproduces your numbers quite closely, updates in a fraction of a second, and does not have any of the security and portability issues associated with macros. Another way to skin the cat, I guess.

--Rik

[elf]

Here's the scale I use on the lead screw dial. It was done in VisualCadd. It does look better with a white background and all of the markings in black.


The smallest division will move the camera .00625mm, but I don't have any lens that can use that small of a step.


I've also added a version of the spreadsheet that doesn't use macros: http://www.efrench.members.winisp.net/p ... acro2.xlsx

[ChrisR]

Yes, that appears to work on my steam powered pc!

I don't have any lens that can use that small of a step

Hits the limits with a scope lens around 10x, or a 20mm wide open.