Important Changes to Camera Bits!

Hot Codes

Print This Article 

  All Keyboard Shortcuts 

    Hot Codes are an advanced and powerful scripting feature mainly aimed at sports photographers who need to create custom variables. 

Code Replacements

    Code replacements are shorthand codes that have replacements (1 or more).  It is used a lot for sports photographers when they caption photos.  A user creates a “code replacement file” which is just a tab-delimited text file with codes in the first column and replacements in subsequent columns.

For example, this is a code “wc8” with two replacements:

wc8    Alex Ovechkin    Alex Ovechkin, Left wing for the Washington Capitals

    The user “invokes” a code replacement using a special delimiter character they can set, for example ‘=’.  When the user types “=wc8=” then as soon as the closing delimiter is typed, this is instantly replaced with “Alex Ovechkin”.  To access the second replacement listing the position and team, the user can type “=wc8#2=” and this can extend to multiple variations of the replacement (third, fourth, etc.).


    This gets more complicated when you throw in Photo Mechanic variables.  Variables are placeholders for metadata. Here are some examples.  Variables have curly braces surrounding the variable name.

Current date for sorting, with dashes
Serial number of the camera that took the photo
Lens aperture of the photo
PortlandIPTC City field
Dennis Walker
IPTC Creator field
Base filename without extension (e.g. ".JPG")
Nikon D5
Model name of the camera that took the photo
Star rating 0-5 given to photo by user

    Variables can be used to create codes. For example, several large news organizations use this technique for major games like Super Bowl where they have multiple photographers and they need to properly assign credits to the photographers for each photo automatically. They do this by creating a spreadsheet of the serial numbers for each camera used by each photographer (photographers typically have 2 or more cameras each). 

    They also want to assign the photographer’s position (e.g. Staff or Stringer), the folder name where the photos should be copied, and the editor’s folder who is editing their photos (e.g. some organizations may have multiple photo editors, each handling multiple photographers that the editor is assigned to). 

    For example, their spreadsheet may have the following 2 lines for a photographer (the spreadsheet is saved as a tab-delimited text file before being loaded into Photo Mechanic)

12345   Dennis Walker   Walker  Photo Nerd  A
67890   Dennis Walker   Walker  Photo Nerd  A

    The first column is code (serial number), second column (1st replacement) is “full” name of photographer, third column (2nd replacement) is “last” name of photographer, fourth column (3rd replacement) is “title” of photographer, and fifth column (4th replacement) is “editor” folder name (e.g. A-D).

    Photo Mechanic has a “Metadata (IPTC) Template” (aka “IPTC Stationery Pad” in PM 5 and earlier) which is a template of IPTC metadata that is applied to each photo as they are “ingested” (or copied) from the cameras either directly (tethered) or from a flash card inserted into a card reader. There are also the Ingest and Live Ingest dialogs that configure where photos are copied to (folder path and name), how the photos are optionally renamed, etc. So, we want the “Creator” to be “Dennis Walker”, and we want his position (Creator’s Job Title) to be “Photo Nerd”. In the Metadata (IPTC) Template we would then enter the following into those fields:

Job Title:

    The variable {serial} is evaluated to 12345 or 67890 depending on which of Dennis’ cameras took the photo. This number is used as a code and the first replacement is placed into the IPTC Creator field, and the third replacement is placed into the IPTC Job Title field.

In the Ingest dialog, there is a path where the photos are copied. For photos taken by Dennis’ cameras, we would want this to look something like:



   This can be accomplished automatically by placing the following into the ingest destination folder path (which is itself relative to the user-specified base ingest folder):



    As you can see, this gets complicated fast because of the syntax. Hoever, a bigger problem is that sometimes a photographer uses a camera model that does not record its serial number in the file or Photo Mechanic is unable to locate it. This breaks the whole workflow since all the codes are based-upon a single piece of metadata, the camera serial number.

Hot Codes

    Hot Codes solves the syntax complexity problem and provides alternate metadata sources for generating codes. Furthermore, if a code cannot be found, Hot Codes provide default replacements that are specific to the column being accessed.

    Hot Codes are implemented by adding declarations at the top of a code replacement file that defines the following:

  • Code Generators: Multiple code generators can be defined, each using different variable(s) and text.
  • Hot Code Names: Names given to each column title. Almost like creating a custom variable name.
  • Default Replacements: Default values for each column title if no code replacement is found for any of the code generators.

    Code Generators are defined by inserting a line starting with “//==”, followed by a tab, then followed by a string that includes variable(s) and optional static text. Multiple code generators can be defined (which gets around the current limitation of Code Replacements only relying-upon a single piece of metadata when being invoked). Think of these code generators as “try this OR that”.

//==     {serial}
//==     {fbas:0,3}
//==     {fbas:1,3}
//==     {model}
    Note: The “//” at the beginning of a line indicates a “comment” which means that the code replacement loader prior to Photo Mechanic 6 ignores these lines.

    This syntax allows you to add Hot Code definitions to code replacement files and make them still be backwards compatible with earlier versions of Photo Mechanic by treating them as comments. The Hot Code loader logic pays specific attention to lines that are normally comments but are followed by two special characters like above.

    {fbas} is a shorthand for {filenamebase} (all variables have a 4 character or less shorthand version). The syntax “:0,3” after the variable name is a substring extraction, meaning start at position 0 (first character) and then grab the next three characters. Likewise, “:1,3” means grab three characters starting at position 1 (second character). The reason for this is that cameras typically generate filenames like either “DJW_1234” or “_DJW1234” depending on whether the camera is in sRGB color space (first variation) or AdobeRGB color space (second variation). This is a standard Exif specification which most camera manufacturers follow. We just want the “DJW” part which we will get by one of these two code {fbas} code generators.

    Hot Code Names are like the column headers that one would traditionally add for a spreadsheet to identify the values in that column. If we want the first code replacement, which is the full name of the photographer, we can just call that “full”. The second column, which is just the last name (or nickname) of the photographer, we can call that “last”. The third column, which is the photographers' job title, we can call that “title”. And the fourth column, which is the folder name for the assigned editor (e.g. A-D) we can call that “editor”.

    Therefore, we add a single line to the hot code replacement file to define our “Hot Codes Names”.

    Note: The “first” column mentioned above is actually the “second” column if this were treated as a spreadsheet.

//##    full    last    title   editor

     Now, we add some default values in case a photo is ingested that has no code for any of the various code generators. Unlike regular Code Replacements, which has only a single default string for all non-existent codes looked-up, Hot Codes has a default value for each of the Hot Code Names. So, for the “full” name of a photographer that is placed in the Creator field of IPTC, we may want to say “Unknown” if no code is found. For the “last” name of the photographer used as part of the folder name path, perhaps we create a folder “Other” when no code is found. For the photographer “title” used for Job Title field of IPTC, maybe we just leave that blank as a default. And for the folder name perhaps we use “all” for the default.

//??    Unknown Other   E

  Therefore, if a photo is ingested and no code generator creates a code that we have a replacement for, the photo credit (IPTC Creator) will be “Unknown” with a blank Creator Job Title, and the photo will be copied into “/Photos/E/Other”.

    After these declarations for Hot Code, the user can add their normal code replacements, but now users can be identified by filename or model in addition to the serial number of the camera. For example, the following code replacement will be used based on a base filename “DJW_****” or “_DJW****”.

     DJW     Dennis Walker     Walker     Photo Nerd     A

  And the following code replacement will be used if Dennis is the only one use using a Sony Alpha 9:   

     ILCE-9     Dennis Walker     Walker     Photo Nerd     A

    Hot Codes are “invoked” by their Name enclosed in ‘[’ and ‘]’ characters. For example, to access the last name of the photographer, one can simply use “[last]” instead of something cryptic like “={serial}#2=”.

    By using the features of Hot Codes, organizations can more easily manage complex workflows. This is especially apparent for the configuration of the dialogs in Photo Mechanic. For example, in the Metadata (IPTC) Template, they can now simply enter the following text into the dialog fields instead of the above examples:

     Creator:     [full]
     Job Title:     [title]

    And in the Ingest dialog for the folder path, it becomes:    


    Not only are Hot Codes much more powerful than basic Code Replacements, but they are also much simpler to configure and therefore less error-prone.

Alternate Default Chains

    The default values for Hot Codes do not have to be static text, they can include variables. For example, if a code replacement can’t be found for a photo for the [full] hot code, which is used for the IPTC Creator field, we could try to lookup an alternate user-defined value stored in the Exif. 

    For example, some cameras can write an optional “comment” to the photos. Some photographers put their name there. So why not use that as a backup, if it is defined, before using the static text “Unknown”? Easy enough: Photo Mechanic has a variable called {comment} (or {cmnt}) that extracts this field from a photo. When the “pipe” symbol ‘|’ is used after a variable as part of a default value, Photo Mechanic will evaluate the variable and if the variable returns an empty string, then Photo Mechanic will continue to the next alternate (these pipe symbols can be chained).

    For example:

     //??     {cmnt}|Unknown     Other     all

Hot Codes in Code Replacements

    Just like variables (enclosed in ‘{‘ and ‘}’ pairs) are used for Hot Codes code generators, a hot code (enclosed in ‘[’ and ‘]’ pairs) can be used as a variable inside of a code lookup. For example, if there are several codes defined like “backupWalker” (for various “last” names of photographers), and each has a replacement that is a folder path to a backup for that photographer, then it is possible to use something like the following to generate such codes:


    And then the full code replacement (to a folder path) might be something like:    

     backupWalker     ~/dennis/Pictures/{datesortdash}

    When used as a secondary live ingest path, for example, Walker could have a copy of all his photos from his various cameras (and only his cameras) placed into this path for that day:


Hot Code Namespaces

    The definitions for Hot Code Names, Code Generators, and Defaults are specific to the current Hot Code “Namespace”. If you only have the need for one set of Hot Codes then you don’t need to be concerned with Namespaces. Your definitions for Hot Code Names, Code Generators, and Defaults will be part of the default “Global” Namespace and therefore it is not necessary to specify a Namespace when you use Hot Code Names within Photo Mechanic such as in the Metadata (IPTC) Template or Ingest dialogs.

    However, if you have two or more separate needs for Hot Codes in your workflow then you need to specify separate Namespaces. You can specify a new or current Namespace using with “//$$”, followed by a tab, then a string with your Namespace such as “ns1”.

     //$$     ns1

    Then any subsequent definitions of Hot Code Names, Code Generators, and Defaults (in the code replacement file being loaded) will be specific to this “ns1” Namespace.  Each code replacement file being loaded starts off in the default “Global” namespace.

    To invoke a Hot Code Name that isn’t in the “Global” namespace, simply prefix this Hot
Code Name with the Namespace followed by a period “.”


    By specifying the “ns1” Namespace, only Code Generators that are defined for Namespace “ns1” will be used. And if no codes are found, only the Defaults for Namespace “ns1” will be used.

    Keep in mind that all the actual code replacement definitions (codes followed by multiple replacements) are present in all Namespaces. Therefore you may need to be careful about how you generate your codes. For example, if one Namespace generates codes using the {iso} variable, and another Namespace generates codes using the {year4} variable, they could both “collide” if the value is 2000. Therefore, it may be necessary to prefix your Code Generators with a short text that identifies the meaning of the variable being used.

     //// Namespace "ns1"
     //$$     ns1
     //##     speed
     //// Namespace "ns2"
    //$$     ns2
     //##     decade
     //==     year{year4}

    Then “[ns1.speed]” would generate a code like “iso2000”, and “[ns2.decade]” would generate a different code like “year2000”.

     iso2000     two thousand ISO
     year2000     the2000s
    Note: It is possible, but not recommended, to have the same Hot Code Name in more than one Namespace. In one Namespace, the Hot Code Name could represent, say, the 2nd replacement value. At the same time in another Namespace, that Hot Code Name could represent the 3rd replacement value. But because the invocation of the Hot Code must specify the Namespace to disambiguate between these two, there will be different Code Generators used and any matching code replacements will use the appropriate numbered replacement (e.g. 2nd or 3rd). If you don’t specify a Namespace when invoking a Hot Code, then Photo Mechanic will use the default “Global” Namespace.


  • txt

Can't find what you were looking for?

Submit a ticket

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry About That!

Let us know how can we improve this article!

Select at least one of the reasons

Feedback sent

We appreciate your effort and will try to improve this article