Photomechanic is the metadata king

TLDR;

Photomechanic’s use of variables and code replacements makes metadata processing a highly efficient affair whilst producing better quality metadata. Photographers especially in sports and events fields should consider using a combination of Photomechanic with their favourite editing software.

This is a quick, simplified guide to explore what variables and code replacements are, both of which I’ll go into greater step-by-step detail in a future post.

Efficient metadata processing is an area where Lightroom is particularly deficient though Adobe may introduce similar features in a future version of Lightroom, until that time arrives, Photomechanic is the ultimate go-to for metadata processing.

Introduction

I have always been a stickler for streamlined workflows, even when I can save as little as a few seconds on each image it would amount to something significant over the course of shooting a major event lasting days to weeks.

So when I was first introduced to Photomechanic sometime around 2011, my initial reaction was “why would I want to use two pieces of software when I can do everything in Lightroom?”. After a brief look at the interface which looks like it was created and left intact since the 1980s combined with my vague understanding of the product, I kept calm and carried on with Lightroom.

It wasn’t until I watched this video by Dan Carr it became immediately apparent how powerful this piece of software is. I was always aware Photomechanic was quick at ingesting & culling (which I don’t find a huge issue with Lightroom as I use very conservative preview settings during import) but the metadata processing aspect is unbelievably good.

Photomechanic has the potential to not only save time on culling but more importantly embed metadata to a higher standard compared with Lightroom and do it much more efficiently. Right off the bat, the two features that make Photomechanic a compelling reason to use it exclusively for metadata processing over Lightroom are Variables and Code Replacements.

Variables

Variables have existed in Lightroom for a long time, you commonly see them when renaming files, you can use all sorts of variables to automatically streamline and beautify the file renaming process.

 
Oddly however Lightroom has excluded this paradigm from all other areas of their program – there is no concept of variables when using Lightroom’s IPTC metadata interface. Photomechanic takes this many steps further and not only allows you to use variables in the crucial area of IPTC Metadata (captions, keywords, titles, etc.) but almost any input field in the entire program can make use of variables.

Variables mini-101
A variable is essentially a placeholder for a piece of data. Looking at Lightroom’s rename tool above there is a variable called {Caption}, when the file rename tool runs, it automatically grabs the caption you entered for the image and inserts it into the {Caption} variable. There are all sorts of variables which can be used, {Caption}, {Title},{Camera Model}, etc. You can get the full list of Photomechanic variables here.

The problem Lightroom currently has is that you cannot use variables when entering IPTC Metadata and this in itself presents two problems:

• It is time consuming

Let’s say you have to enter a person’s name in the Caption, Title, Keywords and several other IPTC fields, you would literally have to type or copy/paste that name into each of those fields, this doesn’t sound like much of a chore but on a grander scale when processing a large amount of images, it all adds up.

• Reduced quality of metadata

Being that it takes a little longer to copy/paste data into various fields, in a pressure environment this reduces your likelihood of entering something wholesome like “Serena Williams at Rod Laver Arena on Thursday 11 January 2016”, because of time constraints you would usually only enter “Serena Williams” and move on.

This is where the power of variables in Photomechanic greets us. Let’s work through a very quick example; below is a screenshot of a template I used for editing at the MOTOGP. I used this particular template in circumstances where the focus is on 1 rider, I use a variety of templates for other situations as well which I’ll go into detail in another post.

Look above and you’ll see a number of variables, you can recognise the variables as they are encapsulated with curly braces {}. Again if you want to familiarise yourself, here is a full list of Photomechanic variables.

The only action I have to do here is enter the rider’s number into the “Persons shown” field, in this case was ’99’ and look what happens next:

Wow! Look at that detail in the caption (let alone the keywords)? Considering I only had to enter the rider’s number, Photomechanic automatically populated the rider’s name, country, team, constructor as well as auxiliary data such as the day and date on which the image was captured.

Compare the before/after and you’ll notice Photomechanic has gone through and replaced the various {variables} with the associated data.

Now I haven’t been completely transparent here; Photomechanic automatically replaced {photog} in the captions and keywords with ‘Damir Ivka’ because the Creator/Photographer field contains ‘Damir Ivka’, but how did Photomechanic know that rider number 99 was JORGE LOREZNO? In addition to this, how did Photomechanic automatically populate JORGE LORENZO’s team, constructor and all things related to JORGE LORENZO?

This is where a nifty little feature called Code Replacements comes in… 

Code Replacements

If you’re a data nerd, think of Code Replacements akin to using VLOOKUPs in Microsoft Excel. Prior to the MOTOGP season, I go through and update a table I keep of all riders in the MOTOGP for the upcoming season. The table looks something like this;

When I entered ’99’ in the Persons shown field, Photomechanic refers back to this table, looks up rider 99 and then automatically retrieves the relevant data when called upon.

Code Replacements 101
Invoking the Code Replacement function in Photomechanic takes the form of this syntax:  

\{variable}#1\

Anything encapsulated by \\ is essentially asking Photomechanic to go lookup some data in a table and return a field. How does photomechanic know what to lookup? That’s done by the {variable} portion of the code: \{variable}#1\  

After finding a match in your table based on the {variable}, how does photomechanic know what to return? That’s done by the #1 portion of the code: \{variable}#1\, the number corresponds with the column you actually want to return, related to the {variable} passed in.  

Let’s walk through a real-life example; looking at the MOTOGP template, in the caption I wrote: 
\{persons}#1\ of \{persons}#4\ 

This then translated to:  
JORGE LORENZO of SPAIN

If you look at this and compare with the table you can see what’s happening here but let’s quickly go a little deeper.  

\{persons}#1\ is telling Photomechanic to grab whatever is entered in the Persons shown field {persons}, in this case ’99’, go find that record in the MOTOGP table I built and return the data that relates to ’99’ from the first column indicated by #1.

Therefore \{persons}#5\ will return ESP because {persons} = 99, Photomechanic looks up 99 in our table above and goes to the 5th column for 99 and comes back with ESP. Side note: this is why I have column numbers in row 1 of the table, it’s not required but I can easily identify the relationship between the column numbers and the actual column names.

Don’t worry if this is still lost on you, I will go step by step and explain in greater detail how to create these templates and explore these options in another post but for now, just know that this functionality not only greatly increases the speed of applying metadata but also increases the quality of your metadata because just by entering a name or in this case rider number, Photomechanic can retrieve all sorts of information based on the data you feed it and provide more detailed captions.

This method does somewhat exist in Lightroom, but it only exists for keywords where Lightroom can automatically retrieve ‘synonyms’ for a particular keyword but again the problem here is it’s limited just to keywording alone. Even then, you cannot control what synonyms you want returned, Lightroom will just return all synonyms related to the keyword.

How can Photomechanic improve?

Photomechanic is already so far ahead of the game where metadata processing is concerned because of it’s programmatic approach to this mundane task of populating metadata but one feature I think could further enhance and improve this process is to introduce a concept of “if then else”.

For example you could do something like, if the {persons} field is empty, then use the {photog} field instead, or if the capture date {date} <> 2015 then make it 2016.

My head is exploding right now with the possibilities of combining something like this with variables and code replacements to take metadata processing to the next level and further improve efficiency.