Digital photography is a complicated discipline comprised of complex relationships, unintuitive numbers and obtuse terminology. Aperture, shutter speed, ISO, depth-of-field, focal length, Bayer filter mosaic, moiré, bokeh and other such terms are the common vernacular of the professional photographer, but seems a foreign language to most outside the discipline.

Web-design is similar to digital photography in being also comprised of complex relationships, unintuitive numbers and obtuse terminology. But despite these categorical similarities, the two languages are worlds apart; one is French and the other Hindi. The web-designer’s vernacular is made up of terms like hypertext markup language, cascading stylesheet, accessibility, fluid grid, responsive design, element, selector, attribute, property, cookie, breadcrumb, graceful degradation, pseudo-class, etc. A language foreign to most photographers.

And yet, despite these differences, the two disciplines share some common ground. In our modern world, the Internet has become the photographers’ best means of exposing viewers to their photography. Inevitably, we enter the grey area where the worlds of photography and web-design collide, typically resulting in confusion. And while photographers need not become web-designers, it is important to understand Web as relates to images.

The Web is a wild place, and one of the grizzliest bears the photographer is likely to encounter is that of pixel density. Pixel Density is measured in pixels-per-inch, often abbreviated ppi, and is one of the most misunderstood aspects of digital imagery. In this article, pixel density will be explored, manipulated and explained. And in the end, you will come to realize the ultimate truth out pixel density and the web:

It doesn’t matter.

Pixel Density vs. Web Module: It’s a “Problem”

I regularly receive messages from Lightroom users bent out of shape after having realized that Lightroom’s Web module exports images at 240 ppi. The discovery typically manifests itself in distress over image piracy and illegitimate use, fears that visitors to the site will download the web-resolution image from the gallery, then utilize the image’s pristine 240 pixels-per-inch quality to create billboards visible from space while claiming the work as their own. The moon will crash into the earth, the seas will rise, and the world will end in flames.

My standard response to this distress runs something like, “It’s not important. Don’t worry about it.”

And this reply is generally not well received.

But notice above my intentional use of quotation marks around the word “Problem”. Because it’s really not a problem, except in the heads of photographers who have been misinformed, led astray of the truth and who, as a result, do not know what they are talking about.

Fact: Lightroom’s Web module exports JPG files at 240 pixels-per-inch.

Fact: It doesn’t matter.

Defining Pixel Density

Pixel density, a.k.a. pixels-per-inch, is an arbitrary value that defines for the printer the dimensions that should be considered 100% scale for an image. Pixel density dictates print dimensions only, not print quality. Quality, a.k.a. resolution, is instead a function of the total number of pixels comprising the image versus the size at which the image is printed.

The Dissemination of Misinformation

On the subject of pixel density, well-intentioned fools have long been spreading misinformation, the cumulative effect of which being the acceptance of falsehoods as truth by the masses. You can’t believe everything that you read, unless you read it at The Turning Gate. The Turning Gate never speaks falsely.

We will be addressing some of this misinformation below.

Pixels-per-inch and Dots-per-inch are Not Interchangeable Terms

Pixels-per-inch (ppi) and dots-per-inch (dpi) are often used as interchangeable terms. This is wrong; these terms are not interchangeable.

A 10 × 10-pixel image on a computer display usually requires many more than 10 × 10 printer dots to accurately reproduce, due to limitations of available ink colours in the printer.

As stated above, pixels-per-inch is an arbitrary value that indicates to the printer the dimensions at which an image should be printed at 100% scale.

Dots-per-inch refers to the number of dots sprayed into a square inch of space on the printed page, or to the printer’s capability to spray dots into an inch of space on paper. Printers may be rated by their dpi capability, with higher numbers indicating that the printer is capable of printing images of higher quality.

Experiment 1

Fact: 1-pixel does not equate to 1-dot, or to any other number of dots on the printed page.

We may illustrate this fact by performing a simple experiment.

First, open Photoshop. Set your colors to default, then swap them; do this by pressing ‘D’ then ‘X’ on your keyboard. Your foreground color should now be set to white, and your background to black. Press CMD-N on Mac or CTRL-N on Windows to create a new image. We are going to create an image 1-pixel wide by 1-pixel tall with a pixel density of 1 ppi, as shown in the image below.

Create an image in Photoshop with these values.

You should now have an image on your screen: one black pixel.

Print your image at its native 100% scale, without borders or frames. On the printed page, you should find a black square 1-inch in size.

As you can see, 1-pixel does not translate to 1-dot of ink; your printer sprayed many dots to create that 1-inch black square.

Let us now take the experiment further to show that pixels-per-inch is indeed an arbitrary guideline for printing.

Create another new image, this time 1-pixel wide by 1-pixel tall with a pixel density of 5 ppi.

You should now have a new image on your screen: one black pixel, seemingly identical to the previously created image.

As with the first image, print this new pixel at its native 100% scale. On the printed page, you should find a black square one-fifth the size of the previously printed image.

At this point, we have two images which are apparently identical on-screen, but which print to different sizes on paper. Clearly, the pixels-per-inch has an effect on print size. Pixels-per-inch does not have any effect on print quality, however, which we may demonstrate by making a third print.

Print again the 5 ppi image, this time scaled to 500%. You should find that the resulting print is identical to our first print, made from the 1 ppi image.

From this experiment, we may draw several conclusions:

• Images with equal pixel dimensions will appear identically on-screen, regardless of their pixel density.
• Regardless of the number of pixels in the image, the printer will create as many dots as necessary to scale the image to the specified print-size.
• Images of equal pixel size, but differing pixel density may be scaled to print at any size. When printed at equal sizes, the quality of the two prints will be identical.
• Pixels-per-inch and dots-per-inch have no correlative translation, and should therefore not be used as interchangeable terms.

With this new understanding of pixel density, let us dispel some misinformation from a popular and widely trusted resource.

According to Wikipedia, pixels-per-inch “can … describe the resolution, in pixels, of an image to be printed within a specified space. For instance, a 100×100-pixel image that is printed in a 1-inch square could be said to have 100 DPI. Used in this way, the measurement is only meaningful when printing an image. Good quality photographs usually require 300 dots per inch when printed.”

Notice the author’s use of DPI in attempting to explain pixel density. This is stupid.

It should correctly read, pixels-per-inch “can … describe the resolution, in pixels, of an image to be printed within a specified space. For instance, a 100×100-pixel image that is printed in a 1-inch square could be said to have 100 DPI PPI. Used in this way, the measurement is only meaningful when printing an image. Good quality photographs usually require 300 dots per inch more pixels when printed at larger sizes.”

The Myth of 72

Many photographers have fallen sway to the hearsay that an image being output for web should be saved at 72 pixels-per-inch. Another number sometimes kicked around in similar context is 96.

The belief that these numbers in any way relate to an image, however, is false. They never affect an image in any way.

So, where does this myth come from?

On paper, text font size in Points is dimensioned in inches. The definition of a Point is 1/72 of an inch, and so there are 72 points per real inch on paper.

Computer displays are dimensioned in pixels, without any correlation to physical forms of measurement such as inches. At some point, it was decided that computer users would require some correlation to printed text, however, and so the operating system simply dreams up and uses fake 72 and 96 dpi numbers to compute text size on the screen.

Programmers call this concept Logical Inches, which equates to pretend inches. The Windows operating system assumes one logical inch on screen to be 96 pixels, while the Macintosh operated system assumes one logical inch on screen to be 72 pixels. And so, if we simply pretend that pixels at these values will cover one inch on their respective screens (without asking the size of the screen), then we can use this to compute that a 12-point font should be shown to be 12-pixels tall on-screen using a Mac, and 16-pixels tall on a Windows display. And so we are happy, so long as we ask no questions.

And for a time, this flawed concept has sufficed for text. But as display resolutions continually increase over time, 12-pixel text-sizes begin to appear smaller and smaller to the human eye and will, at some point, become illegible. Bear in mind that these guidelines were imagined when standard display resolutions were 640×480, 800×600 and 1024×768. Today, screen resolutions of 1920×1200 are not uncommon.

When you cram more pixels into a the same space, those pixels must be smaller. Compare a 15-inch display at 1024×768 to a 15-inch display at 1920×1200, and this notion of correlating physical inches to computer display resolutions quickly falls apart. A 12-pixel font on the former is easy to read, while a 12-pixel font on the latter display borders on being illegible. On the latter display, the notion that 72 dpi = 1 inch of physical screen real estate doesn’t hold up.

So, that’s the story of text. How did the notion of 72 dpi become associated with images?

Let’s say you go to a friend’s party. At the party, you see a girl you’ve never seen before. Because she is at your friend’s party, you may logically assume she is your friend’s friend.

A similar thing happened with the notion of 72 dpi. The value being applied to text on screen was soon applied to everything else appearing on screen, including images. It’s a case of assumed association. But in this case, your friend has never met the girl at his party; somebody else brought her.

Pixel Density vs. Image Quality

Now that we have explained and dispelled the most common misconceptions about pixel density, let’s get back to Lightroom and information that qualifies as truth — the useful stuff.

Pixel density has no impact on image quality. Image quality depends not upon the number of pixels-per-inch, but the number of pixels that comprise the image.

We have previously established that computer displays are dimensioned in pixels. Therefore, the number of pixels wide by pixels tall will determine the size of the image on screen.

On paper, the image size at 100% scale is determined as pixels wide by pixels tall divided by pixels-per-inch. As demonstrated by our first experiment, however, an image may be scaled to a larger or smaller size and the pixels will simply be stretched to accommodate the specified scale. On paper, the image size is determined by the printer, while image quality is a factor of the total number of pixels in the image and the specified size of the printer. Spreading fewer pixels over more paper will result in an image of lesser quality.

To explore the impact (or lack of impact) of pixels-per-inch on our images, let us perform a second experiment.

Experiment 2

To conduct this experiment, download the two images below to your desktop.

550 x 367 pixels, 240 ppi

550 x 367 pixels, 72 ppi

Both images were exported via Lightroom’s Export module at 550 pixels wide by 367 pixels tall; the first image was exported at 240 ppi, and the second image at 72 ppi.

Examining the images, our first observation should be that the images appear to be of equal size and image quality on screen; the images above are both presented at full size.

By looking at the files downloaded to the desktop, we may also observe that both image files are 258KB in size. Despite having different ppi values, the two images are equal in file size. This is because the images consist of the same number of pixels.

Next, import the two image files into your Lightroom catalog. Go to the Print module. Print the two images at the same size. You may print them both to a single sheet of photo paper, or print them larger to separate sheets as you prefer. It’s a good idea to enable File Info to display the file name of each image on the print so that you know which image file corresponds to each print.

By examining the two prints, you should observe that two images of equal pixel dimensions and different pixel density, when printed at the same physical size on paper, will appear to be of equal print quality.

From this experiment, we may draw the following conclusions:

• The value of pixels-per-inch has no impact on image file size.
• The value of pixels-per-inch has no impact on the on-screen display size of the image.
• Both the size of the image on screen, and the quality of the image on paper are directly dependent upon the number of pixels comprising the image.

From this third conclusion, we may extrapolate:

• Prints of better quality may be produced by image files containing more pixels.
• Larger prints require larger image files (i.e. image files containing more pixels).

Experiment 3

This experiment is entirely optional and only worth performing if you require yet further demonstration of the impact of pixels-per-inch on physical prints of images.

Load the two image files above into Photoshop, then print each image at 100% scale. You should observe that:

• The 72 ppi image prints at roughly 7.6 x 5.0 inches.
• The 240 ppi image prints at roughly 2.3 x 1.5 inches.

Because the pixels-per-inch values of the images differ, the printer will interpret the image sizes differently relative to 100% scale.

The 240 ppi image will appear to be of higher quality, but this is only because the pixels are being printed smaller in order to accommodate the smaller physical size of the print. If you should print the 240 ppi image again, scaled to the same dimensions as the 72 ppi image at 100% scale, then you will observe that the actual quality of both images is identical.

Alternatively, you may print the 72 ppi image at a smaller scale. When scaled to the same dimensions as the 240 ppi image at 100% scale, you will observe that the actual quality of both images is identical.

From this experiment, we may draw the following conclusion:

• While the value of pixels-per-inch may affect the print size of an image at 100% scale, it has no impact upon the actual quality of the image, which is dictated by the number of pixels comprising the image and the area of the paper over which those pixels are being spread.
• Because printed scale may be changed according to the whim of the individual making the print, the value of pixels-per-inch becomes largely irrelevant.

The Eternal Quest to Protect Your Images

By now, you should understand that contrary to popular belief, pixels-per-inch has no impact upon the quality of your image, and therefore provides no measure of protection in preventing the download or unauthorized use of images from your website. So, what can you do?

First of all, forget about PPI. As I told you at the beginning of this dreadfully long article, and as you should now understand, IT DOESN’T MATTER. There is no reason to get bent up over pixel density.

So let’s drop the topic of pixel density and instead focus upon the things that do matter, the features that can actually help you to safeguard your images online.

Whether exporting images from the Export module or the Web module, Lightroom offers several options for protecting your images.
First and most relevant to this article is Image Size. We now know that image quality is directly dependent upon the number of pixels comprising your image. The larger your exported image, the better quality at which that image may be printed, with quality degradation being relative to the physical size of the printed image.

Because the pixel dimensions of the image control both the potential print quality of the image, as well as the display size of the image on screen, however, a balance must be struck between exporting the image at a size large enough for web viewing, and small enough not to be worth using as a print. As the photographer, it’s really up to you to find a balance that you find acceptable.

Naturally, we favor larger images for viewing on our website, but larger images put you at greater risk of unauthorized image use, as those images can be printed at larger sizes on paper while maintaining an acceptable print quality.

The next mechanism that may be used to provide some protection is the Image Quality slider, which controls the JPG compression of the output image files. With the quality scaled back, the images become muddier looking and the fine details less discernible. Again, as the photographer, it is up to you to decide where to draw the line between protecting yourself and presenting your image with an acceptable loss of visual quality relative to the pixel dimensions of the image. Experiment to find a value that works for you, and realize as well that different images may have varying thresholds for quality degradation.

Another method of protecting your images is to embed full metadata, including usage, copyright information and status, photographer contact, etc. This is not a perfect method of protection, as metadata may easily be stripped out of an image by anyone willing to make the effort. It certainly doesn’t hurt to embed full metadata, though; the only negative effect is a negligible increase in file size.

One of the best methods of protecting your images is to utilize Lightroom’s watermarking features. By visually overlaying your copyright information and web address on your images, you create a protective element that can only be removed by damaging the image either by cropping the watermark out or through digital manipulation. Most people won’t know how to do this, or won’t find the effort worthwhile. And depending upon the size and placement of your watermark, removal attempts may destroy the integrity of the image. However you approach the matter, watermarks are your best defense against online image theft.

Finally, your best defense is the simple fact that you own the original full size RAW image file, while an image thief would only have the web-resolution JPG — an image file that just wouldn’t hold up to most commercial uses of the image.

Coda

In this article, we have dispelled several of the myths and much of the misinformation surrounding the issue of pixel density. Having read this article and performed the included experiments, you should now have a better understanding of digital image quality and how it relates to your images on the web and on paper.

Should you have any further questions about pixel density or relating subjects, feel free to open discussion in the TTG Support Forum.

Photography is a complicated beast, only partially about the things you’d expect: image making, cameras, lights, computers, etc. As important as those things are, I continually find that a larger part of the business is what happens off set, involving personal interaction with the client, problem solving and adaptability. And so I’m stepping away from my usual subject matter — Lightroom’s Web module — to share with you a recent on-the-job experience; a problem and how I was able to solve it through adaptability, quick thinking and my iPhone.

I hope you will find the story informative, a little entertaining, and that you will keep it in mind should you ever find yourself in a similar situation.

in which the stage is set

Several days ago, I was on location for a photo shoot acting as digital tech for the job. We were in a football stadium, shooting players on the field for an advertising campaign. Aside from the photo crew and production assistants, we had several reps from the ad agency with us. We work with the ad agency and client often, and what usually happens in the studio is that as shots are made, the agency’s art director(s) will make first approval of the image, then email a comp to the client for final approval. Receiving client approval, we strike set and prep the next shot. In studio, we tether to Lightroom 3, export JPG images to email and fire them through the chain of command for approval.

On location, however, things happen a little differently. The photographer was shooting to CF cards, which were passed off to me for download to the Lightroom catalog on our Macbook Pro. I would then standby with the art director while they reviewed the images on the sidelines. Meanwhile, the photographer moves on with the shoot, making more images. No problems so far, until the art director informs me we need to be sending image selects to the client from location for approval.

Checking the Airport signals on the notebook, I find myself within range of two WiFi signals originating from the stadium. Unfortunately, both are closed networks with a password required. Our stadium keymaster doesn’t know the passwords. Nor does anyone on the shoot have a smartphone that supports notebook tethering. We are — seemingly — screwed.

in which I high-five the art director

The ad agency is unhappy. The photographer is at a loss. Our producer is frantic. I am thoughtful. An idea begins to percolate.

“I think I can do this,” I tell them. I ask for a few moments of peace while I work this out. A few days prior, I had stumbled upon an iPhone app; at this point, I hadn’t yet tested the app, but thought it might be just the solution for our dilemma. As it turned out, I was right.

The app is Photo Transfer App, a universal application for the iPhone and iPad that costs $2.99. The app allows users to easily transfer images between their PC, iPhone and iPad over a shared WiFi network.

As previously established, however, there is no WiFi network within range to which we can connect …

Every Mac includes an Airport, Apple’s proprietary network adapter which allows the computer to connect to wireless networks. An often overlooked feature of the Airport, however, is its ability to generate a local network of its own. While useless for connecting to the Internet, this feature is extremely useful in getting two devices talking to each other. And so I used the Airport on the Macbook Pro to create a local network:

All networks are locked, and so we'll make our own: Create Network!

Turning to my iPhone, I accessed my phone’s Settings for WiFi connectivity:

I then went into the Settings on my iPhone to connect the phone to the newly created local network.

At this point, the Macbook Pro and iPhone are communicating. Back in Lightroom, I exported the art director’s selected images to my desktop as web-resolution JPG files, 72 ppi and 1,000 pixels on the long side. The resulting images were roughly 150KB each, large enough to comfortable on-screen viewing, but small enough for email.

I launched the Photo Transfer App and set it up to receive images from my Macbook Pro. This done, the iPhone essentially becomes a server which any computer sharing the network can access via web-browser:

My iPhone is now a web-server for computers sharing the same network, and can be accessed by targeting the provided address using any web-browser. No additional software required!

On the computer, I launched Safari and targeted the given address. This brought me here:

Select 'Upload Files' to send images to your phone.

And, on the phone:

The images transfer from computer to iPhone.

With the image selects now saved to my iPhone’s image library, I was able to email the images to the art director over my phone’s 3G network. The art director then forwarded those images on to the client for approval. With my network and flow established, I was able to continue sending images this way throughout the shoot as new images were handed over to me for download from the CF Cards and new selects were made. Remotely, the client was kept in the loop despite our lacking direct access from our on-site computer to the Internet and email.

“You’re awesome,” the art director said as we high-fived.

“You really are awesome, Campagna,” the producer confirmed.

The photographer kept shooting, we kept sending selects to the client, and the shoot went smoothly.

TTG Monoslideshow-2 is now available for Lightroom 3 Beta 2, bringing the excellent Monoslideshow once more to the Adobe Photoshop Lightroom Web module.

Monoslideshow is a Flash slideshow designed for maximum flexibility, whether you want to have a professional looking portfolio, or a simple image rotator on your website. TTG Monoslideshow-2, built exclusively for Lightroom 3, allows you easy access to Monoslideshow’s many options and features, and lets you view your changes in real-time in the Web module preview.

Among its many configuration options, Monoslideshow 2 includes a full-screen mode, professional transitions, Ken Burns effects, customizable image navigation and slideshow options, and can create slideshows of any size.

Please note that Monoslideshow and TTG Monoslideshow-2 must be purchased separately. TTG Monoslideshow-2 does not include the Monoslideshow Flash component, which must be licensed and supplied separately from http://www.monoslideshow.com.

You can demo Monoslideshow using the interactive demo on the Monoslideshow site. For the most part, TTG Monoslideshow-2 duplicates these controls, though there are some differences.

TTG Monoslideshow-2 is available at an introductory price of $15 until the end of March, after which it will be $20; full details and setup instructions are available on the product page.

As digital photographers, we live in constant fear of the crash. It’s not a matter of IF, but WHEN. The crash is inevitable. At some point, one of your precious hard drives will head down the dark path of no return, taking gigabytes upon gigabytes of precious data with it. Obsessively backing up our work is a part of our craft. None of us wants to be the guy that loses someone’s wedding photos, or the client’s $100,000 advertising shoot. So, let’s assume for a moment that we are well-invested in redundancy, that our images are as safe as they could possibly be: on two separate hard disks residing in separate geographical locations in case of fire, and all images also backed up to DVD, deposited into a safety deposit box in Switzerland with an armed guard detail.

Your. Images. Are. Safe.

And yet, I constantly receive this sort of thing in my inbox:

Matt,

My hard drive crashed and I’ve lost all of my email messages. Can you please send me my download URLs for the TTG galleries I’ve purchased?

Thanks,
Sad Photographer

Luckily, I have records of such things. But I’m guessing that Mr. or Mrs. Sad Photographer lost a lot more than TTG download links, and those other things are probably not so easily recovered.

What frustrates me most about receiving these messages is not the inconvenience of having to look up old transaction records, but the knowledge that this loss could easily have been prevented. Here’s the cold, hard fact dear readers:

Your computer is the WORST place to keep your email.

And if that’s not a fact, then it’s certainly my opinion.

As independent photographers, you are also small business owners. Consider what passes through your email on a daily basis: correspondence with clients, job invoices, purchase receipts, bids, bid requests, image proofs, processing instructions, print orders and very important messages from The Turning Gate. Other possibilities may include bank statements, accounting and other transaction records, sweet messages from your partner, cute things from your kids and all manner of things better not lost in system failure.

A few years ago, I bought my parents a new Mac. Previously, they’d been using an old PC and checking their email via Thunderbird. I setup Thunderbird on the new Mac in order to move the old mail over, which amounted to more than 2GB of saved messages. Two gigabytes(!!) of hard disk space being needlessly consumed. Two gigabytes of data that first had to be exported, and then had to be imported onto the new machine. Two gigabytes of data that might have been lost had that old PC decided to die, and I tell you it was near death’s door at the time. Two gigabytes of data that will only increase in size over time with new emails received and saved, and which will only become a greater liability as it grows, and even more of a pain to preserve or move to the eventual next computer.

I feel I’m becoming long-winded, and so I’ll state my point:

Cloud-based email services can save your bacon and also save you headache, heartache and frustration.

Of all the cloud-based email services on the web, Google’s Gmail is by far my favorite. Google’s Gmail service offers vast amounts of storage, a unique approach to organization, one of the best e-mail-searching features around, and access to all your e-mail from any Web browser—all for the low, low price of free.

The many advantages should be clear. Email messages are not consuming vast portions of my local hard disk, are not in danger of being lost when my hard disk inevitably dies, do not have to be moved when I buy a new computer, can be checked from any computer, any where, or even from my phone. And I promise you that Google takes better care of its servers than you do of your computer, and so your messages are reliably hosted with redundancy and regular maintenance. You can even use your Gmail account to check, collect and store messages from your other email accounts.

Take it to heart, folks. Get a Gmail account, and stop losing your messages in catastrophic system failures. There’s no reason I or anyone should ever have to receive an email from Sad Photographer.

This is a question for users of TTG Highslide Gallery and TTG Highslide Gallery Pro. The “shared resources” feature was an experimental idea built into the gallery. At this point, I’m wondering whether anyone actually uses it. Would anyone miss it if it were gone?

The argument against future inclusion of the feature has several points:

1) It’s a pain in the bum to keep up with from update-to-update.
2) It’s not at all intuitive, and I think just confuses people.
3) It creates a number of additional conditional process for Lightroom to grind through, and may or may not have an impact on the speed of the gallery.

I have no plans to include this feature in any future products; it’s too much hassle amounting to too little a reward. It lives and dies with the Highslide gallery, whatever the response to this post. I would really like to “clean up” the next release of the gallery by removing the feature, but I don’t want to disappoint anyone who may have found it useful. So, I’m looking for you all to sound off on the feature. What do you think? Useful? Extraneous? Indifferent?

Thanks,
Matt

Photographers often have need to password protect galleries of images, whether providing clients with a layer of security or for other reasons. In a previous article, I proposed using a password protection script from Zubrag.com as one possible solution. Another solution was recently brought to my attention by TTG user Steen Brogaard. After testing the script, I find that it’s a little more complicated to get up and running, but well worth the effort in the end.

The script is called Login Redirect, and is a free download from mpdolan.com. This script not only protects specified pages, but also provides an admin area from which user accounts and redirect targets can be managed.

To get up and running with this, you will need to setup a MySQL database on your server. This can usually be done from within your hosting control panel. If you don’t know how to do this, consult documentation or support with your web host for assistance.

Here are some tips to get this setup:

Download and unzip the Login Redirect package to your desktop. On your web server, create a folder in which to store the Login Redirect stuff; “client” or “clientarea” might be a good name, but it’s entirely up to you. An example location might be http://www.domain.com/client, and this is the example that will be used for all URLs for the remainder of this article.

To get rolling with the install, browse to http://www.domain.com/client/index.html. Read through the information, then hit the “Begin Installation” link in the top right corner of the page.

On the next page, fill in your database information as completely as possible. For the Installation URL, do not include the trailing slash ( ‘/’ ) on the URL, as this will cause problems. The URL should be http://www.domain.com/client and NOT http://www.domain.com/client/.

Be sure to set values for minimum and maximum password length, as leaving this blank will cause all passwords to break, as I found the hard way.

Submit, and setup your admin user on the next page. Do not change the redirect location. If you filled in your Installation URL correctly, as described above, then it will be correct.

On the final page of installation, you will be given code and told to create a config.php file in your client folder. There’s already an empty config.php file at that location, so just open that up and paste your code inside.

To finish the installation process, you should find a login link at the bottom of the page. Go ahead and login, and you should be directed to your admin area.

In the future, you will login from the URL http://www.domain.com/client/login.html. Your clients will also login from this address, and you should use this as your target URL if you wish to create a Client Area menu item in your TTG galleries.

With installation complete, return to your FTP application and delete the install folder from the Login Redirect files.

Any page you wish to protect will need to be modified manually, as documented on the page http://www.domain.com/client/index.html.

Using this script you can protect any individual image gallery or gallery index created by TTG Auto Index, with clients being redirected to their galleries on login.

And before you ask, the answer is “No, this is not something that I can build into TTG Pages or any other web engine. This setup process must be performed manually, and cannot be automated from within Lightroom.”

Finally, keep in mind that this is only one of many possible solutions for password protecting your galleries. The Zubrag.com script from my previous article remains a valid method of protecting galleries, and there are many other scripts to be found by performing a search for “password protection scripts” in your favorite search engine.

It’s been more than a year since I published my first article on file name conventions. The problem with the blog format is that important articles are often buried in time. And the problem with time is that it often changes our perspective on things. The purpose of this article is to once more bring the topic of file naming to the foreground, as well as to revisit, redress and expand upon my recommendations for file naming.

How you name your image files is important. It is far more important for many more reasons than I think most people realize. Adhering to a convention when naming your files can help you to locate specific images, organize your images, identify ownership of your images, correlate various renditions of your images in various locations, factor into search engine optimization, assist in client proofing and image sales, and more.

And while file names tie into the use of TTG web engines in a number of ways, which shall be discussed, this is not an article only for TTG users; this is an article for all Lightroom users, and all digital photographers.

First things first; let’s take a field trip. Open a new browser window and perform a Google image search for _MG_0001.jpg and/or IMG_0001.jpg, which are common default file names produced by many makes of digital camera. There’s no telling what you’ll find. And I think this illustrates the importance of always renaming your own image files, lest you become lost in this mash of anonymous, often poor quality imagery.

Now, open your Library and search for the same. If you find even a single image still retaining its default file name from the camera, then you haven’t been doing a good enough job managing your files. I know I’m guilty. Are you?

Naturally, every photographer will follow different rules for naming their files. In the course of this article, I will outline and provide support for my own reasoning in naming files. This is the way I think is best, though opinions may vary and you are welcome to disagree. My rules attempt to take into account various factors such as computer operating systems’ file handling, file handing on the web, file name consistency in various locations, file identification, Lightroom behavior and more.

As Lightroom users, the first thing we must take into account is Lightroom’s handling of file names. This is a consideration comprising two parts. The first, is our file handling preferences; the second is exporting from the Web module and will be discussed below. In Lightroom’s Preferences, go to the File Handling tab and locate the options for “File Name Generation”. Pictured below are my recommendations for how to setup these options.

By setting our File Name Generation rules this way, we give ourselves a sort of insurance against pilot error when naming files in the future. And this leads us to our first rule of file naming:

1. Do not use spaces or special characters in your file names.

Considerations taken into account by this rule include file sorting, Lightroom’s Web export behavior and web use.

Spaces or special characters in file names can cause a number of problems in sorting, web use and more. Lightroom recognizes this, and strips file names of spaces and special characters on export from the Web module, replacing them with underscores ( _ ). Rather than relying on Lightroom to do this on export, though, we should name the files in our Library so that Lightroom will have no reason to rename them for the web. This will ensure that your image file names on the web match perfectly the image file names in your Library, making it easier to move back and forth between the two, and also ensuring that you can make the most of your web galleries.

To accomplish this, avoid spaces and special characters when naming your files; use underscores where separation is necessary. Do not use dashes, exclamation points, parentheses, slashes, etc. Example file names might look like mc20070108Identifier001.jpg or mc_20070108_Identifier_001.jpg.

If your files are named correctly, the file names of the exported web gallery images will match the file names in your Library.

With matching file names across the board, it’s easy to isolate files in your library in accordance with the feedback collected by the client proofing features in many TTG galleries. Feedback comes into your mailbox as a comma-separated list of files for each category of feedback (all selections in a list, all 5-rated images in a list, etc.).

You can copy this list of comma-separated files and paste it into Lightroom’s Text filter to isolate the specified images in your Library. The filter should be set to Text | Filename | Contains, as pictured below.

The filtered images can then be saved as a Collection for processing.

In summary, the only characters we will be using in file names are letters, numbers and underscores.

2. Begin file names with an alphabetic identifier.

Considerations taken into account by this rule include file sorting, file identification in your Library and web use.

File names should begin with an alphabetic code or keyword that identifies you as the photographer. You might use your initials or your name, but this should be something that will be consistent for all of your images. The reason this identifier should never or rarely change is that the next step in the file name will be the date (see below), which will be used to sort our images chronologically. If this front-end identifier varies from image-to-image, it will invalidate our sorting by date.

But this begs the question, then why not begin with the date? The answer is the web. In using Lightroom to export galleries, your file names will often be used in the gallery source code to fill in id or class for various page elements. It is invalid for either id or class to begin with a number or special character; they must always begin with letters, or your page will contain validation errors. As a precautionary measure, and to ensure web validation according to W3C standards, it is best to adhere to this rule.

Because your initials or name are not likely to vary, they make an excellent front-end identifier for your files. By using a photographer identifier up front, this also makes it easy to separate images from multiple photographers — if you have a second shooter on a wedding job, for example; or if you’re on location and your assistant takes a nice photo of you that you’d like to save, but not mix in with your own shots.

Having this identifier will also help your clients to identify your files amongst others when they receive or archive files from multiple photographers. Because your files all begin with your initials, they will always be grouped together in folders.

My name being Matthew Campagna, my identifier would be “mc”, and our file name in-progress is:

mc.jpg

3. Date your files in the format YYYYMMDD.

Considerations taken into account by this rule include file sorting.

One of the key concepts when naming files is to place your broadest identifiers first, and to narrow your identifiers as your move deeper into the file name. Your name will not change, making it the broadest possible identifier; the date will change and daily. But it is important to keep your images in chronological order, as capture time makes for a natural organizational structure.

In keeping with the broadest-first rule, we begin our dates with the year (YYYY), then the month (MM) and finally the date (DD). This will ensure proper chronological sort order on your computer.

For the sake of argument, however, let’s try it another way. Americans often follow the rather backwards habit of writing their dates in the order MM-DD-YYYY. A group of files named in this way would sort improperly, as in this example:

01-10-2010
01-11-2009
01-11-2010

In order for the computer to sort files in the correct order, the year must come first, followed by the month and then the day. Our file name in progress now looks like this:

mc_20100110.jpg

4. Use descriptive keywords in your file names.

Considerations taken into account by this rule include file sorting, file identification in your Library and search engine optimization on the web.

When placing your images on the web, the most important piece of information that search engines are capable of using to identify your images is the file name. It is therefore prudent to make your file names descriptive through the use of keywords. For file sorting purposes, keywords should follow the date and should appear with the broadest keyword first, narrowing in specificity with each subsequent keyword. Keywords should be separated by underscores. For example:

Italia_Firenze

In this example, “Italia” is the broadest keyword being the name of the country, while “Firenze” becomes more specific in naming the city. We might narrow further by adding additional keywords for locations within that city:

Italia_Firenze_Duomo
Italia_Firenze_Ponte_Vecchio
Italia_Firenze_Uffizi_Gallery

For the sake of argument, see what happens when this broadest-keyword-first rule is not followed:

Coloseum_Roma_Italia
Duomo_Firenze_Italia
Eiffel_Tower_Paris_France
Ponte_Vecchio_Firenze_Italia
Vatican_Roma_Italia

As you can see, our cities and countries get all mixed up due to our file system sorting by the first letters of each specific location. Here’s one final example that might work well for files from a client shoot, in the order [ Client Name ]_[ Location ]_[ Descriptor ]:

Maxim_Los_Angeles_Grace_Park
Maxim_Los_Angeles_Tricia_Helfer

Or:

Starbucks_Seattle_Exterior_Tables
Starbucks_Seattle_Exterior_Walking
Starbucks_Seattle_Interior_Chair
Starbucks_Seattle_Interior_Counter
Starbucks_Seattle_Interior_Tables

Building our in-progress file name, let’s take it back to Italy. Here’s our example thus far:

mc_20100110_Italia_Firenze.jpg

5. End it with a four-digit sequential counter.

Considerations taken into account by this rule include file sorting.

Why four digits? Say you’re shooting a wedding. You’re definitely going to shoot more than 100 images, probably going to shoot more than 999 images, but will likely not shoot more than 9,999 images unless you’re some kind of masochist. And so the four-digit counter is most often an excellent all-purpose fit. And so, our final file name might look like this:

mc_20100110_Italia_Firenze_0001.jpg

Coda

And that’s it for file names. What have we accomplished in this process?

We now have a file naming system that produces file names which …

• … are identifiable by the photographer who took them.
• … are identifiable and searchable by date or keyword in our library.
• … will sort in proper chronological order on any computer file system.
• … will remain consistent between your Lightroom Library and Lightroom-generated web galleries.
• … utilize keywords to improve search engine optimization for each individual image and for our image gallery on the whole.
• … are valid values for use in XHTML source code for id and class attributes.
• … fully translate back into our Library when using TTG client proofing options in engines such as TTG Highslide Gallery or TTG Client Response Gallery, or returned from shopping cart services such as PayPal or Fotomoto.

In closing, it’s easy to use Lightroom’s Filename Template Editor to create a template for naming your files in this fashion. Here’s how to setup your template:

Then you will only need to enter underscore-separated keywords when renaming files; the template will take care of the rest:

For more information on using the Filename Template Editor, see the Adobe Help Center.

As usual, feedback on these methods is welcome. Everyone has their own take on file naming, so if there’s something you feel could be done better in another way, let’s hear it in the comments.

There are more than 20 different web engines available here at The Turning Gate. More often than not, its the paid engines that receive the bulk of the attention. After all, they keep this place going and provide me the most motivation to work on them. Many of the engines here are available as free downloads, however. For those who may have overlooked them, the following is a list of those free engines.

HTML Galleries

TTG Panic Gallery

Flash Galleries

TTG Simpleviewer-2

TTG Simpleviewer

TTG Autoviewer

TTG Postcardviewer

TTG Polaroid Gallery

TTG PhotoStack Gallery

Special Purpose Engines

TTG XML Maker

TTG Viewport Sizer

In addition to the purely free downloads listed above, free demo versions are available of the following TTG engines. The demo versions have various limitations placed upon their functionality, but allow you the opportunity to test the engines before making a purchase.

HTML Galleries

TTG Highslide Gallery

TTG Highslide Gallery Pro

TTG Horizon

TTG Client Response Gallery

TTG Shadowbox Gallery

Special Purpose Engines

TTG Pages

The Turning Gate gets a brief shout-out in David duChemin’s Vision Mongers, published in November. According to the product description, “For those who want to make the transition into the world of vocational photography–staying true to your craft and vision, while fusing that craft with commerce, VisionMongers is a great place to begin your journey.” In discussing the use if the Internet in promoting your craft, on page 143 duChemin writes:

Adobe Lightroom’s Web module can create some stunning galleries using templates from the simple to the complex. Best of all, they’re either free or inexpensive. They require some tinkering, but for the budget-minded they’re a great place to start. Do a Google search for Lightroom galleries, or begin at LightroomGalleries.com. The Turning Gate (Lightroom.TheTurningGate.net) is also excellent.

David duChemin is an assignment photographer specializing in humanitarian projects and world photography. A passionate contributor to the international photography community, duChemin’s first book, Within the Frame: The Journey of Photographic Vision, received worldwide acclaim for its vision, passion, and depth. Find David online at Pixelatedimage.com.

Fotomoto has been generating some buzz recently. The Fotomoto Blog has been updated with some of the textbites and links to the articles, and Fotomoto user Richard Vanek has written a detailed review of Fotomoto’s print and package quality. For anyone that’s been on the fence as to whether to implement the Fotomoto features in TTG Highslide Gallery Pro, this makes for good reading.