Skip to content

RBTN005: Functionality of the Dynamic Image Overlay Node

The Dynamic Image Overlay node is available starting from Retrobatch Pro version 2.2.

Download a Sample Project to Follow Along

RBTN005_Sample.zip

The Dynamic Image Overlay node operates similarly to the Image Watermark node but with the key distinction that the image used is not static. Instead, the image source is dynamically determined via the Image Key field in its properties inspector.

To illustrate, consider a workflow that generates 20 images from a base template, with each image having a randomly assigned overlay. You may download the sample project above.

Below is an example of the Dynamic Image Overlay node's properties, particularly the Image Key field:

In this example, the Image Key field contains the value $userValue.RandomImage$. This instructs Retrobatch to search the asset's userValue dictionary for the RandomImage key, which provides the image. The RandomImage key is inserted using a JavaScript node preceding the overlay node in the workflow, as shown below:

The corresponding JavaScript code is:

function getRandomInt(max) {
    return Math.ceil(Math.random() * max);
}

function processAsset(document, jsnode, asset) {
    var imgName = "rand/" + getRandomInt(7) + ".png";
    asset.setUserValue_forKey(imgName, "RandomImage");
    return true;
}

This script randomly generates an image path (from 1 to 7) and assigns it to the RandomImage field within the UserValue dictionary. Although the key is named RandomImage here, it could be labeled otherwise depending on user preference.

When the Dynamic Image Overlay node encounters the $$ delimiters, it searches the UserValue dictionary for the corresponding value. In this case, it retrieves a string such as rand/4.png, which refers to one of the images stored in the "rand" folder, matching the random file name generated by the script.

OK, but now how does Retrobatch know where to find the 4.png image?

Search Path for Image Resolution

The Image Key field functions as a URI-like path, guiding Retrobatch through a sequence of steps to locate the image:

  1. If the URI starts with file:, Retrobatch interprets it as a local file URL.
  2. If the URI starts with /, Retrobatch treats it as a local file path.
  3. Retrobatch checks prior nodes in the workflow for image resolution. Nodes may do this differently, depending on their functionality.
    1. In the case of the CSV Reader node, it'll search through the CSV headers for a value and return that. See the Parsing CSV Files documentation for more info.
  4. If none of the above steps yield results, Retrobatch searches for the image relative to the workflow document's location.

In the provided example, the following files are present: 

./out/
./rand/4.png
./rand/5.png
./rand/7.png
./rand/6.png
./rand/2.png
./rand/3.png
./rand/1.png
./RBTN005.retrobatch
./template.acorn

Thus, Retrobatch resolves the image path (e.g., rand/4.png) by locating the image within the same directory as the RBTN005.retrobatch file.

Once executed, the workflow generates 20 images in the out folder, each featuring a random overlay from the "rand" folder.

Got questions or ideas? Email support@flyingmeat.com or visit our online forums.