File Delivery Overview

The greatest number of workflow problems occur during file delivery. As a file is moved from a photographer's workflow into that of a designer, art director or retoucher, clear communication is essential to prevent accidental and unwanted changes from being applied to your file.

Why is there an (almost) universal file delivery problem?
Questions to ask to make file delivery easier
What about delivering unrendered files?

Why is there a (almost) universal file delivery problem?

The difficulty comes from the wide gulf that exists between photographers: those that do not want to (or don't think they need to) do any more work other than make the image files available, and those photographers that would like to control the look and quality of their images all the way to the press sheet.

File delivery can be complex due to the large number of potential uses of digital image files and the large number of options for delivery files. The two main categories, rendered files (standard format) and unrendered files (raw format), further break down into files that come from an optimized workflow and those that come from a batch workflow. Therefore, we break the file delivery section down into rendered and unrendered delivery. We further break down rendered file delivery into files that come from an optimized file workflow and files that come from a batch workflow.

In addition, we provide a checklist that outlines the basic file delivery questions. We provide the checklist as a PDF download that can be emailed back and forth to help form the questions and answers that will make file delivery an easier process.

Questions to ask to make file delivery easier

What will the files be used for?

In the absence of complete information, or if the file will have multiple uses, then the delivery files should be in the highest resolution the camera offers and should only have capture sharpening applied. It also implies that the image receiver is responsible for all post-production work other than basic color balance and tonal corrections.

What size and resolution are required?

This question needs to be answered very specifically for those delivering optimized files. For those delivering batch output files, the main criterion is that the files are large enough for the intended uses. In this age of electronic delivery, it is helpful to at least specify screen resolution or print resolution since this will have a major impact on the bandwidth needed to upload and download efficiently.

What is the preferred color mode?

By color mode we mean RGB or CMYK. Most photographers prefer to work in and deliver RGB files. Most printers prefer to receive CMYK files. What happens in the middle has a great impact on how the photographers’ images appear in print. Who should do the conversions from RGB to CMYK is one of biggest unresolved digital photography workflow issues and we would like to resolve it here. We recommend  that photographers deliver CMYK whenever possible for jobs going to print. Photographers need to educate and prepare themselives for this output if they aren’t experienced with CMYK.

What is the preferred color profile for RGB files?

While not yet an industry standard, the basic rule of thumb in color profiling is to deliver sRGB files for web, screen and projection, and to deliver in Adobe RGB (1998) for print. Unfortunately, many photographers have learned from experience that if the image receiver is unknown, or does not understand this question, that they are better off delivering all files in the sRGB color space. As you can see in our color profiles section, sRGB for print may result in loss of color gamut that could have been printed.
Read more about RGB profiles in the Color Space and Color Profiles

What is the preferred color profile for CMYK files?

The biggest reason that photographers are reluctant to deliver CMYK files is because of all the mystery and myth that surrounds which CMYK profile they should use. CMYK profiles are device dependent, meaning that each type of press (and sometimes even each individual press) has its own color characteristics. There is also the fact that papers used in commercial printing vary widely in color and have widely different ink absorbability – from gloss coated, to newsprint. However, the good news is that commercial printing has by necessity become much more standardized. Printers have learned that they need to print to the recognized GRACoL, SWOP, SNAP standards in the U.S. and the FOGRA standards in Europe if they want to be considered for the majority of print jobs. Bottom line, a handful of standard CMYK profiles cover most of the possibilities, and printers have the tools to adapt those standard profiles to specific papers.

For sheetfed offset presses, use the Coated GRACoL 2006 profile. For reproduction on web presses, use the newer SWOP 2006 standard profiles. Use SWOP2006_Coated3v2 for high quality web sheets, and SWOP2006_Coated5v2 for the less expensive, lower quality sheets. For newspapers, start with the SNAP standard for newspaper reproduction. These three standards are commonly used by advertisers preparing files for reproduction on a variety of publications and will often be the best starting point when preparing CMYK files for clients. If your client will be preparing your photo for reproduction on a non-standard printing condition, it is important to receive detailed instructions on how to best prepare your files before you deliver them to your client.

How should files be named?

Most image receivers accept what they are given. A few have implemented DAM (digital asset management) systems and use file naming schemas as part of their image organization. Most stock agencies have file naming schemes as well. Some image receivers change file names to suit their purposes, which can make communication about specific files difficult. Therefore, it is wise to put the original file names in the description metadata field to help matching up re-named files to the originals. As a last resort, files can sometimes be matched up by comparing the EXIF file creation data if EXIF data was preserved in the derivative files.

what type of file to deliver
Figure 1 There are many choices to make before you can reach agreement on the best type of file to deliver.

What is the preferred delivery file format?

Rendered file delivery formats are usually JPEG, TIFF, or rarely Photoshop (PSD). PDF format can be used for image files although its main use is for files that contain both vector and raster data such as those from page layout programs like InDesign and QuarkXPress. One feature of PDF is that it supports password protection, although this feature has limited real-world functionality. Some publishers and service bureaus specify EPS as a preferred format, but we recommend that you use this delivery format only if it is specifically requested. Some museums have standardized on JPEG2000 due to its enhanced feature set, which includes improved lossy as well as completely lossless compression. JPEG2000 is not widely supported by web browsers and is generally not used in the professional photographic, print or design community.

JPEG is the most common delivery format since it takes up much less space on delivery media and uses less bandwidth for electronic delivery. JPEGs saved with the least compression at the maximum quality setting are virtually indistinguishable from uncompressed TIFF files. Standard JPEG format has several important caveats when compared to TIFF. These do not impact their usefulness as a delivery format as long as these features are understood. JPEG files can be very highly compressed, which means it is easy to introduce visual and completely destructive image artifacts if the Photoshop save quality drops below 6 (on a sliding scale of 12). Different applications and even Photoshop Save For Web & Devices use different scales, which can be confusing. The best rule of thumb is to not go below the mid-point of any JPEG save scale if it can be avoided. Quality 8 on a scale of 12 is the minimum that should be used for delivery files. If you think there is any chance that delivery JPEGs will be altered and resaved as JPEGs, it is best to save at quality 12. It is a good plan to explain in a delivery memo or delivery readme file that JPEGs should be saved as TIFF or PSD files before any additional work is done on them. This will minimize compression artifacts on resave (and educate the uninformed) and allow the use of layers and other Photoshop features.

TIFF is probably the second most common delivery format after JPEG. Many design directors and publishers prefer it because it is an uncompressed format and doesn’t lose any quality with multiple saves. TIFF also has the advantage of supporting greater bit-depth and layers. The disadvantage of TIFF is size: it is approximately ten times larger than JPEG. TIFF can be compressed both lossless (LZW) and lossy (ZIP, JPEG). However, LZW compression doesn’t result in much size saving (and may actually increase file size for 16-bit TIFFs). ZIP compression results in a slightly smaller file size than LZW, and JPEG compression comes very close to standard JPEG compression size. However, few TIFF readers, other than Photoshop and InDesign, read ZIP or JPEG compressed TIFF files. JPEG compression offers one advantage over simply saving as a JPEG, and that is that layers are preserved. JPEG compressed TIFFs do not support 16-bit depth. We recommend delivering compressed versions of TIFF only if they are specifically requested.

PSD, the native Photoshop file, is used more for the creation of rendered master files than as a delivery file format. It supports the complete range of Photoshop features such as multiple layers, adjustment layers, type layers, layer effects, paths, multiple channels, screening, etc. It is this extreme functionality that makes PSD a good option for master files. PSD’s uniqueness has been somewhat diminished now that TIFF and PDF can save everything that can be saved in a PSD file. PSD files can be much larger than TIFF files if “maximize file compatibility” is turned on, since this causes a flattened composite version of the file to be saved as a file within a file. Turning this feature off prevents some applications, Expression Media (now Media Pro) for instance, from showing a layered PSD file as an image file, which is not too useful if you catalog layered master files. We recommend that unless PSD is specifically requested, use either TIFF or JPEG for delivery.
Read more about rendered file formats in the Rendered File Format

What about delivering unrendered files?

Some clients request, and some photographers deliver, raw or DNG files. We do not recommend the former, and only recommend DNG in special circumstances.
Read more in the unrendered file delivery

Should delivery files be 8 bit or 16 bit?

Delivery files should almost always be 8 bit. The exception would be if the hand-off were being made to a retoucher who needs the best possible starting point for doing additional work.

Should all delivery files be flattened?

Delivery files should almost always be flattened. The exceptions would be if the files are being handed off to a retoucher, or if you want to convey what the output sharpening should look like, but don't know if the files will be resized. In this case, you may elect to deliver a file that has the sharpening applied as a layer. Be sure to properly label that layer!

What file sharpening is required?

In general, all digital image files should have capture sharpening applied, though this step is not necessary for all cameras.
Read more in the camera sensor

Sometimes specific areas of an image are sharpened and others not sharpened. This workflow step is referred to as creative sharpening, and only occurs in an optimized workflow. Beyond that, only image files that are at final size (or very close to it) should receive output sharpening. Sometimes a generic output sharpening is applied if it is likely that the image receiver will be unaware of the need for output sharpening. This is an area that benefits from good communication (and education).

What metadata is required to be in the files?

All delivery files should have basic metadata embedded. All photo editing programs, browsers, and cataloging applications can be used for this function. Be aware that applications that embed the XMP metadata format are preferred over those that embed only the legacy IIM format. Applications that embed both are best, however. XMP format allows the use of custom metadata panels, which is the best tool for embedding specific metadata that is not in the IPTC standard schema. Rights usage is an area that has not been well supported by standard IPTC schemas. This will hopefully be addressed by use of custom XMP metadata panels that support PLUS (Picture License Universal System) licensing metadata.

What is the best delivery media or method?

We are moving from a world of physical delivery to one of electronic delivery. Still, there are advantages to delivering image files on write-once media. It provides an indelible record of the condition of the delivery files, their file names and metadata. Files delivered electronically can be altered, renamed and deleted. There is also the slight chance that they can become corrupted, and there are bandwidth constraints for large deliveries and deliveries to those without high speed Internet. Yet, electronic delivery is the future so it is important to understand the methods and services that are available. It is important that all parties have complete delivery information, whether it is physical address, FTP information, the maximum size that can be used for email delivery, or to test file hosting and delivery services to make sure they work for the image receiver.

What information should be included with the delivered image files?

We recommend the use of readme files, which can be simple text files, or PDF files that describe what is being delivered. Good pieces of information to include are the color profile, file size and resolution, file formats, and rights and usage information.

Up to main File Delivery page
On to File Delivery Checklist

feedback icon
Last Updated September 22, 2015