It should come as no surprise to anyone who has talked to me or
worked with me regarding digital images or stock photography that I am a
great proponent of embedded metadata in digital images, and that in my
work as a consultant to other photographers and stock photography
agencies I have implemented strong use of embedded metadata in digital
images to help solve some of the problems of "orphan images". It
certainly will not be a surprise to the Members of Picade who have had
to struggle to come up to speed with our requirements to do so since
prior to our inception.
In a major Chicago ad agency conference room recently I was asked a
fundamental question by an art buyer I have heard countless times in
many forms in the last ten years as digital images have became the norm,
and that has recently given rise in the US Congress to the specter of
"Orphan Works" legislation:
"One of my [art directors|researchers|secretaries|friends|...] found
this image that they want to use but they [didn't|can't] tell me where
they found it. How do I find who owns it and how to license it?"
The fact was that the digital image in question (which they thought
might have been one of mine and was unfortunately not) had no
identifying characteristics: no visible or invisible watermark, a
numeric filename that gave no clues about anything, and no embedded
metadata.
The image was an "orphan" that had to be discarded for consideration as
the anchor image in a major ad campaign because it was impossible to
find the owner [cue sound of gurgling water from a flushing toilet].
Photographers and agencies: every image that leaves your hands or those
of your agents or distributors must have embedded in it as metadata your
copyright notices, your contact information, image identifying
information, and basic terms of licensing AND be properly registered
with the Copyright Office. Anything less means that you will likely lose
license income and may suffer from image theft or the penalties of any
"Orphan Works" legislation that may be passed in the future - which
might even strip you of your copyright in the images or the ability to
derive licensing or penalty income from prior uses that were not
properly licensed.
Adding other identifying features such as a "digital slide mount" with
your name and contact information visibly displayed outside the image
area, a distinct and recognizable watermark, a filename that
incorporates your web domain as well as a unique image identification,
all are helpful as well.
A sample "digital slide mount" comp image of my own, similar to what I
eventually hope to produce automatically for Picade's website for
downloadable comp images:
I am in the implementation phase of Picade's first customer oriented
website that will customize our presence on PhotoShelter, and some of
the additional steps that I referred to the immediate paragraph are not
immediately possible because of the design and functionality of
PhotoShelter's system, but will definitely be part of the implementation
of Picade's first stand alone website presence [also concurrently in
development]. All of the previously mentioned embedded metadata are
there in our images now, and I had a very significant struggle last year
on behalf of all photographers to keep PhotoShelter from routinely
stripping all of the embedded metadata from displayed images, which they
no longer do as a result.
One of the competing interests in designing and hosting a website is to
make the pages (and displayed images) download and display as fast as
possible for the viewer and which minimizes the cost of bandwidth for
the website owner.
This means the html markup and the images themselves should be as lean
as possible, and our industry's primary image tool Photoshop has had a
feature since about version 6 called "Save for the web" to make images
that were "optimized" for the web by among other things, stripping out
all the embedded metadata in the image to make the filesize of the image
smaller and to therefore make the image download and display on the web
faster.
This has put Adobe squarely at odds with the competing interests of the
original image creators and the webs' design and web hosting side of the
business, and Adobe have grudgingly and somewhat sheepishly acknowledged
this fact by burying within the "save for the web" interface of recent
versions of Photoshop the option to include some XMP metadata within the
stripped down image. In a posting on his Adobe blog,
John Nack
references how to do this.
Unfortunately, as I discovered last week while helping one of our
Members and a web developer he was working with on an image metadata
display issue, the resulting embedded XMP metadata in a CS3 "save for
the web" image does not contain all XMP metadata, only effectively the
metadata that corresponds to the original Photoshop "fileinfo" binary
IPTC metadata, and explicitly not the complete set of the newer IPTC4XMP
metadata including the "Creator Contact" information.
Early this week a reference to the John Nack posting on the Adobe blog
referenced above showing how to add XMP metadata to a "save for the web"
image was made on another private professional group forum, and I posted some
information there regarding the issues I had found and a workaround
involving an open source command line tool, binaries of which I have
posted here on the download files section of the Agora for both Mac PPC
and Win32. If I can find a way to get a binary compiled for Mac Intel I
will post that as well.
The workflow is basically four steps, and uses Photoshop CSn both to
create an XMP metadata packet and to create stripped down "save for the
web" jpeg images, and the open source wrjpgxmp command line tool from
Bert Bos of the W3C that
enables you to embed an XMP metadata packet
into the stripped down jpegs without recompressing and re-encoding the
jpeg image itself.
-
Get the Bert Bos jpeg xmp toolkit either from his website as a C language
source distribution
and then compiling it, or as immediately
useful compiled binary executables by downloading from the
files section here.
With respect to the Mac PPC binary, thanks to
Aaron Bieber
for compiling it and sharing. This is a one-time step.
-
Use Photoshop CSn to create an XMP metadata template of the information
you want to embed in the image(s) - a step that should be very familiar
to Picade Members from their workflow of preparing images for Picade. If
you are using Photoshop CS, you will need to obtain and install the IPTC4XMP
metadata input template that comes already installed
in Photoshop CS2 and CS3. If all you are doing is embedding essentially
static contact and copyright information metadata, this is a one-time or
at worst a single yearly step, but the ease of creation makes it
possible to use this for shoots, assignments, or projects with relevant
specific additional metadata as well.
-
Create optimized jpegs for your end website use by soft previewing in
Photoshop using either the generic or PC monitor profile to properly
visualize your work results, converting to sRGB profile, then using
gamma, levels, curves, and color correcting your image for Gamma 2.2
display, and appropriately sharpening and resizing the image to your
final output size. "Save for the web" as a jpeg without using the option
to embed XMP metadata, at a size/quality setting that is appropriate for
you purposes, in a directory where you will do your later work in this
workflow. This is essentially what you have always done (or should have
done) in the past.
-
Embed the XMP metadata template you created in step two in your images
using the Bert Bos wrjpgxmp command line tool. In the case of the
specific metadata packet that I personally use (derived from Photoshop
CS, CS3 might make a smaller packet), this increases the size of the
stripped down jpeg image by 3793 bytes per image after embedding.
To expand on the hard bits of this a little, you create a minimal XMP
metadata template in Photoshop CSn containing your personal
contact and licensing information to use with the workflow by:
-
Create a "new" image (Control-N, Option-N) - this has no embedded Exif
or other metadata from previous work, a very important step to minimize
the amount of "stuff" in the generated XMP datafile. Just use the
defaults in the new image dialog, we'll be throwing the file away later.
-
Open "fileinfo" (Alt-Control-I, Alt-Option-I) for the new image. Using
the IPTC4XMP and other metadata templates, create your contact
information, copyright status flag as "marked", copyright notice,
copyright information url, rights usage terms, and special instructions
and any other information you want to embed in the processed jpegs.
-
Save the generated "fileinfo" metadata as a template using the arrow
button in the upper right hand corner of the fileinfo dialogs to an
appropriate name that you will recognize. Cancel the fileinfo dialog,
delete the temporary imagefile, and exit Photoshop.
-
Find the generated "fileinfo" XMP metadata template file on your
computer (it will be named as you named it with an ".xmp" filetype
extension, on Windows it will be under "C:\Documents and
Settings\\Application Data\Adobe\XMP\Metadata Templates") then
copy it where you will be working later.
Screen captures of the process follow (I cheated and loaded a
pre-existing metadata template to save retyping, so the initial
Description fileinfo dialog has an anomalous "Created" date from last
year at the bottom at the bottom), and I am presenting them at "life size"
so that they are readable, even if it will mess up the web document
display a bit.
Preparing your images prior to "save for the web" should of course be
done on a calibrated, profiled, and color managed system. The biggest
part of image preparation is properly previewing your visual changes to
the image by soft proofing, by first setting it up for either a Windows
RGB or a generic Monitor RGB profile, and then turning on soft proofing
(Control-Y, Option-Y) while you are working on your images, and in my
opinion, by using a "stair step sharpening" image reduction process
similar to the Photoshop action you can buy from Fred Miranda, or
that is detailed in principle by David Riecks on his Controlled
Vocabulary website, to counter the detail blurring that occurs when you
reduce a digital image in size.
The final step requires opening a "command line window", "dos prompt
window", or "terminal window" to your working directory and running a
command similar to the following (assuming the xmp template file is
named "template.xmp" and the minimal "save for web" jpeg is "input.jpg",
and your desired final filename is "output.jpg") and everything is in
the working directory:
wrjpgxmp -cfile template.xmp input.jpg >output.jpg
A screen capture of preparing the "digital slide mount" image used at
the start of this article:
Obviously this final step is a one-by-one image step that can be
automated using various forms of scripting specific to a particular
operating system or scripting language, but that is "an exercise left
for the student" <GGGGG>.
What I will say is that I personally name my imagefiles by the image
identifier used in my DAM system, with a postfix to the filename name
that indicates the class of the imagefile (I store several levels of
prepared imagefiles for use by reproduction size for print or the web),
and that downloadable "comp" images prepared by this workflow get named
with my domain_name+imageid+size_usage_suffix.jpg.
As an example, here is a web preview sized image of one of my Chicago
subcollection #D001 images #C030 maintained internally by me:
CHGOD001C030_P.jpg
For Picade, internally this images' master would become:
1002E00000CHGOD001C030.jpg
presented externally as a download protected "preview sized" image or swf:
1002E00A012FGM_P.jpg
1002E00A012FGM_P.swf
and the downloadable "preview sized" comp image (which in the future
will be a "digital slide mount" image) as delivered to an end user would
be named:
www.picade.com-1002E00A012FGM_P.jpg
When named in this manner, your image filenames are essentially globally
unique and contain information about their source (the domain name),
your personal image id, and a filesize reference that makes the image
unique within your own filesystem. There is other proprietary
information embedded that helps us when a customer requests pricing or
licensing information from Picade, but as noted, that is proprietary.
HTH.
Michael Beasley