File Lifecycle Overview

The four phases of image lifecycle

Understanding the digital image lifecycle is fundamental to understand how to put together the workflow that is best for you and the kind of work that you do. The lifecycle has four phases:

• Capture
• Ingest
• Works in progress
• Archive

Figure 1 These four phases of the image lifecycle repeat across all workflows, although the order of works in progress and archiving may change depending on software choice, and the steps within works in progress may expand or contract depending on how far the optimization process is taken as well as the output and delivery needs.

Capture

Ingestion

Ingestion is the first transfer from the camera to the computer. Two kinds of challenges are unique to the ingestion phase. The first is that there is only one copy of the image file, so it’s pretty vulnerable to corruption or loss. The second challenge is that a number of processing chores are best done at this stage. The ingestion stage is an important opportunity to use computers for what they do best—performing repetitive tasks quickly and reliably without a lot of user involvement.

Tasks for ingestion include the following: renaming, adding bulk metadata, adding rendering settings, backing up, DNG conversion (optional), sending to an image editor, and preparing for visual inspection.

Working

We use the term working files to describe images that have gone through the batch processes that are part of the ingestion phase but have not yet gotten to the safety of the archive phase. In this stage, you will generally want to do image preparation processes that make the images ready for the archive (as outlined below). Working files are in a state of rapid change, and are best handled by a different backup protocol, which is one of the reasons that it’s helpful to think of them differently than either the ingestion or archive phase.

Working files tasks include the following: rating for quality; basic grouping; image adjustment; proofing output; multi-image proof-stitching (panoramas and HDR, for example); preparation for archive (folder finalization, DNG conversion if needed); derivative file preparation, as needed; and validated transfer to archive.

Archive

We use the term archive files for any files that have been put in their permanent homes and safely backed up in a secure, long-term way. It is often the case that many original files are archived long before the final derivative files have been delivered.

Since the archive is the safe and permanent home for the photos, the goal is to move the images into the archive as quickly as is practical. We’ll take an in-depth look at how to structure the archive in the Directory Structure, Catalog Strategies, and Archive sections.

The creation of derivative files complicates the neat arrangement of the originals archive. Images get reworked at later dates (sometimes much later), and this messes up the backup arrangements that are so clean and easy with a single original archive. These files are high-value images, however, and need to be protected as much or more than any other image. (As a matter of fact, they are likely to be your most valuable images.) We'll outline how you can archive originals and derivatives separately so that you make the archive process as simple and secure as possible in the Directory Structure, Catalog Strategies, and Archive sections.

Archive tasks include backing up to a second hard drive; backing up to an additional media type; proofing, as needed; sending files back to the working files folder for reworking, as needed; and periodic data validation.

Originals and Derivatives

There are two different kinds of working files, original files and derivative files. Original files are raw or JPEG capture files created by the camera. Derivative files are files derived from those originals. Original files should pass through the workflow quickly and are often archived long before you make final derivative files. Original files should have only the minimum amount of work done to them, all of it non-destructive, before being archived.

Derivative files are images that need to be optimized in Photoshop and saved as standard file formats such as TIFF or JPEG, and possibly Photoshop PSD format. Derivative files are usually a much smaller portion of your image archive, however they often represent a large portion of your work effort since each one often takes significant time to process.

Batch workflow

The batch workflow has a short working file lifecycle. There are some differences in the batch workflow file lifecycle depending on whether the original capture files are rendered (JPEG) or unrendered (raw).

The batch workflow steps:

• A basic edit and organization of the shoot
• Rating the images
• Optionally adding additional descriptive metadata
• Image edits with the goal of optimizing well enough for proofing, output, and/or delivery. We recommend parametric image edits for both raw and jpeg capture.

Optimized Workflow

The optimized workflow has more steps and often a longer time frame.

The optimized Workflow Steps

• A basic edit and organization of the shoot
• Rating the images
• Optionally adding additional descriptive metadata
• Parametric image edits to the raw files with the goal of optimizing well enough for proofing
• Creation of a web gallery, online proof, PDF, or other method to create a set of proofs of the shoot. The proofs will be used to determine the “selects” that will become masterfiles
• Create masterfiles
• Create derivative files for output/delivery based on the specifications for final use. These files will be sized and sharpened for the final output media which may be screen, substrate, or both

All-in-one software

All-in-one applications can handle most (if not all) the workflow steps including ingest, work in progress, and archiving. Applications like Lightroom and Aperture can also be used for tethered capture, although each has different approaches and procedures. Lightroom and Aperture can be used to download image captures from cards. Both can provide parametric image editing functions for raw files (which are designed for PIE) as well as for JPEG which can also be parametrically image edited (but not as extensively). Both can be used as a hub to export files to Photoshop (or other raster image editor) for pixel based image edits. Both applications can then re-import the pixel edited image files to their catalogues.

When we call these applications “cataloging PIEware, we are describing that each application is built on a database, which provides a cataloging function. The database saves the previews and allows for virtual organization of the images into collections. The previews and organization are saved into the database (catalog).

This is very different from the way browsers or PIEware that do not have a database function. Not having a database requires these applications to build previews on the fly (takes time) or save them in a small cache. The lack of a database means that they are not considered to be digital asset managing (DAM) applications. Cataloging PIEware, on the other hand, can be considered to be a DAM application.

Separate applications

Although all-in-one applications for workflow are becoming increasingly popular, largely because they are making image cataloging easier, others find that managing workflow through a set of separate workflow applications such as an image ingestion application, followed by a browser application, followed by a cataloging application allows better control over the work order, and better tools for the separate steps.

Work order and application type

A working file’s lifecycle order is based on software application type. A cataloging PIEware application should allow you to put your original capture files away right after the ingest step. Although the files are effectively archived, additional work can be done to the files at anytime and the changes can be stored in the PIEware database, or written back to the files.

Figure 2 A cataloging PIEware application, such as Adobe Lightroom, creates an archive when you import files. This puts the archive workflow step ahead of the working step. The arrow points both ways since files are accessed from the archive as needed to create masterfiles, delivery and/or derivative files.

If you use separate applications for ingestion, working, and cataloging, the file's lifecycle order is linear (as the flow chart at the top of the page shows), going from capture to ingest, to working, and finally to archive. The catalog (or directory structure) becomes the hub for retrieving and working on the original files. In this scenario, it is usually the case that the archived files will be rewritten, if they are DNG, or have a new sidecar file written if they are proprietary raw files.