Capture Naming as Metadata

One of the primary jobs of a DT, especially on a high volume set, is managing images as they come in. This usually relies on setting the capture folder and some some basic tokens for setting the name. If the tech gets behind (or the photographer gets ahead) it’s easy to have images mis-filed requiring renaming, which, depending on the naming convention, can be complicated or error prone.

Current capture naming is just file naming, and thus once a name is set that’s what it is, no matter where that file is (or is supposed to be). Take the venerable <Destination Folder Name> token, which adds the name of the folder to the filename, one the most common naming schemes out there. However, when moving a file the name is no longer correct. Renaming is easy, but now you have to contend with file counters, other tokens, or plate info that’s been manually added.

However, if the filename wasn't a fixed piece of information and is instead based on metadata the name would always be correct.

Tokens

Using tokens not just for initial naming and renaming would mean the filename would always match the state of the metadata. So for instance, the naming scheme <Image Folder Name>_<Capture Counter> would always match the current image folder and global capture counter. Renaming a file would be as simple as moving it. Remembering to rename and set the counter would no longer be necessary.

Live tokens would also make it easy to remap metadata values for a given token. For instance mapping color tags used for tagging shot types (hero, grey card, plate) could be done automatically, and importantly, consistently. Similarly it’s common to add info about a plate to the filename (LT, DK, glow, empty set), which is really metadata that is traditionally captured as part of the filename.

In some cases the filename needs to hold a lot of information: brand, SKU, color, product name, select state, plate type, etc. Usually much of this is predefined and shouldn't be changed. Storing that information as metadata and rendering it with tokens would make it harder to accidentally change. For a theoretical tethered capture application perhaps the "filename" text field would actually be a tiny single-field metadata editor for only the data needed.

Fixing bad naming would be trivial. Perhaps on day one the client didn't care much about the naming, but on day two they've found a new appreciation for the art (of file naming, that is). For large shoots batch renaming can be a surprisingly slow process, and again complex if needing to keep some parts of the name in tact. With everything in metadata renaming the shoot is as simple as reordering the tokens.

A final benefit is the option of having multiple names for an image. The DAM can have one name, whereas the designers can have a shorter one, all tied together by an image ID. Or in the case of fixing naming, keeping the original as a reference while going forward with the new scheme.

Counting

One of the most important pieces of information is the most easily changed: the file counter. Some workflows want a single continuous counter for the whole shoot, others by shot. What happens if you import additional images from card or rename images? Current software treats all of these counters as separate, much to the chagrin of many a digital tech.

Computers, and I believe this to be an uncontroversial statement, are very good at counting. There isn't a reason for us humans to have to keep track of so many different numbers. There are a number of different counter tokens I believe would be useful.

• A "Global Capture Counter". This one simply counts up, and could be thought of as a unique ID for an image.
• A "Sorted Counter". Pick your sort type, typically date, and it gives an index into that list. Importing images would allow them to be easily sorted correctly.
• A "Sorted Folder Counter". The same as above, but on a per-folder level. Adding or removing images wouldn't require renaming.

Wrapping Up

Given the importance of correctly named images I believe we need to change how we treat them. In much the same way as "ImportantDoc-V1", "ImportantDoc-Final", "ImportantDoc-Final-Final" isn't the best backup method, relying solely on the filename, without leveraging the abundance of metadata available, isn't the best way to store critical information about the contents of a file.