Output events
This week (though it’s taken nearly a year on and off) I finalised another Capture One app – CheckOut – based on the Output events feature. You can find the app in the store here.
Scripting Output events
Output events are script objects that record a variants processing history. Basically every time you process a file in C1, the app logs some data about what was done automatically. You can then query the the variant for this data. Without these, the script designer would have to create “watch folder” monitor scripts, or use Capture One’s event script framework while the user is working – you can instead just ask any varaint at any time “what has been processed from you, and where did it go?” and get the answer.
Available Output event values
Every time you process you create an Output event, so a variant can contain many. A single output event object contains:
Example
This simple example demonstrates how to log all the (unix formatted) destination paths of files processed (to date) from the primary variant
|
1 2 3 4 5 6 7 8 9 |
tell application "Capture One 23.16.2.2.10" tell primary variant set theOutEv to output events -- creates a list of output event objects repeat with anEvent in theOutEv set thePath to path of anEvent -- pull out the path propery from the output event log thePath end repeat end tell end tell |
The CheckOut app
The initial idea for CheckOut came from some digi friends and was a simple concept – run an app the end of the day and it will tell you if you processed everything that was Captured into the session – and a perfect use case for Output events.
While it sounded simple on the surface, at scale the details exploded pretty quickly.
For a few files it was fine, but presenting a summary for a full day of maybe 2-3000 shots over 30 favorites was something else entirely: I thought Excel for Mac would make a decent candidate to dump data into and make reports – primarily as this is also scriptable* so bridging the two apps should be relatively straightforward**.
Then there were questions like; What if the file was processed more than once? or with different recipes? what if the files are not on disk any more? How to display all this in a meaningfull way? How to track everything that is processed?
Implementation
The resulting app is 100% applescript, bridging C1 and Excel. On run, the app will:
Check the current session for the output events of every variant that exists in session favourites.
Fetch and discombobulate all the data to a new Excel doc in 2 review sections.
A summary view for counts, in and out
A detail view for a file by file breakdown/errors by event
The app deals with theoritcially 2 workflows:
To make a clean, readable solution for both was tricky as the scenario of multiple output events created complex data structures. To try and solve this there are two views. A basic summary and a detail view.
The basic summary view checks counts of all the basics for the session. Favourites, files, basic output counts. Basically all the files in and files out.
The detail view is a view of each RAW file, its spawned child files and if the file is still on disk where it was sent to. If your workflow requires procesisng more than once, this area will contain more detailed information on job success/fail.
Basic summary view
Basic summary panel is color coded when assuming the 1:1 relationship.
The Output summary on the right is running counts of how many Jpegs and how many Tiffs the session has output, and its parent folder path.
If everything has been processed perfectly, all cells should be green, counts will all match.
Detail view
The extended view summary does a blow by blow list for each and every file by favourite folder. It tells you which files are problems and why, how many times it was processed, if it is still on disk etc. Its much more useful for finding problems in complex jobs.
WHy this? Well there is no recipe “fingerprint” in the scripting interface to know what came from what recipe so impossible to know the intention. For example, processing with 2 separate recipes which are both jpeg, can only be interepreted as “2 jpegs, processed twice”. In this case, the basic view is marked yellow and “multiple” in the output area. This less than ideal problem is why the detail view exists – you can see the folder has questionable events, then check the advanced and see if everything is green.
The detail view is also color coded.
Limitations
There is a fundemental limitation of Output events, in that the events log the path of output when a variant is processed, so successful reconciliation requires the output file needs to still be on disk in the location it was processed in for it to pass inspection. Basically if the output file cant be found in the folder to which it was initially processed, the outut will be logged as missing or deleted.
* a model designed by the devil himself
** not at all
*** the “exists” enum is broken and doesnt work. Instead you have to try to log the file alias for an event (true) which will (a feature of alias’) error if it doesn exist (false).