www.photomacrography.net :: View topic - Focus Step calculator WAS: DOF change table for bellows
www.photomacrography.net Forum Index
An online community dedicated to the practices of photomacrography, close-up and macro photography, and photomicrography.
Photomacrography Front Page Amateurmicrography Front Page
Old Forums/Galleries
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
Focus Step calculator WAS: DOF change table for bellows

 
Post new topic   Reply to topic    www.photomacrography.net Forum Index -> Macro and Micro Technique and Technical Discussions
View previous topic :: View next topic  
Author Message
elf



Joined: 18 Nov 2007
Posts: 1385

PostPosted: Sun Sep 13, 2009 3:15 am    Post subject: Focus Step calculator WAS: DOF change table for bellows Reply with quote

Here's a little Excel worksheet that generates a table for bellows draw change per focus step: http://www.efrench.members.winisp.net/programs/DOF-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.


Last edited by elf on Sun Sep 13, 2009 9:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
ChrisR
Site Admin


Joined: 14 Mar 2009
Posts: 8425
Location: Near London, UK

PostPosted: Sun Sep 13, 2009 3:58 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
rjlittlefield
Site Admin


Joined: 01 Aug 2006
Posts: 20279
Location: Richland, Washington State, USA

PostPosted: Sun Sep 13, 2009 5:05 pm    Post subject: Reply with quote

ChrisR wrote:
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
Quote:
=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
Back to top
View user's profile Send private message Visit poster's website
elf



Joined: 18 Nov 2007
Posts: 1385

PostPosted: Sun Sep 13, 2009 9:43 pm    Post subject: Reply with quote

I've uploaded a new version because Chris has already found a bug Sad 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.

rjlittlefield wrote:
ChrisR wrote:
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
Quote:
=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.

rjlittlefield wrote:

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 Smile
Back to top
View user's profile Send private message
rjlittlefield
Site Admin


Joined: 01 Aug 2006
Posts: 20279
Location: Richland, Washington State, USA

PostPosted: Mon Sep 14, 2009 12:22 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
elf



Joined: 18 Nov 2007
Posts: 1385

PostPosted: Mon Sep 14, 2009 1:47 am    Post subject: Reply with quote

rjlittlefield wrote:
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.


rjlittlefield wrote:

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 Smile I've updated the online copy.
Back to top
View user's profile Send private message
rjlittlefield
Site Admin


Joined: 01 Aug 2006
Posts: 20279
Location: Richland, Washington State, USA

PostPosted: Mon Sep 14, 2009 8:22 am    Post subject: Reply with quote

elf wrote:
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
Back to top
View user's profile Send private message Visit poster's website
elf



Joined: 18 Nov 2007
Posts: 1385

PostPosted: Tue Sep 15, 2009 12:01 am    Post subject: Reply with quote

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. Smile


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/programs/DOF-Macro2.xlsx
Back to top
View user's profile Send private message
ChrisR
Site Admin


Joined: 14 Mar 2009
Posts: 8425
Location: Near London, UK

PostPosted: Tue Sep 15, 2009 12:23 am    Post subject: Reply with quote

Yes, that appears to work on my steam powered pc!
Quote:
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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    www.photomacrography.net Forum Index -> Macro and Micro Technique and Technical Discussions All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group