Breakdown of Scripted Productions

Although the most obvious way to break down a screenplay or teleplay is by scene, this might not be recommended (as far as digital asset management is concerned) early on in the production process. It’s common for scripts to change right up until principal photography (or even past that point in some cases), with scenes added, removed, or re-ordered in the process. Although there are conventions to minimise the resulting complexities of such changes, for example, adding new scenes with a prefix to prevent having to renumber others (so that a new “A22” scene would be inserted between scenes “21” and “22”), in practice this isn’t always the case, particularly if the rewrites are significant.

What this means is that assets might be simply attributed to “scene 30” early on, but after a rewrite, the new scene 30 is actually a different scene. Depending on the system used for tracking digital assets, they might simply be listed under “scene 30” (or perhaps in a folder on a disk called “30”) and now have no direct connection to the correct scene number. For these reasons, it can be beneficial to break down story elements into more encompassing “sequences” instead. A sequence can be thought of as a group of scenes that tells a specific part of the story, even if the shooting location may change a number of times within it. A good example is a “chase sequence” in an action movie, which might span a number of scenes and locations. In this way, people would know to look for information about a particular vehicle or prop, for example, within this sequence, rather than having to know which particular scene it was associated with at the time.

Categorisation

One of the most important things that should be done with any digital asset is to assign it to a category in some way. A digital photograph might be captured by set decoration, for example, and sent over with a filename to at least indicate the sequence it belongs to (or, as is often the case, some generic name such as “DSC_0423.JPG”), but for the sake of posterity one of the most helpful things that can be done is to identify a broad range of categories that the image could fall into (for example, does it relate to a specific prop or to the overall set?) and store it accordingly. Perhaps the simplest and most intuitive way to do this is through a series of folders, so that, for example, all images for props go into one folder and images for vehicles into another.

Subcategorisation should also be considered (for example, in the form of folders within folders), so that, for example, “props” might further be classified as “weapons”, “furnishings”, and so on. However, the danger here is in having too much dependence on categorising things such that there might be debate as to how a particular thing should be categorised. Should a kitchen knife be considered a “weapon” or a “utensil”, for example? A good rule of thumb is that if there’s any doubt as to what something should be when trying to categorise it, it will likely be much harder to find in a given category later on.

Figure 11.1 Categories and Subcategories

Box 11.1 Leading with Zeroes

How assets are named is extremely important to being able to identify what they are in a digital environment. It can take a lot longer to browse pages and pages of digital documents to find something specific compared to leafing through pages of printed reports, unless you have the ability to search for specific keywords, or otherwise know where to find something, in which case searching digitally becomes much faster than doing it physically. For more abstract files, such as digital images, there’s no good interface to identify what it is other than to view it, unless it is named in such a way that the filename (or the context of the enclosing folders) provides identification as to the content.

For this reason, it can be important to establish “naming conventions” that should be used for specific types of files. For digital concept art, for example, it can be useful to include what the subject of the image is in the filename (such as “wine glass close up 1.jpg”), whereas for movie files for camera footage it might be useful to include the slate and take number (such as “101A-3B.mov”). Whatever conventions are devised, it can be important to agree on a system where numbers are “padded” with leading zeroes as appropriate.

What this means is, if something should have a number, such as for something that needs to be identified as belonging to a particular scene, instead of just numbering it as you’d write it down (such as “scene 4”), you make sure that there’s always a specific number of digits (typically based on whatever the maximum number would be). So for a shoot with 120 scenes, for example, you’d want to make sure that all scenes have three digits, and that any with fewer have leading zeroes (so, for example, instead of “4”, “72”, and “102”, you’d have “004”, “072”, and “124”).

Why this can be important is so that when they are displayed in a sorted list, they appear in a way that makes sense. Consider the following list of scene numbers, as they would be sorted in most computer systems:

• ▸ 1
• ▸ 10
• ▸ 100
• ▸ 2
• ▸ 21

With three-digit padding, the list would sort in a more natural way:

• ▸ 001
• ▸ 002
• ▸ 010
• ▸ 021
• ▸ 100

Tagging

One of the problems with categorising items in this way is that there are occasions where it would be useful to associate something with multiple categories. For example, a single file might fit the categories of “set decoration”, “photo”, “reference”, “tunnel sequence”, “pipe”, “weapon”, and so on. Trying to convey all that information through a structure of categories and subcategories can become cluttered and ultimately defeat the purpose of doing so in the first place. In these situations, using “tags” can be a better fit.

Tags (or “keywords”) are free-form words or short phrases to attribute something to an asset. The most important aspect to using tags is that any item can have multiple tags, and they do not need to conform to a particular order—all tags are considered equal. The strength of tags is when you need to find something later on, you can search for items “tagged with” a particular tag, for example, “weapon” and see everything with that tag, regardless of where it originates. It’s also possible to search for things that match a set of tags, such as “yellow” and “clock”.

With such a powerful approach come drawbacks, however. As tags are free-form, there’s no easy way to enforce convention. You can’t, for example, ensure that all photos are tagged as such (except where tagging is combined with some form of automation, that identifies key properties about something and adds tags automatically), meaning that whoever is responsible for adding tags to items remembers to do so, which is not as easy as, say, choosing which one of five folders to put a file into. Furthermore, it can be a very manual and time-consuming process to add the requisite tags in the first place, particularly if there’s not someone dedicated to the task in the process. Finally, tags may be lost when moving data between systems. For example, tags on files created on the Windows operating system are lost when copying them to a Mac system (and vice versa), or if uploaded to Cloud Storage. That said, when tagging is first done within a primary Cloud storage system, or within a Cloud-based tracking system, the benefits persist for the duration the system is used, which is often long enough.

Figure 11.2 Categorisation through Tagging

Box 11.2 Everything Is an Asset

As more aspects of the production process become rooted in the digital world somehow, more things can be thought of as digital assets (and thus, there become more things to track). It’s easy to consider reference material that exists in a digital form as an asset, but what about reports saved as PDF files? Camera tests exist as digital media somewhere, as might things like table reads or hair and make-up tests. Many of these might have little long-term values, but then as discussed in chapter 13, if there’s capacity to store something in the Cloud, it might be better to do so than not.

As the capacity to store assets increases, so does the importance of organising them in an effective way to ensure that people are able to find things as easily and quickly as possible. This can mean having strong organisational policies in place, such as by making use of clear categorisation, but it may also mean taking steps to ensure irrelevant assets don’t clutter lists of results. One such approach is to “archive” older materials by moving them out of the main production workspace, or it may mean curating search systems to filter out certain items as time goes by (whilst still providing some means to find such items if they are really needed).

Version Control

One of the trickier problems of asset management is version control: the process of managing different versions of a particular item. This is perhaps most obviously applicable to the work that art departments do, which can undergo many iterations and changes on a single piece of concept art or costume. However, it extends to almost every facet of a production. A single “take”, for instance, could be considered a version of a shot, and similarly the “final cut” of a production will likely represent only one of many, many versions of the work done by the editorial team.

Perhaps the most crucial thing to appreciate about version control on any creative endeavour is that all the interim versions are important to keep in the process of getting to the final ones. It can be helpful to compare changes between different versions of the same thing, and there might be occasions where a version that was previously thought to be inadequate proves to be more desirable than chronologically newer ones as time goes by and surrounding context changes.

The Cloud loves to automatically version things. Cloud storage services such as Box (box.com), for example, will automatically track as files are changed, storing a history of each version of a file that was changed (along with the ability to view those at specific points in time). Some systems such as Google Docs (docs.google.com) even track changes made to a document as they happen, generating multiple versions, and allowing every revision to be viewed or reinstated at any time (in many systems, even the act of restoring a version itself constitutes making a new version, so you can restore older versions without fear of permanently losing any recent work). Many of the systems for review and approval (as discussed in chapter 12) allow for sophisticated comparison of different versions, such as viewing multiple versions side by side or allowing for switching between them in context.

Integrated Systems

The ultimate asset management system is the one that’s fully integrated with every other aspect of the production. Such a system would allow artists to submit each version of their work and have it tracked, reviewed, and approved throughout the production’s duration. Others would be able to easily find their work and be confident that they’re looking at the correct version. They could find any related materials as needed and build on it, completing the production with access to what they need and clear lines of communication. Even after the production wraps, assets can be easily located, gathered, and archived.

Although these seem like lofty ideals, many systems exist that are helping to make this a reality. SyncOnSet (synconset.com), for example, provides asset management functionality for the duration of a shoot, with breakdowns, inventory tracking, and reporting all integrated. 5th Kind (5thkind.com) extends this by allowing digital assets to be stored and tracked in the Cloud and then subsequently reviewed and approved in the same system.