Adobe Photoshop Lightroom Tutorial - Part XV - Speeding Up Your Workflow Using Presets and the Painter Tool

Part I - Index and Introduction
Part XVI - Saving And Migrating Your Adobe Lightroom Presets

In previous parts of this series we've already seen how Lightroom lets you save a set of configuration options into a reusable entity. In Part XIII and Part XIV, for example, we've used two adjustment brushes to improve both the iris and the sclera (the eye white) of our model. As you've seen, you can save the definition of a brush and reuse it whenever you need it.

In this part, we will see how we can use a similar technique to speed up and greatly simplify your workflow when using Lightroom presets.

What a Preset Is

A preset is a set of configurations that can bulk-applied to a group of photos at a time, which is something you find yourself doing more often than not. Lightroom let you define two kinds of presets:

• Develop preset.
• Metadata presets.

As their names imply, a develop preset is a set of develop configuration options and a metadata preset is a set of metadata values such as EXIF and IPTC metadata. In both cases, Lightroom lets you specify a value for every option available in the corresponding set. If you're defining a develop preset, for example, you will be able to specify the value for each and every option that you find in the Develop module.

Every time you find yourself during repetitive work it's a good opportunity to consider creating a preset. Common situations in which you can take advantage of  a preset are, for example:

• Adding location, contact or copyright metadata.
• Applying the same basic tone adjustment to a set of photos taken under the same exposure condition.
• Applying the same color temperature and tint adjustment to a set of photos taken under the same lightning conditions.
• Applying the same lens correction parameters to a set of photos taken with the same lens.
• Applying the same camera calibration parameters to a set of photos taken with the same lightning conditions.

How To Create a Develop Preset

To create a develop preset, you have to follow the following steps:

• Open a photo in the Develop module.
• Apply the settings you want to save in a preset. During this step you can safely ignore the values for the options you don't want to include in the new preset.
• Select the Develop/New Preset… menu item or click the "+" button in the upper right corner of the Presets panel, as shown in the following image.

Develop Module - Detail of the Presets Panel

• Lightroom will show you the New Develop Preset window.

New Develop Preset Window

• Introduce a name for your new preset.
• Choose the folder where you want to store your preset. By default, Lightroom suggests you use the User Presets folder but you may create a folder hierarchy using the Develop/New Preset Folder… menu item or the New Folder… item in the Folder listbox of the New Develop Preset window.
• Choose the settings you want to save in your preset. In the previous image, for example, we've chose the Noise Reduction settings, the Lens Corrections settings and the camera Calibration settings because we want to automate this corrections for a set of photos taken to the same subject in a single session with the same camera, the same lens, the same ISO sensibility and the same lightning conditions.
• Select the Create button to create the new preset.

Once you've created a new preset, it will appear in the presets hierarchy shown into the Presets panel of the Develop module.

How To Create a Metadata Preset

The steps you need to follow to create a metadata preset are conceptually very similar to those required to create a develop preset: you need to customize the metadata of a photo and use it to create a new metadata preset. The procedure is the following:

• Choose a photo in the Library module.
• Apply the metadata you want to save in a preset. During this step you can safely ignore the value for the metadata key you don't want to include in the new preset.
• Select the Metadata/Edit Metadata Presets… menu item or the Edit Preset… item in the Preset listbox at the top of the Metadata panel (shown in the following picture).

Library Module - Detail of the Metadata Panel

• Lightroom will show you the Edit Metadata Presets window.

Edit Metadata Presets Window

• Check the metadata keys you want to include in the new preset.
• Select the Save Current Settings As New Presets… item in the Preset listbox at the top of the window and introduce a name for the new preset.

Once you've created a new metadata preset, it will appear in the Preset listbox in the Metadata panel.

Using Presets

Presets can be used in a variety of way, depending on the stage of your workflow you're in.

In the Library module, you can apply presets in three ways:

• You can select one or more photos, right-click on them and choose the preset you want to apply from the Develop Settings or from the Metadata Presets submenus. Be aware that Lightroom will show user defined presets at the bottom of the submenus. If you've got plenty of them, don't panic: there they are, but you will have to scroll the entire submenu down. While this is pretty easy on a Mac, it is a pretty clumsy procedure on Windows.
• You can choose the metadata preset you want to apply from the Preset listbox in the Metadata panel.
• You can use the Painter tool (which is found in the toolbar, see Part II of this tutorial) to paint a preset on the photos you choose. If you can't find the toolbar, enable it using the View/Toolbar menu item or directly select the Painter tool using the Metadata/Enable Painting menu item.

You will choose the most suitable method depending on the situation. If, for example, you need to apply a preset to all of the photos in a folder or to a large set of easily selectable photos, choosing them all and right clicking on them is surely the quicker way to do it. If, on the other hand, you're reviewing your photos one by one in the Library grid view, the Painter tool will be more appropriate than an infinite series of right clicks.

Using The Painter Tool

The painter tool, although somewhat hidden, is a pretty powerful tool that will let you "spray" not only presets, but a larger set of adjustments over a photo. In the current Lightroom release (v. 3), the painter tool lets you apply the following kind of adjustment to a photo:

• Keywords.
• Label.
• Flag.
• Rating.
• Metadata.
• Settings.
• Rotation.
• Target Collection.

This tool is very handy when you're reviewing your photos on the Library grid view in whichever stage of your workflow. Sometimes, you will use it at the beginning, for example to fix an incorrect rotation of some photos or to apply some metadata preset. Other times, you will use it at the end, during the rating process. By its own nature, it's very easy to use: just pick up an adjustment to apply, and keep on clicking on the photos you want to modify.

To activate the painter tool you can click on the "spray" icon on the toolbar, as shown in the following picture:

Toolbar - Painter tool (Highlighted in Red)

Once the painter tool is activated, your mouse pointer will change to the spray icon shown above and the toolbar section of the painter tool will expand to make place to other controls that will appear. The first one of these controls is a listbox that lets you choose the kind of adjustment you want to apply. The complete list of available adjustments is provided at the beginning of this section. The other controls are contextual and will depend on the kind of adjustment you choose, as shown in the following pictures.

Painter - Develop Presets

Painter - Keywords

Painter - Rating

As you can see in the first of the previous pictures, you can use the Painter tool to choose a preset, in this case a develop preset, and apply to every photo you click.

When you're finished painting, just dismiss the painter tool pressing the Esc key or clicking once again on the Painter tool in the toolbar.

Applying Presets During Import

So far we've seen how presets can enhance your Lightroom experience by speeding up any phase of your daily workflow. Sometimes, however, presets can be useful even before your photos have entered your Lightroom catalog. During the import phase, Lightroom will give the option of:

• Applying a develop preset.
• Applying a metadata preset.
• Applying a set of keywords.

This is handy when the set of photos you're importing share common characteristics and you can apply the corresponding presets while importing them into the catalog. I always use this option to:

• Apply basic metadata, such ownership, location and copyright.
• Apply camera calibration settings.
• Apply lens correction settings.
• Apply noise correction settings.

Let's suppose you're importing a set of photos from a portrait session. Based on your experience, you know you can take advantage of bulk-applying the following presets:

• A specific clarity adjustment (maybe slightly negative).
• A specific camera calibration setting, such as Camera Portrait or a custom one of yours.
• The lens correction profile for your lens.
• A set of keywords.
• Additional IPTC metadata of your session (model, location, etc.)

During the import, Lightroom will apply the presets you chose and then you'll begin working on the already adjusted photos.

In the following picture you can see a detail of the Import window, the Apply During Import panel.

Import Window - Apply During Import Panel

As you can see, this panel lets you choose a develop preset, using the Develop Settings listbox, a metadata preset, using the Metadata listbox, and a set of keywords, typing them into the Keywords text box.

If you want to help me keep on writing this blog, buy your Adobe Photoshop licenses at the best price on Amazon using the links below.

Google Authenticator: Using It With Your Own Java Authentication Server

The Google Authenticator application for mobile devices is a very handy application that implements the TOTP algorithm (specified in RFC 6238). Using Google Authenticator you can generate time passwords that can be used to authorize users in an authentication server that shares the secret key of the requesting users.

Google Authenticator is mainly used to access Google services using two-factor authentication. However, you can take advantage of Google Authenticator to generate time based password to be authenticated by a server of yours. The implementation of such a server is pretty simple in Java and you can get some inspiration getting the source code of the Google Authenticator PAM module. In this blog post, we will go through a simple implementation of the TOTP algorithm in a Java class.

Generating the Secret Key.

To generate the secret key we will use a random number generator to fill up a byte array of the required size. In this case, we want:

• A 16 characters Base32 encoded secret key: since Base32 encoding of x bytes generate 8x/5 characters, we will use 10 bytes for the secret key.
• Some scratch codes (using Google's jargon).

// Allocating the buffer

byte[] buffer =

  new byte[secretSize + numOfScratchCodes * scratchCodeSie];

// Filling the buffer with random numbers.

// Notice: you want to reuse the same random generator

// while generating larger random number sequences.

new Random().nextBytes(buffer);

Now we want to extract the bytes corresponding to the secret key and encode it using the Base32 encoding. I'm using the Apache Common Codec library to get a codec implementation:

// Getting the key and converting it to Base32

Base32 codec = new Base32();

byte[] secretKey = Arrays.copyOf(buffer, secretSize);

byte[] bEncodedKey = codec.encode(secretKey);

String encodedKey = new String(bEncodedKey);

Loading the Key Into Google Authenticator

You can manually load the key into Google Authenticator, or generate a QR barcode to have the application loading it from it. If you want to generate a QR barcode using Google services, you can generate the corresponding URL with a code such as this:

public static String getQRBarcodeURL(
  String user,
  String host,
  String secret) {
  String format = "https://www.google.com/chart?chs=200x200&chld=M%%7C0&cht=qr&chl=otpauth://totp/%s@%s%%3Fsecret%%3D%s";
  return String.format(format, user, host, secret);
}

Verifying a Code

Now that we've generated the key and our users can load them into their Google Authenticator application, we need the code required to verify the generated verification codes. Here's a Java implementation of the algorithm specified in the RFC 6238:


private static boolean check_code(
  String secret,
  long code,
  long t)
    throws NoSuchAlgorithmException,
      InvalidKeyException {
  Base32 codec = new Base32();
  byte[] decodedKey = codec.decode(secret);

  // Window is used to check codes generated in the near past.
  // You can use this value to tune how far you're willing to go. 
  int window = 3;
  for (int i = -window; i <= window; ++i) {
    long hash = verify_code(decodedKey, t + i);

    if (hash == code) {
      return true;
    }
  }

  // The validation code is invalid.
  return false;
}

private static int verify_code(
  byte[] key,
  long t)
  throws NoSuchAlgorithmException,
    InvalidKeyException {
  byte[] data = new byte[8];
  long value = t;
  for (int i = 8; i-- > 0; value >>>= 8) {
    data[i] = (byte) value;
  }

  SecretKeySpec signKey = new SecretKeySpec(key, "HmacSHA1");
  Mac mac = Mac.getInstance("HmacSHA1");
  mac.init(signKey);
  byte[] hash = mac.doFinal(data);

  int offset = hash[20 - 1] & 0xF;
  
  // We're using a long because Java hasn't got unsigned int.
  long truncatedHash = 0;
  for (int i = 0; i < 4; ++i) {
    truncatedHash <<= 8;
    // We are dealing with signed bytes:
    // we just keep the first byte.
    truncatedHash |= (hash[offset + i] & 0xFF);
  }

  truncatedHash &= 0x7FFFFFFF;
  truncatedHash %= 1000000;

  return (int) truncatedHash;
}

The t parameter of the check_code method and verify_code methods "is an integer and represents the number of time steps between the initial counter time t0 and the current Unix time." (RFC 6238, p. 3) The default size of a time step is 30 seconds, and it's the value that Google Authenticator uses too. Therefore, t can be calculated in Java as

t = new Date().getTime() / TimeUnit.SECONDS.toMillis(30);

Download the Library

A ready to use library can be downloaded from GitHub, where Mr. Warren Strange kindly started a repository with the code from this post and packaged it in a Maven project. The library contains a complete implementation of the server-side code, better documentation and some example code in the test cases.

Conclusion

You can now use the Google Authenticator applications and use it to generate time based passwords for your users, authenticated against your own authentication server.

As you can see, the required code is pretty simple and all of the required cryptographic functions are provided by the runtime itself. The only nuisance is dealing with signed types in Java.

Enjoy!

Using a ThreadPoolExecutor to Parallelize Independent Single-Threaded Tasks

The task execution framework, introduced in Java SE 5.0, is a giant leap forward to simplify the design and the development of multi threaded applications. The framework provides facilities to manage the concept of task, to manage thread life cycles and their execution policy.

In this blog post we'll describe the power, the flexibility and the simplicity of this framework showing off a simple use case.

The Basics

The executor framework introduces an interface to manage task execution: Executor. Executor is the interface you use to submit tasks, represented as Runnable instances. This interface also isolates a task submission from a task execution: executors with different execution policies all publish the same submission interface: should you change your execution policy, your submission logic wouldn't be affected by the change.

If you want to submit a Runnable instance for execution, it's as simple as:

Executor exec = …;
exec.execute(runnable);

Thread Pools

As outlined in the previous section, how the executor is going to execute your runnable isn't specified by the Executor contract: it depends on the specific type of executor you're using. The framework provides some different types of executors, each one with a specific execution policy tailored for different use cases.

The most common type of executors you'll be dealing with are thread pool executors., which are instances of the ThreadPoolExecutor class (and its subclasses). Thread pool executors manage a thread pool, that is the pool of worker threads that's going to execute the tasks, and a work queue.

You surely have seen the concept of pool in other technologies. The primary advantage of using a pool is reducing the overhead of resources creation, reusing structures (in this case, threads) that have been released after use. Another implicit advantage of using a pool is the capability of sizing your resource usage: you can tune the thread pool sizes to achieve the load you desire, without jeopardizing system resources.

The framework provides a factory class for thread pools called Executors. Using this factory you'll be able to create thread pools of different characteristics. Often, the underlying implementation is often the same (ThreadPoolExecutor) but the factory class helps you quickly configure a thread pool without using its more complex constructor. The factory methods are:

• newFixedThreadPool: this method returns a thread pool whose maximum size is fixed. It will create new threads as needed up to the maximum configured size. When the number of threads hits the maximum, the thread pool will maintain the size constant.
• newCachedThreadPool: this method returns an unbounded thread pool, that is a thread pool without a maximum size. However, this kind of thread pool will tear down unused thread when the load reduces.
• newSingleThreadedExecutor: this method returns an executor that guarantees that tasks will be executed in a single thread.
• newScheduledThreadPool: this method returns a fixed size thread pool that supports delayed and timed task execution.

This is just the beginning. Executors also provide other facilities that are out of scope in this tutorial and that I strongly encourage you to study about:

• Life cycle management methods, declared by the ExecutorService interface (such as shutdown() and awaitTermination()).
• Completion services to poll for a task status and retrieve its return value, if applicable.

The ExecutorService interface is particularly important since it provides a way to shutdown a thread pool, which is something you almost surely want to be able to do cleanly. Fortunately, the ExecutorService interface is pretty simple and self-explanatory and I recommend you study its JavaDoc thoroughly.

Basically, you send a shutdown() message to an ExecutorService, after which it won't accept new submitted tasks, but will continue processing the already enqueued jobs. You can pool for an executor service's termination status with isTerminated(), or wait until termination using the awaitTermination(…) method. The awaitTermination method won't wait forever, though: you'll have to pass the maximum wait timeout as a parameter.

Warning: a source of errors and confusion is a understanding why a JVM process never exits. If you don't shutdown your executor services, thus tearing down the underlying threads, the JVM will never exit: a JVM exits when its last non-daemon thread exits.

Configuring a ThreadPoolExecutor

If you decide to create a ThreadPoolExecutor manually instead of using the Executors factory class, you will need to create and configure one using one of its constructors. The most extensive constructor of this class is:

public ThreadPoolExecutor(
    int corePoolSize,
    int maxPoolSize,
    long keepAlive,
    TimeUnit unit,
    BlockingQueue<Runnable> workQueue,
    RejectedExecutionHandler handler);

As you can see, you can configure:

• The core pool size (the size the thread pool will try to stick with).
• The maximum pool size.
• The keep alive time, which is a time after which an idle thread is eligible for being torn down.
• The work queue to hold tasks awaiting execution.
• The policy to apply when a task submission is rejected.

Limiting the Number of Queued Tasks

Limiting the number of concurrent tasks being executing, sizing your thread pool, represents a huge benefit for your application and its execution environment in terms of predictability and stability: an unbounded thread creation will eventually exhaust the runtime resources and your application might experience as a consequence, serious performance problems that may lead even to application instability.

That's a solution to just one part of the problem: you're capping the number of tasks being executed but aren't capping the number of jobs that can be submitted and enqueued for later execution. The application will experience resource shortage later, but it will eventually experience it if the submission rate consistently outgrows the execution rate.

The solution to this problem is:

• Providing a blocking queue to the executor to hold the awaiting tasks. In the case the queue fills up, the submitted task will be "rejected".
• The RejectedExecutionHandler is invoked when a task submission is rejected, and that's why the verb rejected was quoted in the previous item. You can implement your own rejection policy or use one of the built-in policies provided by the framework.

The default rejection policies has the executor throw a RejectedExecutionException. However, other built-in policies let you:

• Discard a job silently.
• Discard the oldest job and try to resubmit the last one.
• Execute the rejected task on the caller's thread.

When and why would one use such a thread pool configuration? Let's see an example.

An Example: Parallelizing Independent Single-Threaded Tasks

Recently, I was called to solve a problem with an old job my client was running since a long time ago. Basically, the job is made up of a component that awaits for file system events on a set of directory hierarchies. Whenever an event is fired, a file must be processed. The file processing is performed by a proprietary single threaded process. Truth be said, by its own nature, even if I could, I don't if I could parallelize it. The arrival rate of events is very high throughout part of the day and there's no need to process file in real time, they just to get processed before the next day.

The current implementation was a mix and match of technologies, including a UNIX shell script that was responsible for scanning huge directory hierarchies to detect where changes were applied. When that implementation was put in place, the number of cores in the execution environment were two, as much. Also, the rate of events was pretty lower: nowadays they're in the order of the millions, for a total of between 1 and 2 terabytes of raw data to be processed.

The servers the client is running these processes nowadays are twelve core machines: a huge opportunity to parallelize those old single-threaded tasks. We've got basically all of the ingredients for the recipe, we just need to decide how to build and tune it. Some thoughts before writing any code were necessary to understand the nature of the load and these are the constraints I detected:

• A really huge number of files is to be scanned periodically: each directory contains between one and two millions of files.
• The scanning algorithm is very quick and can be parallelized.
• Processing a file will take at least 1 second, with spikes of even 2 or 3 seconds.
• When processing a file, there is no other bottleneck than CPU.
• CPU usage must be tunable, in order to use a different load profile depending on the time of the day.

I'll thus need a thread pool whose size is determined by the load profile active at the moment of invoking the process. I'm inclined to create, then, a fixed size thread pool executor configured according to the load policy. Since a processing thread is only CPU-bound, its core usage is 100% and waits on no other resources, the load policy is very easy to calculate: just take the number of core available in the processing environment and scale it down using the load factor that's active at that moment (and check that at least one core is used in the moment of peak):

int cpus = Runtime.getRuntime().availableProcessors();
int maxThreads = cpus * scaleFactor;
maxThreads = (maxThreads > 0 ? maxThreads : 1);

Then, I need to create a ThreadPoolExecutor using a blocking queue to bound the number of submitted tasks. Why? Well: the directory scanning algorithms are very quick and will generate a huge number of files to process very quickly. How huge? It's hard to predict and its variability is pretty high. I'm not going to let the internal queue of my executor fill up indiscriminately with the objects representing my tasks (which include a pretty huge file descriptor). I'll prefer let the executor reject the files when the queue fills up.

Also, I'll use the ThreadPoolExecutor.CallerRunsPolicy as rejection policy. Why? Well, because when the queue is filled up and while the threads in the pools are busy processing the file, I'll have the thread that is submitting the task executing it. This way, the scanning stops to process a file and will resume scanning as soon as it finishes executing the current task.

Here's the code that creates the executor:


ExecutorService executorService =
  new ThreadPoolExecutor(
    maxThreads, // core thread pool size
    maxThreads, // maximum thread pool size
    1, // time to wait before resizing pool
    TimeUnit.MINUTES, 
    new ArrayBlockingQueue<Runnable>(maxThreads, true),
    new ThreadPoolExecutor.CallerRunsPolicy());


The skeleton of the code is the following (greatly simplified):


// scanning loop: fake scanning
while (!dirsToProcess.isEmpty()) {
  File currentDir = dirsToProcess.pop();


  // listing children
  File[] children = currentDir.listFiles();


  // processing children
  for (final File currentFile : children) {
  // if it's a directory, defer processing
  if (currentFile.isDirectory()) {
    dirsToProcess.add(currentFile);
    continue;
  }


  executorService.submit(new Runnable() {
    @Override
    public void run() {
      try {
        // if it's a file, process it
        new ConvertTask(currentFile).perform();
      } catch (Exception ex) {
        // error management logic
      }
    }
  });
}


// ...
        
// wait for all of the executor threads to finish
executorService.shutdown();
        
try {
  if (!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
    // pool didn't terminate after the first try
    executorService.shutdownNow();
  }


  if (!executorService.awaitTermination(60, TimeUnit.SECONDS)) {
    // pool didn't terminate after the second try
  }
} catch (InterruptedException ex) {
  executorService.shutdownNow();
  Thread.currentThread().interrupt();
}

Conclusion

As you can see, the Java concurrency API is very easy to use, very flexible and extremely powerful. Some years ago, I would have taken much more effort to write such a simple program. This way, I could quickly solve a scalability problem caused by a legacy single threaded component in a matter of hours.

Hyperfocal Distance: Advanced Depth of Field and Focusing Tips

The Basics: Depth of Field

Focusing is invariably one of the tasks you perform while taking a shot. You also know that focusing isn't only about having your subject in focus: you can use depth of field as a composition technique to give your photo a particular mood.

Depth of field is the distance between the farthest and the nearest object that will appear in focus in your photo (we will later clarify what does in focus mean). You may use a shallow depth of field when you want to isolate your subject from the surrounding objects, as you can see in the following image:

Shallow Depth of Field

The yellow flower is in focus, while the background is blurred. The characteristics of the blurred part of the image is called bokeh, and mainly depends on the chosen aperture and on the physical characteristics of the lens you're using.

On the other hand, other times you may want every part of your image to be in focus, such as in a typical landscape shot.

Being able to understand how you can control the depth of field is fundamental if you want to use it proficiently and get the shots you want.

Depth of field is mainly affected by these parameters:

• The focal length of your lens: the greater the focal length, the smaller the depth of field.
• The aperture you're using: the smaller the aperture, the greater the depth of field.
• The distance to the subject: the shorter the distance to the subject, the smaller the depth of field.

As we'll see later, and as you've probably experienced yourself, it's much more difficult to get a shallow depth of field than a deeper one. How many times were you striving to get a portrait with a good bokeh without success? You tried raising your aperture (reducing the f-number) but nothing, the background wasn't sufficiently blurred. Why?

We will soon discover it. These rules are fairly basic and are pretty well known to the average amateur photographer. However, these are only approximations of a more complicated formula and sometimes you may strive without success to get the results you want even if you're following all of the above mentioned advices.

Understanding the Nature of Depth of Field

Depth of field behind and in front of the object that is on focus isn't symmetric: on most conditions, depth of field will be deeper behind the subject and shallower in front of it. We won't explore the details of the depth of field equations, but it's important that you realize the following:

• The ratio between the focus zone behind a subject and the focus zone in front of it tends to 1 when the distance between the camera and the subject gets shorter and is about the same order of magnitude of the lens focal length. Unless you're shooting with a macro lens, this won't be the case.
• The depth of focus zone behind the subject increases as the distance from the subject increases and will reach the positive infinity at a finite distance, usually called hyperfocal distance.

What does this mean? Well, amongst other things it means that:

• It's way more difficult to blur the foreground rather than the background.
• If the distance from the subject is greater than the hyperfocal distance you aren't going to get that beautiful bokeh you're looking for, no matter how much you strive for it.
• On the other hand, if you're looking for a picture with a really deep depth of field, just be sure your subject is farther than the hyperfocal distance.

Hyperfocal Distance

We now understand that the hyperfocal distance is responsible for at least some problems we had while getting the focus condition we looked for our shot. The hyperfocal distance H can be expressed as:

H = (f²) / (N c)

where f is the focal length, N the aperture and c the diameter of the circle of confusion. The circle of confusion, as suggested at the beginning of this post, is the criterion used to establish when a region of a photo can be considered in focus: it's the minimum diameter of the circle generated by a cone of light rays coming from a lens when a point is not in focus. Being the diameter of a physical light spot on your sensor (or on your film), this value depends on the size of the sensor: the biggest the sensor, the biggest can be c to get comparable sharpness. You can use 0.03 mm as a typical value for c.

Some properties of the hyperfocal distance are:

• The biggest the focal length, the biggest H is. Please note that the relationship is quadratic: a lens with a double focal length will give an hyperfocal distance four times as big, keeping the other parameters fixed.
• The biggest the aperture, the smallest the hyperfocal distance.
• When focusing on an object at the distance H, the depth of field will be extend from H/2 to infinity.
• When focusing on an object at a distance H or greater, the ratio between the focus zone behind the subject and the focus zone in front of the subject is infinite.

But how big is H? Here are some values for H(f, N) some common focal lengths and apertures (assuming c = 0.03 mm):

• H(18mm, f/4) = 2.7 m
• H(18mm, f/16) = 0.67 m
• H(55mm, f/4) = 25.21 m
• H(55mm, f/16) = 6.30 m
• H(100mm, f/4) = 83.33 m
• H(100mm, f/16) = 20.83 m
• H(200mm, f/4) = 333.33 m
• H(200mm, f/16) = 83.33 m

It's now apparent why focal length is often really important if you need a good bokeh. If you're shooting with a 18mm-f/4 lens, if your subject is more than 2.7 meters away there's no way to get a decent bokeh. And even if it got closer, the boken wouldn't be that good either. On the other hand, this is the reason why wide lenses are really good to get a really wide landscape in reasonable focus. Even if you were shooting with a 55mm lens at f/4, any object farther than 12.6 m (25.21 m / 2) would be in focus.

We've understood why, if you want to shoot at a subject at a given distance and you want to get a good bokeh, you must take the hyperfocal distance into account:

• If your subject is nearer than the hyperfocal distance, you can shoot and tweak your depth of fields using the other parameters.
• If your subject is farther than the maximum hyperfocal distance you can get with your lens, your only option is changing it.
• If your subject is very close to the hyperfocal distance of the lens configuration you're using, you should consider changing the lens anyway to get a good bokeh (the reason will be explained in the next section).

Evaluating the Depth of Field

Learning your lens parameters is important and knowing the approximate hyperfocal distance of your lenses (at least for some apertures) is important if you need to quickly evaluate if the conditions in which you're going to take a shot are correct.

There's another advantage of knowing the hyperfocal distance: using a curious mathematical property of H, you can quickly evaluate the characteristics of the depth of fields at distances smaller than H without learning the complex, and not-as-easy-to-evaluate, depth of field equations. Here's how.

The nearest end and the farthest end equations of the depth of field can be expressed in terms of H and s (the distance from the subject), when s is much larger than the focal length (which is always true unless you're doing macro photography, which is not the case):

D_N = H s / (H + s)
D_F = H s / (H - s)

This equations are pretty simple, but not enough for a photographer to quickly use them when shooting without the help of a calculator! If we now consider distances s = H / n (where n is a natural integer), then these formulas simplify ever further:

D_N = H / (n + 1)
D_F = H / (n - 1)

• The depth of field at a distance H/n (where n is an integer number) is the range [H/(n+1), H/(n-1)].

Much easier to calculate by mind! Also, it's apparent that for relatively small H or relatively big n you're going to have a shallow depth of field. You often won't even need to calculate the result, just remember the principle.

Using this trick, you can evaluate approximately the depth of field. For example: if you're shooting with a 200mm lens at f/4, you know that H is approximately 333 m. What's the depth of field if we're making a portrait to a subject at 10 m? 10 meters is approximately 333/30 so that, from the above formula, the depth of field will be the range [333/31, 333/29] = [10.74, 11.48]. Pretty shallow, indeed.

From this formula it's also clear why the ratio between the focus zone behind the subject and in front of it goes down from infinity to 1 when the distance from the subject goes down from H.

Conclusion

In this blog post we've introduced the concept of hyperfocal distance and explained why it is so important to understand the basic characteristics of the depth of field. Depth of field is an important tool for you as a photographer and it's omnipresent in every photography course. However, very often a photographer isn't able to evaluate the depth of fields he's going to obtain from a specific camera configuration and he's left with trial and error, without even being able to assess if the shot he's looking for is even possible to achieve.

The hyperfocal distance equation is very simple and is much simpler of many depth of fields models you can find. If you don't need to calculate it exactly, known H is sufficient in most everyday situations.

Have fun.

Adobe Photoshop Lightroom Tutorial - Part XVI - Saving And Migrating Your Adobe Lightroom Presets

Part I - Index and Introduction
Part XVII - Tone Curve

As we've seen in previous posts of this tutorial, many aspects of Lightroom can be customized by users and saved into a preset. There are many kind of presets and the most commonly used are:

• Develop presets.
• Export presets.
• External editor presets.
• Import presets.
• Metadata preset.
• Watermarks.

Instead of repetitively applying the same configurations over and over again, you can permanently store them in a preset and load them when necessary. You can, for example, save a commonly used develop configuration (such as a color temperature setting) in a preset and apply it with just a click to a bunch of photos at a time. Or you can save metadata configuration into presets and automatically apply them during an import operation.

There are many reasons why you should know how and where Adobe Lightroom stores your presets. Some of the common scenarios where you would want to save and migrate them are:

• Safeguarding your data against loss.
• Sharing them across different Lightroom instances, probably because you're using more than one computer.

Imagine, for example, you create some custom adjustment brushes and save them as presets. You then migrate your catalog to resume working on another computer only to discover that your brushes are gone.

Maybe you thought that a Lightroom catalog was self contained: it is, but only to a certain degree.

Where Are Presets Stored?

Lightroom version 3 can store and use presets in two places:

• In the preset folder, a unique folder per user account.
• In the catalog directory (only if explicitly enabled).

By default, Lightroom only uses the user presets folder, unless you select the Store presets with catalog checkbox in the Lightroom preferences window, as shown in the following picture:

Lightroom Preferences Dialog

The user-wide presets folder is called Lightroom and its location is platform dependent. Fortunately, there's a quick way to determine which folder it is: open the Preferences dialog, navigate to the Presets tab and push the Show Lightroom Presets Folder… button (shown in the previous picture). In the case of the OS X operating system, this folder is located in ~/Library/Application Support/Adobe/Lightroom:

Lightroom Presets Folder in Mac OS X

If you decided to store the presets in your catalogs, you will find a copy of this directory into your catalog root directory.

How Can I Backup And Migrate My Presets?

This is really easy: copy them to a folder that Lightroom recognizes as a preset folder and they're will be ready to use. Just pay attention to your Lightroom configuration, as detailed in the previous section, to copy presets from and to a correct location:

• If you're storing the presets with the catalog, just synchronize the catalog across computer and no more action is needed.
• If you're storing the presets in the user wide presets folder, you need to back it up manually and synchronize it across computers.

An effective way to synchronize files across computer is using rsync. Using rsync you can efficiently keep in sync a folder across different machines with almost no effort and transmitting the minimum amount of data to keep in sync the target with the source. This is a specially important factor to take into account since catalogs can get in the gigabytes range very soon.

Which Approach Should I Use?

If you're using only one or few catalogs, maybe its convenient for you to change the default Lightroom behaviour and store them with your catalogs. Every time you back up your catalog, you're presets will be backed up as well. And if you synchronize a catalog to another computer, all of your presets will be available on the other machine without further effort.

However, if you're using many catalogs, you may want to store commonly used presets outside the catalogs: otherwise, you would have to create them again to any new catalog you create.

You can also use a third and completely manual approach: you can manually manage which presets you want to store and at which level. Just look for the corresponding files (the presets folder structure is pretty self-explanatory) and copy them to where you need it.


If you want to help me keep on writing this blog, buy your Adobe Photoshop licenses at the best price on Amazon using the links below.