A new tool for the production of high quality output

[Bart_van_der_Wolf]

Hi folks,

As serious photographers, we are occasionally faced with shooting scenarios that we have less experience with compared to our usual subject choices. It can be helpful if we can test several setup scenarios before doing the actual shoot.

How large can we print, which lenses do we need, how much of the subject will be in critical focus? Those are just some of the questions we may want to be able and answer in advance, and go in prepared.

Many, if not all, of those questions can be answered with the use of so-called Depth of Field calculators. Several of those calculators are available on the internet, or as a dedicated application, also for smartphones and tablets. However, one of the biggest shortcomings of those calculators is that they require to input an important calculation parameter, the so-called Circle of Confusion diameter limit, but they do not offer any guidance as to what value is best to use.

In fact, most of them offer preset values based on the selected camera model, thus totally ignoring the intended output quality requirements and viewing conditions. Producing large format output requires different settings than those required for producing images for a webpage. The one-size-fits-all approach doesn't fit at all if quality is your concern.

 "It's a DoF calculator, Jim, but not as we know it."

The tool I am offering is a bit different. Of course it uses the same fundamental algorithms to calculate the physical consequences of lens settings such as focus distance and aperture, but it does so with our intended shooting goals and available equipment in mind. It also applies some automatic refinements, e.g. when diffraction is a limiting factor.

Therefore those shooting and viewing goals need to be determined as a first step, and the available equipment as the second, with a few simple selections. Only then will we be able to do meaningful calculations. The results of those calculations may occasionally surprise us because the calculated results are goal specific, instead of generic. That's particularly useful in uncommon shooting situations.

The tool will try and stay close to the input that was given earlier, if possible, therefore the order in which the input changes are made matters. Some of the choices will alter prior input, which is inevitable because everything is part of a single possible solution.

The fastest way to achieve the result we are looking for is to follow the sequential settings from top to bottom, that's why I've numbered them, unless one of the later parameters is already known to be a given.

An example is the choice of aperture / f-number, e.g. if the optimum lens performance is more important than the creative DoF consequences (e.g. in case of reproductions), then by all means select it first, and the rest of the parameters will follow this setting, unless the tool is forced by your
subsequent input to adjust the aperture again.
 
Another example is with Photomacrography, where it is often more logical to set the magnification factor first, and then move the subject into the focus-range. Then by all means, set the focal length of your macro lens, and the magnification factor first.

To simplify this first setup, I've provided a number of generic shooting setups that you can choose from with a pull down menu. Those settings will get you in-the-ball-park.

Now, without much further ado, here is the link to the on-line web application:
The Depth of Field output quality planner

As of this posting, it's a beta-testing version release, although I've tried to already eliminate as many potential issues as possible. It was tested on several web-browsers, and I've also built in some prevention for overly 'creative' input, such as negative distances. Under very rare input situations, I hope, one may run into an issue. In that case pick one of the generic scenarios to get a fresh starting situation. Refreshing the web page will ultimately solve any issue, but also requires to redo all input from the beginning.

I welcome user feedback, it will help to make it an even more useful tool.

Cheers,
Bart

[jrsforums]

Hi, Bart.....


Need this in an iPhone app  :-)

[Bart_van_der_Wolf]

Need this in an iPhone app  :-)

Hi John,

I know that would make it easier to use on a phone, but it would also open a whole other can of worms on my side, getting it done. To name one, I don't have an iPhone ... Another is that the number of Android phones (which I do have) and Tablets have already overtaken the iPhone/iPad share in my neck of the woods, so I would have to prioritize on at least two platforms.

Anyway, you can just open the tool as it is on a browser tab, and leave that tab open. The tool doesn't phone home after it has loaded, so you can just carry it along, even without cellphone connection.

Cheers,
Bart 

[eronald]

It's encouraging to see some original stuff appear here.

Edmund

Hi John,

I know that would make it easier to use on a phone, but it would also open a whole other can of worms on my side, getting it done. To name one, I don't have an iPhone ... Another is that the number of Android phones (which I do have) and Tablets have already overtaken the iPhone/iPad share in my neck of the woods, so I would have to prioritize on at least two platforms.

Anyway, you can just open the tool as it is on a browser tab, and leave that tab open. The tool doesn't phone home after it has loaded, so you can just carry it along, even without cellphone connection.

Cheers,
Bart 

[Alan Smallbone]

Great tool Bart, thanks so much for doing it. An android app would be great but I will see how it works from the phone as you mentioned it.

Thanks again for all that you contribute.

Alan

[Bart_van_der_Wolf]

It's encouraging to see some original stuff appear here.

Hi Edmund,

I most certainly wanted to avoid the YADOFC (yet another Depth of Field calculator) syndrome, but even more than that solve  some missing links in the use of the concept.

People seem to rarely stop and think about what value of COC to use, and why. Many phone apps even come with fixed values based on camera model, but that's pretty useless, IMHO of course.

I've also built in some informational feedback about diffraction effects, and ultimately even apply an adjustment to the COC when diffraction totally limits resolution (MTF=0). It's all automatic.

Cheers,
Bart

[Bart_van_der_Wolf]

Great tool Bart, thanks so much for doing it. An android app would be great but I will see how it works from the phone as you mentioned it.

Thanks again for all that you contribute.

Hi Alan,

Thanks for the kind words.

I've set the application up with a number of exchangeable lens camera pre-selections, to reduce the need to punch in too many numbers. That should already make things a bit easier when using it as a browser tool. When people let me know that they'd like to have a specific model added, I'll consider that if time permits.

For exchangeable lens cameras and those with a fixed zoomlens that are in the database, I automatically guestimate a standard focal length close to the diagonal of the sensor dimensions, to get a starting point that's somewhat in-the-ballpark. I currently have no provision for camera models with a fixed focal length lens, so one would need to type in the specific (real) focal length for the specific camera.

Cheers,
Bart

[jrsforums]

Bart, for us metric illiterate (well, not illiterate, but need to convert/translate) Americans, would it be a big deal to have an option to show distances in feet?

Thanks...John

[Bart_van_der_Wolf]

Bart, for us metric illiterate (well, not illiterate, but need to convert/translate) Americans, would it be a big deal to have an option to show distances in feet?

Hi John,

I'm working on it, but it requires a lot of additional code testing, and I didn't want to delay the availability due to only that reason. I may add it one input field at a time. It ties in with a question I've asked, and received useful answers about, here on LuLa, concerning which unit conversions one uses in daily life. Yards appeared to be very unpopular, except for some sports related uses.

Since the tool will correctly handle all situations from long lenses to macro,  a lot of different distance units can be produced. The user interface should be able to display that in a compact space, and user input should not require too many leading zeroes to be entered.

The information I received will be used to also do some automatic switching, from inches - to feet - to miles when e.g. the Hyperfocal distance would otherwise start producing excessively large numbers in inches or small ones in feet. Likewise the tool will switch to smaller units when too many zeroes would be produced to depict very small distances or quantities. The algorithms and conversion factors are already in the codebase, now I need to adjust the user interface and add event triggers. As I said, still some work to be done.

Cheers,
Bart


P.S. While it's a bit of cheating, for now you can also use the section 3. copy lens settings button and switch front/rear and focus distance to non-metric equivalents there. When you first set the required units, and then click the copy button, things should display what you want.

[peterv]

Thank you Bart, the unknown/doubtful COC factor has always made these DOF-apps a bit of a rough guide for DOF. Really very helpful!

[Bart_van_der_Wolf]

Thank you Bart, the unknown/doubtful COC factor has always made these DOF-apps a bit of a rough guide for DOF. Really very helpful!

Hi Peter,

You're welcome.

I obviously agree, COC values without being output referred make little sense.

Section 1) of my tool now also make it much easier to answer the question;

• How large can I print a file from camera 'x' ?

Before, the obvious answer was; How large is the paper your printer can handle?
But that didn't say anything about the quality one could expect.

Now we set our required quality level, viewing distance, and camera sensor parameters,
and out comes the maximum print size. Anything larger has lower quality, anything smaller
will have even higher quality. As simple as can be.

Cheers,
Bart

[Peter Stacey]

Hi John,

I know that would make it easier to use on a phone, but it would also open a whole other can of worms on my side, getting it done. To name one, I don't have an iPhone ... Another is that the number of Android phones (which I do have) and Tablets have already overtaken the iPhone/iPad share in my neck of the woods, so I would have to prioritize on at least two platforms.

Anyway, you can just open the tool as it is on a browser tab, and leave that tab open. The tool doesn't phone home after it has loaded, so you can just carry it along, even without cellphone connection.

Cheers,
Bart  

You'd only need some changes to your existing webapp Bart.

I don't think native apps for this would be worth the time as it is all available on your existing webapp.

The problem with using it on an iPhone, Android, Windows or Blackberry phone is the downscaling, which makes interacting with the app difficult on a small screen (though much more useful for use in the field, where people carry phones, but are less likely to have a laptop or iPad, etc. handy).

Adjusting the existing layout with a modified stylesheet would make it more responsive and open up the possibility of having a single webapp that looks and works good on a phone through to a desktop.

No need for native apps (and as for screen emulation, it can all be done in a browser with Dev tools).

Regards,

Peter

[Bart_van_der_Wolf]

The problem with using it on an iPhone, Android, Windows or Blackberry phone is the downscaling, which makes interacting with the app difficult on a small screen (though much more useful for use in the field, where people carry phones, but are less likely to have a laptop or iPad, etc. handy).

Adjusting the existing layout with a modified stylesheet would make it more responsive and open up the possibility of having a single webapp that looks and works good on a phone through to a desktop.

Hi Peter,

Good suggestions, thanks.

I thought you might be concerned about the no cell phone connection part, but apparently not so much. I'll have a look at how a different style sheet may help with the downscaling. On my Android phone rotating the phone 90 degrees to landscape orientation makes things readable at full width (I deliberately tried to keep the width down a bit for this reason, but I can still shave of a few pixels), and when I double tap on the screen it zooms in to full size. Maybe that functions differently on an iPhone, I'd have to check that.

Cheers,
Bart

[eronald]

Hi Bart -

A glance at this neat app leads me to wonder yet again 1) what sort of rez one should use at printing, and 2) how a current digital camera really stacks up compared to film. I wonder if anyone has published and compared the transfer functions of inkjet printing and enlarging?

Edmund

[Bart_van_der_Wolf]

A glance at this neat app leads me to wonder yet again 1) what sort of rez one should use at printing, and 2) how a current digital camera really stacks up compared to film. I wonder if anyone has published and compared the transfer functions of inkjet printing and enlarging?

Hi Edmund,

1) The printer driver dictates the best choice for resampling to native printer resolution. Canon/HP printers require 300 or 600 PPI input for the requested output size, if anything else is received, the printer driver will resample for you, but that robs you of the opportunity to output sharpen at the actual print resolution. Epson printers require 360 or 720 PPI (the finest detail option must also be selected) input, otherwise it will do the resampling itself. One typically resamples up(!) to the nearest PPI

The printer driver resampling is usually not very good (usually bi-linear, or on rare occasions it's plain bi-cubic) and that lowers contrast of micro-detail, for reasons of speed. The lack of control over the output sharpening is my main concern, if one wants optimal quality and images with 'punch' rather than a dull veil.

Therefore my suggestion after the input of section 1.4), to resample the resulting image from the calculated PPI to the native printer PPI, and then apply output sharpening.

2) That is a bit harder to comment on, because film comes in many flavors. But as far as my tool is concerned, you can simply input the actual film image dimensions (e.g. 36x24mm, or 56x56mm, or 120x95mm, if scanned without mask(!)), and the scanned pixel dimensions, and the rest works as expected. It's just a different type of sensor.

The second difficulty with the direct sensor/film quality comparison is that they natively have a markedly different MTF response (with the scanning process adding some more variation). When looking for the limits of resolution (but that's only part of the complete story) a shot on film of my Star test chart with sinusoidal grating will tell the whole story, including the scanner influence (which will also show benefits of scanning at 6000 PPI or a bit more). And it will give you a slanted edge for SFR analysis of the entire imaging chain as well.

As far as the upsampling transfer functions themselves, I've posted some comparisons here on LuLa, with some transfer curves and log Fourier space views of the same crops were added a few posts after that.

Hope that helps.

Cheers,
Bart

[NancyP]

Interesting. I never bothered with other DOF calculators, due to the pre-set CoC - CoC preferences being individual to shooter and intended photo format. In addition to being able to choose CoC, the neat thing here for me is the stack size calculator.

[Bart_van_der_Wolf]

Interesting. I never bothered with other DOF calculators, due to the pre-set CoC - CoC preferences being individual to shooter and intended photo format. In addition to being able to choose CoC, the neat thing here for me is the stack size calculator.

Hi Nancy,

Of course the user should be enabled to choose his/her personal value for the COC parameter which lies at the basis of all Depth of Field calculations. However, a problem can also arise in selecting which COC value to use.

Rather than relying on some mythical value, the user can now let the tool assist in finding the optimal value, especially useful for unfamiliar shooting scenarios. It is still possible to manually override the optimal setting, but I rarely see a good reason because the tool incorporates all sorts of tweaks based on image magnification and/or extremely narrow aperture selections, much more accurately than I can.

The focus stacking part to me, is a natural extension for when we need to bend the laws of physics in our favour. It is also rather revealing, as it shows how many slices may be required to achieve the impossible. Even in the macro region, the slices do not have the same range, so users of automated focus rails are advised to use the narrower slice depth as a guideline. It may lead to some additional slices with overlap were a larger step distance could have been used, but it's better than finding gaps later.

All can be tested in a simulated run, without having to shoot and evaluate a single trial frame. That helps to get better results faster.

Cheers,
Bart

[Misirlou]

Personally, I vote for apps for the devices, because some of us shoot in places far, far from any network connection.

But, Bart would not have to do all that coding himself. It would be easy enough to farm this out to a different developer. If the app takes off, he gets some sales profit. If not, he loses nothing.

So, Bart, I may know an iPhone developer who could put this together for you on that platform. Send me a PM if you're interested.

[eronald]

Personally, I vote for apps for the devices, because some of us shoot in places far, far from any network connection.

But, Bart would not have to do all that coding himself. It would be easy enough to farm this out to a different developer. If the app takes off, he gets some sales profit. If not, he loses nothing.

So, Bart, I may know an iPhone developer who could put this together for you on that platform. Send me a PM if you're interested.

I can do it.

Edmund.

[qwz]

I will be a great tool, but why you don't use fixed dpi settings according to actual printers drivers settings - Epson use 360 or 180-240-360-380-720 steps (and 300 its wrong for Epson driver), HP and Canon use 300/600ppi.
Durst Theta use 254ppi, Lambda 400ppi and so on.