The Politics of The Green Screen Shoot

"Green Screen" by Peter Pearson
licensed CC BY-SA 2.0

Often vfx professionals are confronted by other film or video professionals who see the world from their perspective without understanding our world, or who have notions about quality that will cause trouble down the line.

Case in point, I read a LinkedIn post today from an editor-animator-camera operator who has a DP wanting to over-crank a camera to get a better chroma key.  More specifics: there is synchronized audio, proposed shoot speed is 59.97, mastering speed is 23.976.  DP believes he will get a crisper, cleaner key.

First, let's tackle the technical question and help this editor with the right information, then we will talk about how to handle the politics of the situation where your voice may not be the loudest in the room.

Over-Cranking the Camera and Conforming Footage

To answer this question, let's consider the over-cranking speed adjustment required for mastering first and then discuss the keying.  Again the specs- synchronized audio, 50fps conformed to 24 fps Drop Frame.  In this situation over-cranking may not help and will most likely will introduce motion discontinuities, also known as a glitch or bump or jump in motion.  

The questioner says the DP wants to "conform" the footage to 23.976.  Conforming footage in editing or compositing parlance means to LIE to the software.  If the footage is shot at 59.97, the native or true speed is 59.97, for simplicity we will say 60 frames per second.  Conforming means to tell the software after importing the clip that the speed is not 60 fps, it is say, 24 fps.  This means that it will play 60 frames of clip in 60 frames at a speed of 24fps.  If it were not conformed, it would play 60 frames of clip in 24 frames of master at a speed of 24fps.  In this case, conforming one second of source footage results in 2.5 seconds of master footage.  This will then cause the footage video to be out of sync (behind) the footage audio.  Usually a problem.  So therefore the footage cannot be conformed, it must be retimed.  

Retiming Footage Methods and Their Artifacts

In doing so there are three ways - dropping frames, blending frames and blending pixels.  In this case every 2.5 frames needs to be merged to produce one frame.  If dropping frames, it means 5 frames become 2, so a jump or glitch will occur every 3 frames.  Depending on motion, this will usually be noticeable.  If frames are blended, it means 2.5 frames will be dissolved together to make a new frame, which means details will be repeated and ghostly artifacts will most likely appear, especially around edges of high contrast.   If pixels are blended, it means a new frame will be attempted based on contextual motion of the pixels.  This can result in swimming pixels.  Because  the footage is being sped up, this is less likely than if it were being slowed, but it still may happen where details are at a high frequency, like in hair or fabrics or other textures.  Anytime footage is retimed there is an opportunity for artifacts to creep in.  The vfx artist or editor may have some control over quality, but in the end, the footage and software will rule the result, not the artist, editor or DP.

Now the question is, will the footage look better if over-cranked.  It depends on your primary delivery market.   If your market is broadcast TV, then shooting 60fps may be desirable if you also master at 60fps, because then you can have smoother, cleaner field rate motion.  But today in HD many shows want to see frame motion and like the 24fps look as more filmic.  As the given specs are a 24 fps (DF) delivery, then that advantage is lost.  If the drop frame method of retiming is used, then absolutely nothing is gained.  The extra frames are just wasted money.  If the blending method is used, the result will not really be sharper.  Instead, contrast edges (true edges and internal edges) will have artifacts that become more notceable as movement is faster.  If the pixel-blending method is used, the resulting edge details are getting softened.

You can test this with any footage.  Pick something with some motion and conform it to 60fps.  Now drop it into a 24fps timeline or sequence, and retime it with each method to a speed of 250%.  The various artifacts will appear. Depending on your footage, it may or may not be acceptable.  But in real production, remember you don't get to reshoot if it is not acceptable, and so the point of this discussion is to provide all the information for an informed discussion.

How will Retiming OverCranked Footage Benefit a Key?

If the pixel blending method can be used without artifacts, the retiming will effectively denoise the edge where the backing color (green screen) meets the subject.  In fact, if drop frame retiming produces minimal glitchy motion, one could simply denoise at 60fps and then drop frames for a slightly better result.  But remember, the key edges are being blended in both methods, which is essentially blurred in the time dimension.  Edges may be less noisy, but the picture itself will not be crisper.

Better Keying Results With Oversized Images.

A better result will be achieved by shooting at a higher resolution.  If instead one shot at 23.976 with 4k or 5k acquisition resolution, and then pulled key, composited and then scaled master to delivery size of 2k or HD, then the resulting key will always look better and there will be zero risk of artifacts.  To keep it simple, suppose we shoot 4k and deliver 2k.  That 2:1 size ratio is a 4:1 detail ratio.  That means our key edges are four times more data and detail.  Fine hairs are now four times the area.  This means that more pixels are used in pulling the key, which gives you a crisper AND a smoother edge at the same time.  If you scale before compositing, the result will be good, but if you scale after compositing, the result will look better because the post-scale is now blending AREA from four times detail to normal detail.  The natural noise in the keyed edge, the natural rounded corners where the key edges are not sharp are 1/4 the size, so the result looks sharper.  The soft edges have 4/1 the pixels, so the blending is smoother.

Cost Implications and Other Options

Both Over-Cranking and Over-Scaling the footage when shot will increase costs.  With over-cranking, your storage and transfer times will increase 2.5x at every transfer point.  To properly watch for artifacts, your system must be able to play full-resolution, uncompressed video real time without skipping any frames.  While you can frame by frame for spatial artifacts, motion glitches often are hidden when stepping through frames due to perceptual issues.  

With Over-Scaling, the larger frames will use more stock or disk space and will consume more handling time and storage at every transfer step.  Even with compression, the rule of thumb is that 2x the size = 4x the detail = 4x the storage space = 4x the time to transfer.  It means a more expensive graphics system is needed to view images in real time, and if not real time, it is 4x the labor to view and check frames.  It will also increase compositing costs in both real labor and rendering cpu time.  

If the cost or schedule implications are an issue, another very simple option would be to reduce the in-camera noise.  Assuming a digital shoot, this should be adjustable in camera settings (outside my scope here).  If film, select negative film with less grain.  

Then of course the more even and better the backing color, the less stress you will need to put on the edges.  So while an acceptable key may be achievable, if the DP is really concerned about a good key, he needs to give you a good plate.  Review the methods of green or blue screen compositing, watch for sharp creases or shading changes in the backing color, and ask for clean plates.  After all, the keying software is just performing mathematical data processing on the acquired footage data.  The rule in data processing is always, garbage in, garbage out.  Fix it in post may be an option if the shoot costs need to be contained or time runs out, but that has its own cost, and should be defended.  

The Politics

Ultimately, how footage is shot is going to be a decision worked out by the Director and Producer, balancing aesthetics and costs.  The DP will have a great deal of influence in this speaking to aesthetics, because there are many considerations beyond just the key.  We touched on temporaral image quality.  The VFX Supervisor, Editor or Compositor needs to be the advocate for the post process.  Your job is to clear away any myths or illusions the others may have about the process and help them understand the potential aesthetic problems and cost implications of the technical method selected.  If the decision effects your budget or schedule, you need to speak up.  

It's not something to go to war over.  So if the DP insists, you just need to make sure your concerns are acknowledged (documented!) and your budget and schedule requirements are specific for the methodology.  Then let the higher-ups make the decision.  But if they leave the decision to you, then you need to weigh their aesthetic goals against the  risks and costs.

At the end of the day, good keys are not really about tricky shoots.  They'e about tried-and true best practices. They're about the skill, knowledge and careful work of the DP, crew and compositor.  Tricky shoots cannot make up for inept work. Great work can only do so much with bad data. 

May all your shots be treasures and all your frames gems.  Best success.

#0051 Ten Essential Rules of File Naming -. Summarized

Previous:      Asset Management 101 –  Ten Essential Rules of File Naming - 10 Include Extra Data

Asset Management 101  

Ten Rules To File By

So about now you're wondering if you want to modify your naming conventions or not.  Doing so can be a big undertaking, involving sometimes getting the consensus of other supervisors and producers.  It should certainly be initiated only for new projects, and you'll need to prepare a good document explaining what the changes are, why they are important and possibly how the system will be implemented.

When implementing the system, you'll need to consider how you will train your staff.  A memo is fine, but better is a briefing paper or possibly a slide show illustrating how the new system works.  You may find it necessary to explain to the staff why the changes are important and how it will make things more secure and improve everyone's understanding of file status and relationsips and revision level.   You need to explain the new system because people tend to resist and question change; explaining it to people is a show of respect.


Mostly, you'll need to get your intermediate supervisors and coordinators fully committed to the changes and get them to understand it is part of their job description to knoow and enforce naming conventions.


A final thing to consider is automation.  For one company, I made a spreadsheet in Open Office.  Artists in each work unit can fill in the information for their shot and get back a properly formatted name for their scripts and renders.  Similar utilities can be developed in MEL, Python or Javascript for users.  In NUKE a gizmo could be put together.  Remember, artists are busy and will ignore or make mistakes in file naming just because they are rushing or tired.  Make it easy for them.  


Here's an outline of this series

10 Rules To File By

1.Let it Speak (Make it meaningful)

2.Make it Short

3.Keep it Simple

4.Avoid Special Characters and Control Punctuation

Use command-line compatible punctuation

Avoid Spaces

Two periods maximum

The hypen – if you dare

Use postScript Notation

Special Emphasis

5.Protect Sort Order

Maintain Chronology

Variations and Passes after take or version

6.Rendered Files Must Refer to Their Script

7.There can be only ONE revision 1

Call Composited Shots "takes"

Put Modifiers After Revision Number

Tie Render Passes To A Revision

Use Takes and Versions Together

Make sure your revision modifier policy is understood

Use Codes and Punctuation Sparingly

8.Abbreviate Consistently

Abbreviations

Codes

Consistency

Legibility

9.Use Project Identifiers

Separate internal or external work

Client company and sometimes division or department

Project: film, show, series, campaign,

Sub-project: TV episode, spot or reel number.

10.Include extra data

Artist Names

Variation vs Option Descriptions

Rights Managed Files

Camera Angle

#0050 Ten Essential Rules of File Naming 10-. Include Extra Data

Previous:      Asset Management 101 –  Ten Essential Rules of File Naming - 8 Abbreviate Consistently

Asset Management 101

Include Extra Data

In the post, #0043 AM101: Part 2 - Understanding File Classification , I list more than 15 ways to classify files. In your naming system, incorporating this meta-data into a file name can often be useful, avoiding the need for secondary data files with data about the data. Let's look again at some of the extra data you might include:

Artist Names

This should go without saying, but sometimes it is important or helpful to embed the artist names or initials in a filename. Case in point: I currently am supervising in a mixed-OS environment, with Linux, Mac and Windows machines. The server is Linux, and my Windows machine doesn't convert for me the user and group ID numbers into names. For most files, we don't care enough to make this an issue. But for some files, with shared authoring, it is easier if we know who authored the most recent revision. Likewise, artists may be working in a common folder generating multiple assets.  In both these examples, knowing who made the file can save time.

Variation vs Option Descriptions

Often we are producing more than one option. For all files, this also belongs after the revision control number, unless the options and variants represent unique elements that can or should be used.
To clarify, suppose we are making a single element in Photoshop of a gaseous cloud for compositing. We've designed three Layer Comps and named them, “red”, “blue” and “mixed”. If only one of these should be used we would name these:
example 1

shot12_gasCloud_v01_red.jpg

shot12_gasCloud_v01_blue.jpg

shot12_gasCloud_v01_mixed.jpg

But suppose we are asked to provide three unique gas cloud variations for a shot. These might be named:
example 2

shot12_gasCloud1_red._v01jpg

shot12_gasCloud2_blue_v01.jpg

shot12_gasCloud3_mixed_v01.jpg

This implies, of course, a requirement for explicit and clear instructions to the artist. However, giving explicit instructions will strengthen your command and control system. When in doubt, the artist should ask if they are presenting options or variations.

Other File Classification Data

Rights Managed Files – One company I worked for found it important, when collecting stock files, to include rights usage information in the filename. They developed some simple abbreviations to indicate Royalty Free and Rights Managed assets. When collecting or accepting assets from the client for reference or use, it might be useful to encode the file with information to indicate whether the file is only for reference, client use in a particular project, or general use for all client projects.

Camera Data – Sometimes it might be useful to file footage with information about the camera angle (wide, close-up) or a camera number. Suppose you have stereo footage, then you need a consistent way to name your left and right view footage and asset files. Likewise, suppose you're assembling work from a multi-camera shoot, you may want to identify which camera was used in the source footage filename.



Use your imagination, and remember, that the most important aspect of asset filenaming is to facilitate control, yet accommodate unpredictable needs. Allow in your convention for modifiers and additional data, don't try to predetermine every possible situation, and update your specifications and review them with your staff often.
Just remember to protect your sort order, Usually the most important aspect of sort order will be the asset name and the next most important will be the revision control system numbering. After that come your modifiers and other data.

Next:             
Asset Management 101 – part 9: Ten Essential Rules of File Naming-Summarized

#0049 Ten Essential Rules of File Naming 9-. Use Project Identifiers

Previous:      Asset Management 101 – part 5: Essential Rules of File Naming 8- Abbreviate Consistently

Asset Management 101 – part 7 
Use Project Identifiers 

Often in production asset files are named in a way that if you took shot 11 from three different projects and put them all in the same folder, you would overwrite two and end up with only one asset. That is to say, the shot name contains no project information, and thus is not unique within your file-system. This practice is a bit sloppy, and forces you to rename files when pulling copies for your internal demos. However, while I don't recommend it, studios can get away with non-unique asset names because they are usually kept within a project tree. (We will discuss project trees in a future article.)

Let's talk about best practices again: your best practice is to consistently include some project identification in your file names. Going back to my post, In the post, #0043 AM101: Part 2 - Understanding File Classification , there are four levels of client and project data that could be part of a file name:

1. internal or external work

2. client company and sometimes division or department

3. project: film, show, series, campaign,

4. Sub-project: TV episode, spot or reel number.

Use of all four in every file name could be cumbersome and lead to some very long file names. I recommend that shots contain some project information. I reduce the list by combining level one with level two. How I do this is simple: internal work is filed under the studio name, and external work is files under the client name, and both are at the same level. For example, within my jobs or projects folder, my company name Alsup Digital FX contains demo and non-client tests. Client folders contain each client's files, tests and billed work. (Reason: tests are often rights managed also.) Shot files in Alsup Digital could start with the string “AD”. Client Walter Thomas Studios becomes WTS.

I worked for one company that was very particular about the importance of separating client work by name. Their clientele included several major production studios, with highly sensitive work covered by very tough non-disclosure agreements. Files for each client were carefully secured and access limited to assigned artists. All files had to start with the abbreviation of the client studio name to help prevent accidental exposure of one client's work to another.

I further reduce the list by combining level three with level four by abbreviating the project and appending a sub-project number. For most clients I would use a two or three letter abbreviation. For example,in the previous post, our imaginary client TV series,  Movie Effects Magic. is abbreviated as MEM or mem followed by the episode name.  Incidentally,  when I give a choice between upper and lower case, please make the choice for your artists, don't leave it to each member of your staff to decide how they like it.

While many companies do tie projects to file names, others do not embed the client name or abbreviated client name in every file. This is a choice, which again you need to ask your staff to follow studio policy consistently.

If you choose not to include a client or project identifiers in each file name, just remember you and your artists have to be careful to avoid combining files from multiple clients and multiple projects in the same folder. This is seldom a concern, but there are situations where it could be effect your work flow. Let's consider two cases:

The first  case is you are asked to pull together samples of work from the last year's project. You go and select the best shots from seven shows and copy them to your sample collection folder. However, some of them have the same name. You are forced to come up with a system on the spot. Another artist, given the same task, comes up with their system. The editor, who has done this in the past, has files named and organized a third way. Confusion.

The second case is your company uses an approval pipeline that involves delivering files into folders to be processed. When each artist completes a take, they send a copy to their supervisor's review folder. He then either approves it, moving it to his supervisor's folder, or rejects it moving it to the folder, GiveNotes/. The coordinator looks in the VFX supervisor's folder and tells him there are 20 shots to review (from multiple projects) and the VFX Supervisor either forwards it to the coordinator for delivery to the editor or sends it back to the under-supervisor, logging notes in a spreadsheet. Approved files are moved to an approved takes folder. Because these moves are all on one file system, the overhead is essentially zero, but the collection of files into folders and movement to advance or revise them provides a convenient approval control system for this company. The caveat is that a project identifier is needed for each shot.

Client identifiers and project identifiers are not essential. Of the two, a project identifier can be used alone. It implies a specific client and your artists are more likely, and I should say more than likely, to occasionally mix assets from one client project with another project for the same client.

Next:             
Asset Management 101 – part 7: Ten Essential Rules of File Naming 10 - Include Extra Data

#0048 Ten Essential Rules of File Naming 8-. Abbreviate Consistently

Previous:      Asset Management 101 – part 5: Essential Rules of File Naming 7- There Can Be Only One

Asset Management 101 – part 6

This rule could possibly be split into “Use Abbreviations” and “Be Consistent”, but then I'd need an 11^th point, and that just would cause all kinds of psychotropic disruptions in the universe and list makers everywhere might shudder in disgust. The point is, when naming things, be consistent, use abbreviations, and use abbreviations consistently. Let's lump into this post the idea of using codes and talk about legibility.

Abbreviations

For example, suppose you're working for a client named Walter Thomas Studios. You can abbreviate most names to between two and four letters, so you've decided clients get three letters: WTS or wts.

Next, WTS has awarded you a short film, The Red Eyed Animator, and a series, Movie Effects Magic. So again, three characters or four characters work with most films, so you use three characters (and save the fourth for sequels), giving you either “rea” or “REA”.

For the series you know you will certainly have double-digit episodes and it could go to triple, so you name your Movie Effects Magic episodes MEM001 and so forth. For series common assets, you use the episode number 000, so you don't need an ad-hoc name like “Season Assets”, which, while perfectly acceptable, breaks sort order.

When naming episodes, remember, clients will have their own show numbers, You may want to use these or part of these. For example, suppose WTS uses the numbers 09000-09999 for its MEM series, you can use 000-999 because your system replaces the initial “09” with “MEM”, thus: wtsMEM001.

Other abbreviations you might use:
example 1

v version

r revision

t take

rl reel

sc scene

sh shot

c camera

Codes

You may have noticed that the other abbreviations list contains abbreviated field names, with the data following the abbreviation. Oftentimes you may wish to code other data with shots.
One system I developed employed the use of status codes on all our quicktime takes, so that in addition to knowing what take it was, we knew the level of refinement. Here are some status codes that could modify (and hence follow) your take name:
example 2

ANM 2D Animatic with audio

BLK Playblast Maya Blocking

RUF Rough Composition

STD Submitted To Director

STE Submitted To Editor

TCB Take Accepted, Could Be Better

TCF Take Considered Final

Of course, use of these codes requires the ability of the supervisor to review the shot and rename the file with the correct code. Use your imagination and perhaps you can come up with a set of codes that sort properly and reflect the revision loop you use.

Consistency

If you always use the first three characters of a file name for the client ID and next four for the project ID, you can dispense with punctuation, yet still have scripts process and separate files based on clients and projects. Consistency in how names are assembled can actually allow you to remove punctuation or field identifiers (such as “v”). For example, elimination of nonessential punctuation and field abbreviations can reduce this file name length:
example 3

wtsMEM001_rl1_sc001_sh011_t02_v1_vikas_RUF.mov

wtsMEM001_1001011_021vikas_RUF.mov

Legibility

One important corollary to abbreviations and consistency is to improve legibility, the ability to distinguish between letters and hence read the file name. Note in example 3 that the text string for reel, “rl” is hard to read when next to a 1. for this reason, try to avoid lower case “l” in abbreviations and codes.
To help with legibility, I kept the client name lowercase and made the show abbreviation all caps. . ou could, if you don't use client names, help by making the show name lower case or switch and make the client all caps – just make a rule an follow it consistently:

example 4

WTSmem001_1001011_021vikas_RUF.mov

mem001_1001011_021vikas_RUF.mov

Next:             
Asset Management 101 – part 7: Essential Rules of File Naming 9 - Use Project identifiers

#0047 Ten Essential Rules of File Naming : 7- There Can Be Only One

Asset Management 101 – part 5

Previous:     
Asset management 101 -- part 4 : Ten Essential Rules of File Naming 4-6

In this post, the fifth to look at the basic concepts of Asset management, we will look at the seventh rule of File Naming, call it the Golden Rule:  There Can Be Only One of Each Version

It's called revision control for a reason.  

Take control.

Every CG Pipeline Production Command and Control System depends upon the identification and tracking of asset revisions and shot takes to avoid chaos and confusion and promote efficient workflows. Equally vital is the association of each asset revision with its source files. So let us talk about best practices in file naming for takes and revisions.

best practice:
Call Composited Shots "takes"

Image by Kid's Birthday Parties via Flickr

What is a take?

Before I go on, let me clarify that in my thinking, any movie asset or sequence should be called a take. This is the terminology used on set for a shot revision that is rendered (captured) by exposing the film or digitizing the image. A take is a unique rendering of a shot.

If you currently use the terminology “version” or “revision” for a shot or element render, please change your thinking immediately and call them takes. It's important, because it puts you more in the language of filmmaking and more into the right mind set. It will help you remember that it is perfectly acceptable and often desirable to present multiple takes to a director for seleection. It will help you remember that a take can have good and bad qualities, and that at some point, you and the director need to accept a take and move on, because there is limited time for production.Finally, it will help you separate and track what the client sees from what your team sees in internal reviews.
 

On the other hand, your still art images, CG files, and other files used to make a take can be called versions if you like, because usually the goal is to produce one final refinement. While one can argue that at the end of your production, there will be one final version of each shot, I still recommend that you think of your composite outputs as takes.  To take this further, I usually number these with a "t" instead of a "v", but as we shall see, using a letter at all is sort of unnecessary.

best practice:
Put Modifiers After Revision Number

In the absence of a solid naming convention that correctly manages the various needs of revision control, artists and coordinators will invent there own ad hoc solutions. which will cause nothing but confusion as supervisors are forced to contend with a mish-mash of file names and, even worse, the destruction of sort order (see rule #5: Protect Sort Order).  The most important thing, is to keep all modifiers after the revision or take number.

Artist names are modifiers
 For example, artists tend to think that it is perfectly acceptable to separate their work from every one elses, and put a revision number after their own name, like this: shot12_jack_t01. This can be really annoying if you're looking at the folder and see that shot12_jack_t01 is newer than shot12_jill_t07.   As soon as you notice this, you know you can no longer count on name sorting, and must now sort and select files by date.  This, by the way, is the most common violation of sort order.  A  more correct way (but not ideal) is :
example 1

shot12_t07_jill
shot12_t08_jack

If you need Jack's and Jill 's authorship to be part of the file name, it should go after the version number, and version number uniqueness must be maintained.  This is the only acceptable way. 

Options and descriptions are modifiers
Another example is the artist decides to put a descriptive modifier before the version number and then makes files:  shot12_redOption_v01.psd, shot12_blueOption_v01psd.  Again, this destroys sort order,   A more correct thing is to put the option description after the revision number:
example 2

shot12_v01_redOption.psd
shot12_v02_blueOption.psd.

You should note that in addition to moving the option to be after the revision number, I incremented the revision number for the blue option.  This will help with tracking, because now no  one will need to include the words "redOption" or "blueOption" when discussing the shot and logging it in software.  If your software takes revision and take numbers, you don't have to design it to accept non-numeric data.

Observe also that the ad hoc introduction of letters after your revision number is also just a modifier, like "red" and "blue", but it adds no real information.  Don't let artists call variations "v003A" or "t02B".  It adds  nothing and causes confusion.  Instead, use a more descriptive word or establish codes for common needs.

best practice:
Tie Render Passes To A Revision

Another kind of modifier comes when rendering CG elements.  Most contemporary pipelines give compositors more final control with multi-pass rendering.  Again, pass names belong after the revision name:
example 3

shot12_v01_rgb.####.iff
shot12_v01_depth.####.iff
shot12_v01_ao.####.iff

Remember File Naming Rule #6, Rendered Files Must Refer to Their Script?  By keeping the CG pass information after the version number, one can infer that all these passes come from the same MAYA file, shot12_v01.mb.  This provides an essential association- anyone assigned to revise a pass knows exactly what script generated it.

Suppose you want to adjust the specular pass for shot 12 and add a dirt pass.  You would modify the script, save it as "v02" and then render only the new passes.  The compositor then would have these assets, and each would tie to a Maya file.  Even though the other passes may render correctly from v02, their source is v01. 
example 4

comp assets from shot12_v01.mb

shot12_v01_rgb.####.iff
shot12_v01_depth.####.iff
shot12_v01_ao.####.iff

comp assets from shot12_v02.mb

shot12_v02_spec.####.iff
shot12_v02_dirt.####.iff

best practice:
Use Takes and Versions Together

When it comes to managing shot take numbers, a company may have a policy to only increment take numbers when a shot is presented to the client, as opposed to increementing the takke number each time a take is rendered for internal review. Each policy has its merits, and we won't debate them, but let's look at how the two policies affect your revision control numbering system.
The first method, which we can call Internal Take Numbering, is to assign a take number each time the script is rendered for review by a supervisor. This is a very simple system and works well with the naming conventions I've describes so far. For example, these NUKE scripts will generate the shots shown
example 5

shot12_t01_jill.nk → shot12_t01.mov

shot12_t02_jack.nk → shot12_t02.movx

shot12_t03_jack.nk → shot12_t03.####.dpx

But suppose your company policy is to use Delivery Take Numbering. In this system, only takes delivered (presented) to the client for review or approval are numbered. Suppose in the previous example, the Quicktime (.mov) takes were for internal review. A company using Delivery Take Numbering might name the files and takes a bit differently:
example 6

shot12_t01_jill.nk → shot12_t01_jill.mov

shot12_t01_jack.nk → shot12_t01_jack.movx

shot12_t01_jack_02.nk → shot12_t01.####.dpx

Do you see the problems here? First, Jack appended a _02 to his second take, which he used to render the delivery take. Second, jack preceded jill in the alphabet. So when sorting, the sort order is broken. This is why earlier I said appending the artist name after the shot revision number is not ideal.
The better way, when using Delivery Take Numbering, is to do what software companies have done for years- modify the release version with a sub-release number. In this case, what you do is use a take and a revision number at the same time,, and no one is allowed to reuse a combination. For example:
example 7

shot12_t01v01_jill.nk → shot12_t01v01_jill.mov

shot12_t01v02_jack.nk → shot12_t01v02_jack.mov

shot12_t01v03_jack.nk → shot12_t01.####.dpx

shot12_t02v01_jack.nk → shot12_t02.####.dpx

In this system, after the take number there is a revision number. Note that in this case, the revision number and artist name is used, and appear only in renders for internal review. Final deliveries are renamed or rendered without the revision number. Of course, this is optional, there is no reason (except embarassment?) to hide the revision number from the client.

Modifications of this system would be to use an undescore or period instead of the v. A period is undesirable, because it could cause confusion in some software, but an underscore works fine. Or you could just concatenate the revision number and use it without punctuation:
example 8

shot12_t0101_jill.nk → shot12_t0101_jill.mov

shot12_t0102_jack.nk → shot12_t0102_jack.mov

shot12_t0103_jack.nk → shot12_t01.####.dpx

shot12_t0201_jack.nk → shot12_t02.####.dpx

I'm personally not a fan of the last suggestion, but if it works for you, go for it. I like this best, and would drop the user name if convenient:
example 9

shot12_01_01_jill.nk → shot12_01_01_jill.mov

shot12_01_02_jack.nk → shot12_01_02_jack.mov

shot12_01_03_jack.nk → shot12_01.####.dpx

shot12_02_01_jack.nk → shot12_02.####.dpx

Make sure your revision modifier policy is understood
If you do use revision numbers after a take number, you have one more decision to make.  It's a big one, and everyone needs to understand the studio's policy: does the revision number modify the current take or the last one?

In software, the revision modifies the release.  For example, 8.2 is a modification of release 8.   to clarify, do you want take 02_01 to come before or after the release of take 02?   In the examples I've given so far, it  comes before.  This is a violation of sort order, so while this may be one way of doing it, I suggest making revision 01 of take 02 to be thought of as the first revision after delivery of take 02.   A look at a shot's comp script files would then give the correct sort order and sequence of revision, the ideal in revision control, and in this system, it is unaffected by the addition or omission of artist names.  In this example, I will use the period to separate take and revision fields:
example 10

shot01_t00.01.shk  → .mov output for internal review shot01_t00.01.mov

shot01_t00.02.shk  → .mov output for internal review

shot01_t01.shk  → .mov output for client review

shot01_t01.01.shk  → .mov output for internal review in response to new direction

shot01_t02.shk  → .mov output for client review

best practice:
Use Codes and Punctuation Sparingly

In the examples 8and 9, I dropped the code letters “t” and “v” aand in one case, concatenated the numbers without punctuation and in the other, seperated the information with an underscore.  In example 10, I used a period.  In each case, what I am after is simplification and improved legibility. I dropped revision numbers for client releases, but that, like so many other suggestions I make here, are really a matter of preference.

However, while you may use a period as a field separator in a script or other asset file names, image sequence file names with extra periods must be avoided:
example 11   the wrong way

shot01_t01.01.aep →  shot01_t01.01.####.dpx 

instead, replace the period with some other punctuation

example 12   the right way

shot01_t01.01.aep →  shot01_t01_01.####.dpx

It's called revision control for a reason. 
Take control.

In summary, the rule for revision control is simple: 

There can be only ONE.  

While there will usually be more than one take or revision, there can only be one take one and only one take two and only one take three and only one ....

Please, defend this rule with vigor! Don't let artists break this rule, ask them to rename their files, and make sure every file has a revision control or ID number (even one off files like a quick Photoshop element or a reference) and make sure every file's revision control number is unique.  

Next:            
Asset Management 101 – part 6: Ten Essential Rules of File Naming 8: Abbreviate Consistently

#0046 VFX Fashion International

A simple cart.  Bagdal Sharif, near Hyderabad India
I felt this looked very interesting.
Is this where Gandalf' parked it?

As some readers may know, I've been in India the last few months Digital FX Supervising at GEON Studios.  GEON is a progressive VFX studio located in a Special Enterprise Zone in the northern part of Mumbai, specializing in digital visual effects for international film and television.



Going International 
My first observation, which I believe I've mentioned before in this blog, is that I see that digital visual effects post has become an international business.  Many Visual Effects Supervisors and Producers are already accustomed to working abroad, in various locales, often for half a year or more at a stretch.  Journeyman level animators and compositors, especially single young men and women with in-demand skills, are often tapped for freelance gigs.   I believe more and more talented artists and supervisors will find themselves looking at work opportunities outside their native land, with talent moving in both directions to meet demands for high-end experience, fresh ideas and perspectives, and help facilitate understanding, communication and cross-cultural relationships in this era of outsourcing.

Image via Wikipedia

People of various countries and cultures, despite the presence of CNN, HBO and MTV on every continent, look at life and experience visual media a bit differently.  At the same time, perhaps due to exposure to western mass-media but more likely due to our common humanity, people experience similar challenges in life and respond to visual symbols with an amazing commonality.  The symbolic language of visual effects transcends verbal expression in a powerful way that I see as a reminder of our common humanity.  Great stories, as told through blockbuster films, can and do reach audiences everywhere.  At the same time, the international audience brings a broader spectrum of perspectives and tastes that are slowly finding expression in American and European media.  Access to self-produced media and internet distribution is making it possible for artists and storytellers around the globe to express themselves. 

The design of these columns in the airport at Kaula Lampur caught my eye.

The Visual Media Fashion Statement
Film media is to some extent a sort of fashion industry, with different directors exploring new ideas in color, lighting, camera, music and yes, visual effects.  Working in visual effects, we may see great landmarks in film making like the VES 100.  But beyond that, if you look at the AFI 100 or make your own list, there have been films that have shifted the visual paradigm of movies, introducing a new fashion statement if you will.  For me, I see films like Gone With the Wind, Citizen Kane, Bonnie and Clyde, Star Wars, and Kill Bill as some of these kinds of films.   I'm sure you can come up with a great list of your own.

I have always been interested in non-Western architecture and art, and I guess one of my points today is to encourage my readers to give themselves broad perspectives by looking our business as a fashion industry.  To me, this means looking at past trends, current trends, and international trends.  For me has meant looking at design developments of the last century, Japanese and Moorish style, and giving a small amount of attention to popular culture.  Long ago I noticed that many cultures around the world have very different tastes in color and color combination.  Lately, I'm seeing in India not only a much more colorful palette than in America, but also some differences in camera and editorial work.  Not necessarily better or worse, but different, an expression of the local culture.

Jang Dong Gun stars in Warrior's Way, a stylistic art film fantasy cultural mixture set in the timeless old west.

A western fantasy makes a fashion statement
Recently I saw a film that I felt very much was a fashion statement, The Warrior's Way.  (As a disclaimer, GEON Studios did about 120 shots for this film.  I was not on staff when most of this was done, and was not actually involved in any shots.)  My colleagues at GEON took me to see it opening week, and while I normally don't much care for ninja movies, this film, while having many ninjas and some great martial arts fights, is more of a very stylized fantasy-western.  Not quite Kill Bill, but with good performances, a good storyline, well-paced editing I found it a reasonably enjoyable film.  What pushed it over the top for me, was the  mise-en-scène, the totality of mood and style.  The stylization of the sets, lighting and visual effects backgrounds was awesome.

Reading reviews, I am again reminded that film making is a fashion business and that not every fashion will appeal to every person or every culture.  It's a mixture of surreal elements with fantasy, super-real  action.  Those looking for realism won't like the film, but it's a film that makes no pretense that it's a "real" story.  It's an impressionist painting, not a photograph.  If you want to see a documentary, this is not for you.  But it's art.

While some hated the film -- others loved it, such as reviewer Rashid Irani, who called it the "zingiest entertainment of the year" in the Hindustan Times.   I think the surreal fantasy and video-game action may work for some.  I suggest you see the film in a theater to appreciate the style. Make up your own mind.


Exotic and Mundane India

Rajeswari sunrise, outside Mumbai, India

Working abroad these last four months has been very interesting and challenging.  I arrived in the middle of monsoon season, and between the rain, settling into my new job, and the logistics of setting-up a virtual bachelor existence in a far away land (although skype has helped), there was almost no time to do anything more than walk around my district.   Around early November, the weather had let up and things were a bit settled, and I made a trek to Bagdal Sharif with a new friend, where we spent a weekend at a spiritual retreat.   That was a great experience, albeit a bit personal.  It wasn't quite as exotic as the movies, depict, no Taj Mahal, elephants, giant bats, snakes or jungles, but the event was something totally new and colorful, and the sunrise over the rolling plain was spectacular in the morning mist, with distinctive Indian trees and rice paddies scattered in some not-quite geometric and not quite fractal pattern.  Later, I made another excursion outside Mumbai and caught a great sunrise through the trees.

Image via Wikipedia

Then a bit later in November, while on  a shopping excursion for family back home, I experienced one of India's more mundane sides: shoddy road construction.  It was near Muhammad Ali Road, a popular shopping destination with hundreds of booths in a spider-web bazaar stretching down small streets in all directions.  While walking along a busy and crowded thoroughfare, single file in the gap between moving and parked cars with people pushing past in both directions, I suddenly found I had stepped off into air with both feet at once, meaning the road was suddenly absent, and fell a few inches into a recess covering some subterranean access portal.  I've spent the last four weeks recovering, with two weeks using an office chair in my flat as a makeshift wheelchair and another two weeks building up strength to walk.  I'm ambulatory again, and that's good because I've been pushing too finish 400+ shots for an exciting new Indian TV series premier episode. 

Perhaps my fall is a reminder that we need to keep one eye on the goal and the other eye on the journey.  Or put another way, as supervisors, we need to look at where we want to go, and how we are getting there.

Have a great day 

may your endeavors be rewarding and 

your visual effects be monumental.

Image via Wikipedia

#0045 Ten Essential Rules of File Naming 4-6

Previous:      Asset Management 101 –  Ten Essential Rules of File Naming 1-3

Asset Management 101 – part 4
 In my last post we looked at the first three of the ten essential rules: Let it Speak, Make it Short, Keep it Simple.

These provide the foundation of a good asset naming scheme.  Before we go on, you will notice in this series  I will use the terms file and asset interchangeably.  For the most part, this is true, but sometimes an asset is a collection of files.  For example, a sequence of image files actually is one asset.


Let's look now at rules four through six:

#4 Avoid Special Characters and Control Punctuation

Special characters, like the colon, semi-colon, parenthesis, brackets, asterisks, ampersands, and so forth can and will choke some application you may use now or may need in the future. This may seem like real basic stuff, but it's also stuff that's regularly ignored. Here's a primer on what to do and not do – and why:

Use command-line compatible punctuation

For safety, I suggest keeping all file names friendly for UNIX or LINUX command line work. While most users today interact with file through file browsers built into the operating system or application, advanced users will rely on command line and scripted solutions to speed repetitive tasks. In UNIX, the only foolproof punctuation characters are underscores and periods. Anything else can and will cause problems. Escaping special characters will increase your in-house program development time AND errors will occur in file operations.

Avoid Spaces

The most famous special character to avoid, now widely violated, is the inclusion of spaces w i t h i n f i l e n a m e s. As illustrated, spaces can make things less understandable if overdone. You and I can read my little example, but a text parser will certainly not know what to do with it. While most software today, will tolerate a space in an asset file name well, but it only takes one application to puke and your whole naming convention is in the dumpster. If that application is your in-house back-up script, I pity the fool who loses a fi le with a space in the name.

Two periods maximum

Stick to periods to separate basename, sequence or frame number, and extension. Period. No extra periods. Extra periods will cause chaos with some software that expects the first period to denote the sequence number and the last (or only) to designate the extension. Period.

The hyphen – if you dare

The next one to risk –and I use the word risk with intent – will be the hyphen or short dash. The hyphen is tolerated well most of the time. But be careful, the hyphen in UNIX means command option. So while you can usually use it with safety, it is ill-advised because, like the space, it can break things. Pity, because it looks great in file names.

Use postScript Notation

Other than underscores, the best way to separate words or concepts is what is called Postscript notation. It's now common in scripting languages, and to remind, it goes like this:

nocapitalCapitalCapitalCapitalCapital.ext

In more words, don't capitalize the first word, eliminate spaces, and capitalize words that follow.
Postscript notation is great, but it breaks down when you have initials, and doesn't always read so well, and that's when underscores help out:

rGB_1stDetail_Layer.ext

You'll notice that in this example, the “r” in RGB is lowercase. You can expect that users will violate the rules and make abbreviations like this all caps: “RGB_” at the start of assets unless you make the rule to keep leading abbreviations lower case:

rgb_1stDetail_Layer.ext

Special Emphasis

There is no way to underline text in file names, but special emphasis can be achieved when necessary with doubled underscores. Notice how the word “1st” stands out in the next example.

rgb__1st__Detail_Layer.ext

Hint: I like to set off take numbers (some people call these version or revision numbers, but I will explain why some files have version numbers and some have take numbers later) with this technique, avoiding the letter:

comp__01.ext

#5 Protect Sort Order

Maintain Chronology

Often people will put dates in file names. When doing this, don't put the day ahead of the month or the month ahead of the year. Make sure all file names with dates will sort in date order by always putting them in year, month, day order. If you ever include time, make it follow the date. Never leave out the year because sooner or later, a project will cross over two years. (For short duration projects, you might be tempted to leave off the month, but again, think ahead....) Some examples:

comp__2010_10_14__01.ext

comp_20101014.ext

comp_2010-10-14c.ext

The last is a good example of when you might wisely use hyphens, if you dare. Note the use of double underscores in the first example. Note also that in the third example, the letter “c” follows the date. This is an excellent way to version date-named files, because it is distinctive and gives you 26 revisions with one character. (27 if you make “a” the second version.)

Variations and Passes after take or version

I cannot tell you how often I see labels identifying variations, particularly layers and render passes, before the version or take number. Almost always. Maya's built-in syntax machine does it this way, and, in my humble opinion, it's backward because it makes sorting on revision level break.
A render layer or render pass is always
Why this is important should be obvious if you are a compositor: you want the latest revision of each item. It is much easier for a compositor to go to the folder where the renders are placed, and get all the elements with the latest revision. If, assuming the compositor has been informed a new revision is ready, there are seven layers and only three new elements or passes, it implies that the prior revision is still valid. But if the version number is after the pass name, the compositor has to be more careful to collect all the right elements.
The final reason: it has to do with my next rule:

#6 Rendered Files Must Refer to Their Script

Every file produced in a digital pipeline is either a script, meta data (such as a shot list) or a product file, and every product file is either directly produced, such as a hand-rendered illustration, or indirectly produced, such as script driven renders. Every cg or composite render comes from a script, and the naming of the script and data products generated must always match.

If I have a most vital rule. This is it. Data products must match their script names. Or, more accurately, because an artist's focus should be on producing a new take or revision, the script must be named so that it refers to the product it produces and the product identifies the script used to make it.

Ignorance of this rule is one of the most common cause of chaos. Imagine you've been asked to revise 23 elements, but have no idea which scripts in the shot tree made them. You have to open every script until you find the one that generated the current version of each element.


Next:            
Asset Management 101 – part 5: Essential Rules of File Naming 7- There Can Be Only One

#0044 Ten Essential Rules of File Naming 1-3

Previous:      Asset Management 101 –  part 2: Understanding File Classification


Asset Management 101
The Ten Essential Rules of File Naming
Ever sit at the computer wondering what to name a file? Who hasn't? In the world of CG-VFX, this moment of decision gives either life or death to your file system organization. Good asset management begins with a good name. The magic of naming things is to remember the basic rule – I Am What I AM.

What does it mean, “I Am What I AM?” For most people, this fundamental question is exactly why there is a moment of indecision about what to name a file – too often a user doen't really understand what a particular file IS. 
 
Remember, in my last article I explained that there are more than 14 broad categories for every asset. So what a file is comes from those 14 plus categories.

Except in some far-off alien world, most files have an extension, which takes care of the file data type. By the way, file data tyoe was deliberately not included in my list of 14 ways to classify an asset, precisely because I consider this an inherent classification. So, since the extension (almost) always provides the essential file data type information, let's continue to ignore file data type. 
 
Now, I'd like to share my 10 Essential Rules of File Naming. Today we look at the first three:

#1 Let it Speak

File or asset names work when they speak to you. Now, how can a name speak? Well, what I mean, is a good name will tell you lots of information about the asset. This is the core and this is the reason we need to consider the 14 classification systems. 
 
For example, often an asset name contains a shot number, some sort of revision number and often a frame number. (Frame or sequence position numbers, are also outside my classification systems, but they are clearly relevant and must be given proper attention to protect them from confusing your applications.)
We will come back to this later. For now, keep in mind that the main function of the asset name is to speed understanding and help bring the most important information forward.

#2 Make it Short

My first principle is a simple one: keep the name as short as possible. The old fashioned 8.3 naming rule was about as useful as used gum on a shoe, but names that are two long can cause problems. The first problem, is that names that are two long can eat-up name memory space in software that limits this sort of thing, which is common in older applications or legacy apps that still have an old-fashioned code base. What happens is that if the names are X length and you have N files, N*X can be too much. I've seen it in some apps' bins and in at least one OS. Another problem, is that a name that is too long could break a database program that assumes a file name of a maximum length for a data field. Too long and the name could get truncated, making it inaccurate or useless, or worse, the program could crash or not accept the entry. Even if the filename length is accepted, the display of the long filename could be a problem if using a spreadsheet or a data form with a fixed length of the name display. So, if designing a name space for your assets, consider your legacy applications' restrictions. (If designing an application, consider your users' name space needs.) The best reason to keep names short is you (and everyone else) will be typing them again, and again and again.

#3 Keep it Simple

Overly elaborate naming conventions suffer from several problems. First and most significant, users will forget the rules or disregard them. Also, an overly elaborate name may be too long, be difficult to read or contain characters that make your OS or applications choke.

While these first three rules may seem basic, they provide a foundation for all the rest.  We'll look at the next set in tomorrow's installment.
 

Next:            Asset Management 101 – part 4: Ten Essential Rules of File Naming 4-6