|
<< Click to Display Table of Contents >> Navigation: Nodes > Tasks > UP Metadata > NC to metadata
|
Name Convention to metadata. To extract metadata values from sub-strings of the paths and filenames of the input files and injecting them into metadata tokens that we can then use in the Name Convention syntax (rather than getting their values from embedded metadata in the internal file headers). The new token values will then be passed trough the output connectors and can then be inserted in new file names and file paths in posterior nodes when creating new media. or be used for any other metadata purposes.
This node has priority in case of duplicity (if a token with the same name is found on file embedded metadata it will be ignored) .
Example: let's suppose that you have declared a token named "version" in the Name Convention property of a Media Sequence node (or in a Watcher node):
[path][baseName][_version][_frame][.ext]
And let's suppose the input node loads a sequence in this style:
/test/MyClip_v45_13123.dpx
Now you connect that node to a NC to metadata node, which will analyze the syntax and will set the token "version" to the value "v45".
In that way you can use the version token in posterior nodes for including it in different places of destination paths and file names. For example, you could now connect the NC to metadata to an EXR encoder node, and type this in in the Dst.File Path property of the EXR node, :
[path]/[version]/[baseName][_frame][.ext]
In this example, the token "version" is re-purposed as a folder name rather than part of the name, which will create files like:
/test/v45/MyClip_13123.exr
In the above example the baseName token was left with only the initial part of the file name, so if we want the token "version" to also appear in the new file name we will need to add it explicitly:
[path]/[version]/[baseName][_version][_frame][.ext]
Which will produce:
/test/v45/MyClip_v45_13123.exr
Note that the NC to metadata node does not "create" any metadata tokens at all (all metadata tokens need to exist in the NameConventionPlaceHolders.xml file before they can be used). All what the NC to metadata node does is to extract their values from the name convention of the input files (rather than reading those tokens from embedded metadata in the media files, which is the default behavior). But that is not enough to create new tokens that didn't exist before
In the above example, the token "version" already comes in that file, so nothing has to be done. But any new tokens not existing in that file need to be added to it (before opening Mistika Workflows). However, before adding new tokens to this file it is highly recommended to search if they already existed, because the most common tokens used in media production are already there.
If the token is not existing, an easy way to notice it is because typing the token name (between brackets) in a File Path property should immediately appear in the contextual token list, and become green when the syntax is completed.
Finally, for complex cases where different interpretations are possible please remind this rule: The baseName token will always take the initial part of the name, and it will get as many characters as possible while still matching the name convention syntax. So something like the next example will fail to produce the result we wanted:
Let's suppose we have the original name convention as in the previous example: [path][baseName][_version][_frame][.ext]
And we get this file:
/test/MyClip_v45_other_something_13123.dpx
Then the baseName will receive this value (because it will get as many characters as possible while still matching the Name Convention):
/test/MyClip_v45_other
and then the "version" token will have to take the value: "something", which is not what we wanted.
To solve this type of rare situations you will need to define all the missing tokens, for example by defining enough dummy tokens as needed.
The next example will solve that problem by using this name convention in the input node:
[path]/[version]/[baseName][_version][_dummy1][_dummy2][_frame][.ext]
And before doing this you will need to define dummy1 and dummy2 in the SGO AppData/shared/config/NameConventionPlaceHolders.xml file (even if you don't want to use their values). So you will need to add these lines (in any category you prefer):
<placeHolder from="metaData" name="Dummy1">
<visibility>true</visibility>
</placeHolder>
<placeHolder from="metaData" name="Dummy2">
<visibility>true</visibility>
</placeHolder>
Another usage example is available in the documentation of the Change Name Convention node, which is commonly used in combination with this node.
Input: Files to be processed, with their name convention indicating the location of the metadata tokens.
Output: The input files, with the name convention tokens changed to their new values.
An introduction to all the Python tools in Mistika Workflows is available in the Python scripting tools section.
Information about library extension is available in the Mistika Python Extension Library
https://www.sgo.es/doc/python/
Property Label |
Property ID |
Schema Name |
schemaName |