The following project/idea I originally produced for the Project Lemonade series for Digital Transitions webinars. The following is a short version of it, if you want to see the full webinar visit and sign up to the DT archive here.

Before we get started…

For part 1, we will concentrate on writing the script as if we are mirroring the same logic of using Capture One UI and UX concepts. I’m fully aware there are several approaches, model shortcuts, logic and advanced syntax to ultimately achieve the same results.

However, this “parity” method I have found is a great way to learn the concepts of scripting Capture One, without blowing your mind on day 1. It also helps underline the moving parts within Capture One. Once we have a good base we can look at the advanced stuff and change up the gears in pt2 and pt3.

The reason for pearoasting this is, it is a good project covering many of the core/fundamentals of Capture One scripting:

Code block

Comments

Variables

Operators

If/else statements

Selections

Commands

If you are new to scripting, check out our other posts on getting started.

Let’s start!

---

Conditional Processing

Why automate processing? Processing/converting images – from RAW to an RGB image format – in batches is fairly well supported in Capture One as a feature. You might ask why you would want to automate it further.

The kind of case where this makes sense is when the requirments change to more than just: “process everything as TIFF”.

What if there are certain recipes that should act on images with certain properties? For example, if the image has red tags, process it to here; if they have a certain meta data, process them only as Jpeg.

This kind of problem occurs in more production type environments where you might need extra dynamism – or one where your users dont have technical accumen to select/deselect the necessary images, switch on/off or change recipes paths and so on.

This kind of scenario is when errors happen, and errors at scale are expensive.

Luckily, this is great example of something we can automate!

File>New…

Open a new script file in your IDE and paste in the first bit of code below. Use ⌘+K to compile.

This is what we refer to as a tell block. In AppleScript code blocks start with tell and close with end tell.

When addressing the application, we always start with “tell “. This directs the script to the application “object”: the first object in the “application model”. All the code between this tell/end tell is directed at the application in question.

AppleScript is an “object orientated” language. Understanding the model of how the objects are arranged and inherited is key to making scripts for Capture One.

A good analogy for this is to think of it much like a russian doll. The biggest object is the Application. This contains the next biggest object, the document (session or catalog), which contains the collections (favourites, albums, folders) and these contain variants/images. This is called “object inheritance”.

As the scripter, we have to make sure our commands are directed to the right objects, and this requires navigating the “levels” of the model in the code.

As per previous article ScriptDebugger is recommeneded for many reasons but one of the stand out reasons for me is the object model view in the dictionary. This is great for inspecting objects and viewing the model of any AppleScript capable model.

Next, within the tell application block, we now need to talk to the next object in the model – the document.

Much like as if you opened a session to see some work, we want our script to work on the document in front of the user.

As we are only interested in the document we are working on we can use a special object “current document” – this refers to the application’s top most open and active session or catalog. Again we use tell to direct the script to the document object.

The point of this script is to only process what we are seeing in the document, much like as if we were to do it manually. In order to this next bit, we need to understand about targeting the right “variants” for processing, then committing those to the batch queue.

Our script so far is talking to the document level, but when the user interfaces with images in the UI, you are always in some sort of “collection”. This can be a folder, album, favourite or any other “container” concept of Capture One that holds images.

As with current document, there is another super useful object to the collection currenly selected in the UI and thus being viewed by the user – current collection.

Again, we nest within a tell block.

This makes sure that the script is only targeting the variants for processing that are A: in the document we have active, and B: in the collection we have selected within that document. Again, this is mirroring somewhat the intended user experience of Capture One’s app design.

The next part is really a design choice – you could decide you want the script to work on every image in the collection regardless of selection, or just on a number of images selected by the user. So we don’t break character with our user experience/parity mission, let’s work on the user selection.

Note
“variants whose selected is true” is a newer syntax from v11 onward, and replaces “selected variants”
This syntax returns a list of variant objects.

The repeat (control statement) is designed to loop through the code nested within it, x number of times (which in this case is equal to the number of variants we have selected in the UI). theVariant thus becomes the next variant in the list in each loop.

We use it here as we want to check every variant given to the script. What to check it for, is defined in the code between repeat and end repeat. As theVariant becomes a variant object we can now use a tell block to talk to it as if we we talking to a variant directly.

We are now at the fun part, where we decide the design what we want to do with each variant our script encounters.

Let’s use an IF statement to decide a condition. IF statements only execute the code in the block if the IF equates to true. You can extend IF statements with additional conditions using ELSE IF, which if the first IF equates to FALSE, will run next. You can also use an ELSE statement; if all of the above is FALSE, do this.

What to check is TRUE is a good question. A simple example is color tag. Ben Liddle looked at color tag peculiarities in his post here, but the short of it is, Capture One uses the numbers 1-7 to represent the colours Red-Purple. In doubt, think of how a Rainbow looks, and count in from Red.

Note also the — following the first IF. This is an (inline) code comment.
This allows the scripter to write anything after the line as a comment as to what you were doing or other useful notes that might help decipher what was going on when you come back to it later. Inline comments must be made after the code, not in the middle. You can also start a new line with — and this will also compile as a commented line. Commenting is also useful for removing redundant code, or excluding troublesome stuff when debugging.

We thus check (in the first If statement) if the color tag is 1 (RED). if it is, then line after will execute. If it isn’t, the code skips to the next ELSE IF and checks if the color tag is 4 (GREEN). If it is, the line after will execute; if not, we go to the final ELSE (the garbage collector) which will set the color tag to yellow – indicating unprocessed.

But what of our images that were GREEN or RED?

The process command is added last. Process has two parameters: a list of variants to be processed, and the name of the recipe to use. For RED images, I want the script to process using the recipe “JPEG”, for Green, I want to use the recipe called “TIFF”. For variants that are neither, I will mark those Yellow, just to let me know these weren’t processed.

Note

You need to have your recipes defined in Capture One interface and named accordingly. This script is only “pulling on the handles” and assumes the recipes exist. We should make our scripting more robust and check the recipes exist before running – hell maybe even remake them if they don’t, but this is for another day.

This script is now fully functional, and can be installed and executed from Capture One’s script menu as per this article.

An intro series to scripting Capture One, with Ben Liddle

Splitting hairs: Variants v. Images

The thumbnails in Capture One’s browser pane are technically variants. A variant is a unique set of rendering instructions for a given source raw (or TIF, JPG, etc) image file. These instructions are lightweight (few hundred Kb at most), so you can think of these as virtual copies of your image files. Every image file you view in Capture One has at least one variant; unless you objectively create a new variant, there’ll be a 1:1 ratio of variants and images in your browser.

Setting up the Handler

Below is the code to set up the AS hander. Create a new script file and save this to the top of the file. Handlers are basically bits of code that you can call from anywhere else in the code (once you have already defined it, thus putting this at the top). They start with the on keyword, and are called with my (when they’re located in the same .scpt file as the code that’s calling it, but you can ignore this for now).

Let’s break it down:

Here, I’m declaring that we’re creating a handler arbitrarily called select_vars. The bit in parentheses is a parameter that I’m declaring. Basically, when we call this handler later on, we’ll be passing a variable as well. The ‘as string’ tells the script that whatever I pass to select_vars later on, it must be a string; eg if later on I pass it an integer or list, we’ll get an error.

The color tags in Capture One are scripted to numeric values between 1 and 7. Here, I’m building a list of readable color tag names in their order: a red tag is actually a 1, a green is actually a 4, etc.

Repeat with a variable i, from 1 to the length of (ie count) of the color tag list. On each loop through (iteration), i is the index (position) of the item in the list.

Here we’re checking if the item in position i is the same as the text variable I’m setting. If so, create a new variable called color_tag_number and set its value to the current iteration’s value of i.

Collect all variant objects of the current collection whose property color tag’s value is equal to the value of color_tag_number . Create a new variable, sel_vars, to store references to them. Since we used the plural of variant, our variable sel_vars is a list.

The current document is being told to select the variant objects referenced in sel_vars. This is actually an additive select- if we had four other variants selected, we’d have the count of green-tagged images plus those four selected. This can be prevented by throwing in a deselect command before the new select command:

With this handler set up, we can call it wherever we want in the script without repeating the code block:

Et voila. Variants selected.

Ben Liddle is a data manager in Colorado who automates the shit out of the first half of the work/life balance so the second half can be more fun.