Global

In the global section you can define settings that relate to all the libraries that are currently loaded.

Global Setup

Here your can define which setup file should be used. This controls which Global Config to load and edit.

The Recent config file is a history of the most recent configs. It shows up to 10 of the last recent config file paths. This is a quick way to switch between different library setups.

Setup configuration

Default values

First let’s have at look what default config value you can set:

label	key	description
Element-Number Padding	element_number_padding	Set the number padding for the naming convention. Value of 5 looks like this: fire_00023 default: 5
Frame Padding	frame_padding	Set the frame padding for a file sequence Value of 4 looks like this: filename.0001.exr default: 4
Filmstrip Number of Frames	filmstrip_length	Set the frames used for the preview filmstrip in the ingest view. No matter the length of the sequence, the filmstrip length will be this many frames. default: 24
Thumbnail Frame of Sequence	thumbnail_frame	Set which frame of a sequence should be used for the thumbnail frame. When the value is meaningful the software tried to detect some representative frame for an sequence default: meaningful
Re-number Frames of Sequence First Frame of Sequence	first_frame	If disabled, no renaming will be happening for file sequences. If enabled, it sets the first frame of a sequence when transcoding a file sequence. The files of the sequence will be renamed. default: enable = true and first frame = 1001 Some VFX studios like start with the common 1001 frame. Other studios start with 0 or 1. This forces the artist to align the correct range before working on a shot. It makes sure that the frame range of an element is long enough.

Color Code

The Color Code is a visual help to distinguish between the path items. Each color represents a different type of the items that you can drag'n'drop around to build the folder structure and naming convention. Some values are predefined, some are only known during the ingest phase and others can be set manually by you.

File path definitions

This is the part where you define your naming convention and file path structure

This is where you set the naming convention and file structure on disk.
You need to define the file path patterns so the software knows where to store the elements file data. These two path patterns are the most important path patterns that the transcoding template will use.

Types of path patterns

Which path patterns will be used depends on the output format and the transcoding templates setting for each library. There are two types of path patterns.

In transcoding template you can set this with the option: Type of output file

Single files

Single files are something like a movie file or single textures files. Files without frame count.

/some/path/to/element.mov
/some/path/to/element.exr
/some/path/to/element_v01.exr

Example when the single file pattern is used:

Copy of a single file like a movie file
my-movie-file.mov -> fire_000023.mov

Sequence files

Renderings or sequences with frame counter.

/some/path/to/element.1001.exr
/some/path/to/element_1001.exr

Example when the sequence file pattern is used:

For a movie file (source is a single file) that will be transcoded to a frame sequence with frame counter.my-movie-file.mov > fire_000023.1001.exr

Use '#' for the frame counter. The default frame count padding is 4.

Path Patterns

You can create a so called path pattern. A pattern is assembled by placeholder values. These values get resolved into the actual value on ingest/render time.

The reason is that we don’t know some values at this time because they are dependent on the element that you want to ingest. For example, the width and height is depending on the source item.

By using the combination of path patterns, predefined path values and custom path values,
you should be able to build any naming convention and file structure you like.

Path patterns can be assembled out of any number of other path patterns. They will get resolved as much as they can. Finally, all values (predefined & custom) will get resolved into actual values.

This might look a little bit weird at the beginning, but this system gives you full control over how to assemble your naming convention. You will see the benefit of it in a second.

Example: resolution

Our source image is an image of a flame with the resolution of width 1920 and height 1080.

We create a path pattern to define the naming convention of the resolution folder as followed:

resolution_pattern : <width>x<height>
If we now ingest the element, the pattern gets resolved to: 1920x1080

<width> is a tag. Pattern Tags are defined by the < (less than) and > (greater than) characters.
Everything that is not surrounded by <> are manually set characters and will not get resolved.

Now let’s take it a step further.

We can define custom path values in the path values section.
These values get included in the values that can get resolved by the resolver.

Lets create a path value:
colorspace : linear

and update the pattern from before:
resolution_pattern : abc_<width>x<height>_<colorspace>

This gets resolved to: abc_1920x1080_linear

Notice the tag we added at the end? <colorspace> is a custom pattern tag.
The resolver will look at the path value colorspace and use its value linear

In the settings section: library → transcoding templates
you can overwrite the path patterns and path values.

If we create a library transcoding template that creates a thumbnail preview for our elements, we can overwrite the path value <colorspace> by another value. For example: srgb
The path pattern for this transcoding template gets now resolved to: abc_1920x1080_srgb

Example: category

Let's create a path pattern for defining the naming convention for folder of the element.

Create a new path pattern:
element_name : <category.base.name>_<element.number>

In the ingest view we decide that the category of the element is flame
The base (top parent) category of flame is fire. Because a flame is a part of a fire.

This means that <category.name> resolves to flame and <category.base.name> resolves to fire

What about <element.number>?
This is one of the predefined values. These predefined values are values that are only known once an element is ingested because the values are dependent on the elements data.

If we now ingest a new fire element and there are already 230 fire elements in the database, the element number will increase by +1. Thus the <element.number> will resolve to 231.

So finally: <category.base.name>_<element.number> resolves to flame_231.

Why should we use the base category?

We want our library to be sustainable and be as static as possible for many years.
Once we ingest an element it should not move or be renamed.
If we want to open up a project file from years ago all the media files should be found.

That is why you should decided to store the elements in the base category folder

To go up one directory you can use the relative path double dots '..'
/some/path/<source.directory>/../<proxy_folder> -> will resolve to /some/path/the-proxy-folder

Path Values

Path values are used to resolve the values of the path patterns depending on the element that will be ingested or rendered. Some values are known once we actually know the data that we want to ingest, others values can be set by you (custom values). The custom values can be overwritten in the library and the transcoding templates.

Predefined path values

The predefined values are used as placeholders in the path patterns. They are divided into separate predefined groups that will be commonly used. For each group you can access the sub-keys.

Predefined path values are given and can not be changed manually

Reserved keywords

There are a few reserved keywords that will not be resolved. They are for example required by the renderfarm manager Deadline.
<STARTFRAME> <ENDFRAME> <QUOTE> <AUXFILE>

Example
If you want to get the width value of the source element you ingest, you access the group resolution and the sub-key width in the path pattern like this: <resolution.width>. This will resolve the source image width value for you.

Example: element

Path of element that we want to ingest:
/some/path/to/file.%04.exr
It is a sequence of OpenEXR files that contain a picture of a flame.
The first frame of the sequence is 1001 and last frame is 1042.
Each image has a resolution of width 1920, a height of 1080 and a pixel aspect ration of 1.
In the library there are already 22 fire elements.

In the ingest view we decide that the category of the element is flame.
The base (top parent) category of flame is fire. Because a flame is a part of a fire.

In this overview you can see how each of the predefined values would be resolved into the actual value:

The element UUID (Universally unique identifier) is globally unique across all libraries and databases. This allows you to track this one particular element for all “eternity” with this unique ID.

A hexadecimal presentation is used of the UUID that gets rid of the “-” dashes, which is better for using it in the filename.

Learn more about Universally unique identifiers.

Custom path values

These are the values that you can define. These custom path values get resolved in the path patterns.

Custom path values are the values defined by the user

Examples

server : /path/to/server
library_name: my-element

If you use path patterns that reference path values you have to make sure that these values exist in the path values section. If something can not be resolved because values are not defined, the ingest or rendering of proxies will fail and you will see an error message.

Overwrite pattern & values

The server path or the folder where the library data is stored might chance for each library.
Overwriting path pattern and path values is based on the concept that you only need to overwrite values for each library, which reduced the complexity and misalignment of the file structure.

This gives you the control to setup global conditions for all libraries and you only need to change one or two values for each library.

Collection Database

Collections can be saved in a database or a file on disk. In this section database connections can be created. For more information please check out this documentation here