We often refer to versions as “full frame proxies” and recommend you use them for non-destructive testing of different settings in full-frame tools like Stabilization and Flicker. But what’s really happening under the hood? We’ve put together this handy guide so you can understand what’s being modified when you create or commit versions, particularly if you have multiple sibling versions.
Two general rules to help understand whats going on:
- The parent media is always the source for a given frame in a version until that frame is modified
- Commiting a version overwrites frames rather than merging them
##The Basic Case
In the most basic case, you create a new version, do work in that version and then commit that version back to the parent.
Step 1. Create new version
When you create a new version, it will be identical to the state of the parent clip at the time you create the version.
Step 2. Modify the version
The parent remains in its original state while you work on the version.
Step 3. Commit the version
Once committed, the changes from the version become part of the parent clip.
##Multiple Versions (Serial)
It’s often the case that you’ll do a process on v1, like the results and commit them, then create another new version to use a different tool on. This works just like the previous example. The only difference is that the parent (and starting point for v2) is modified
Step 1. Create new version of previously modified parent
Step 2. Modify version 2
Because you committed v1 before creating v2, any changes you make in v2 will include the changes from v1
Step 3. Commit version 2
Once committed, the parent will reflect the changes made in v1 along with any changes made in v2 on top of v1
##Multiple versions simulateously
Often, you’ll make multiple versions simultaneously to test, say, different passes of Flicker with different parameters. In most cases, this will behave just like the basic case, you’ll make modifications, commit the chosen version and delete the other versions you didn’t like.
But when you have multiple versions and are working on all of them with different tools at different times, things can get a little hairy.
Step 1. Create two versions
Step 2. Modify both versions
Step 3.Commit version 1
Up until now, things have been pretty straightforward in this example. Here’s where it gets weird.
After you commit v1 to the parent, those changes become the parent. And if you have unmodified frames in v2, those will now reference the updated parent clip. In other words, v2 was not a “snapshot” of the parent at the time you created the version, it’s more of a living reference that is always up-to-date
But any frames you’ve already modified in v2 will no longer reference the parent, and therefore never reference the changes made in v1.
So if you were to commit v2 now, you would overwite some of the v1 changes with v2
