Key Concepts

Virtually every aspect of Chalice has been designed to help film compositors work faster, more efficiently, with less duplication of effort, and produce the highest quality imagery. To take advantage of these features, however, requires some knowledge of how Chalice works.

The purpose of this chapter is to help users get the most out of Chalice by reviewing both the concepts behind the Chalice system and the way these concepts are implemented.

The Dataflow Paradigm

Chalice employs a procedural dataflow paradigm for effects creation. The procedural part means that you build a description of a shot, with feedback from monitor previews throughout, and only render out actual image frames when you are satisfied with the result. This is ideal for a process that almost invariably requires numerous changes--you change only the description, and only where the changes are needed.

The dataflow aspect refers to the way you build a shot. Each operation is represented as a node in a flowchart-like network of nodes. The connections among the nodes represent the flow of data through this network. The dataflow model offers the most flexibility because it is " self-documenting," which simply means that the structure of the network itself shows you how the shot has been constructed, making it easier to pinpoint areas to be changed or tweaked--by the shot's creator or by another artist.

In this Chapter

The section on dataflow mechanics is a nuts-and-bolts description of how data flows through the system. This background can help you make sense of the system and use it more effectively. It covers the basics of processing, sequencing, frame navigation, and previewing effects in monitors, with examples of how to connect nodes in the most efficient order for faster processing.

Of course, no other advantages will matter in the long run unless the image quality is there. The section on Image Representation in Chalice discusses how image formats vary, and how Chalice imports and represents image data.

As important as working effectively within an individual grail file is taking advantage of the system's ability to manage data throughout a facility. The section on teamwork discusses the sharing concept, which helps eliminate duplication of effort wherever possible and ensure consistency of elements from shot to shot.

The final section of this chapter covers memory usage, and especially image caching, to help you get the best performance from Chalice.

Dataflow Mechanics of the Chalice System
Image Representation in Chalice
How Chalice Facilitates Teamwork
Memory Usage in Chalice

Dataflow Mechanics of the Chalice System

As discussed elsewhere, Chalice employs a dataflow paradigm in which you create a description of a shot by building a flowchart consisting of nodes, in which each node represents a different operation. A dataflow network starts with one or more Disk Input nodes, which point to the source image files you will be modifying.

Whatever operations you perform on this imagery, finally you will want to render new image files of the completed shot to disk. In Chalice, you use a Disk Output node to specify how and where to write the image files, and connect it to an Exec node. A Chalice dataflow always terminates at an Exec node, the master control you use to instruct Chalice to begin processing.

Image Dataflow

You can think of the data as a stream, which flows left to right across the interface, from the source (Disk Input) nodes to other nodes downstream, being modified by the nodes you connect, in the order you connect them, until it reaches the end of the network. This left-to-right flow is considered to be the most natural for English speakers, who read and write using the same directional flow.

Sequence (Frame Number) Dataflow

Just as image data is passed through the network, the command to process each frame is also passed through the network, in the opposite direction. The function of the Exec node is to send a sequence of frame numbers, one at a time, upstream in the dataflow to which it is connected.

For instance, to process a sequence of frames 1 to 15, the general operation would be to first send the number "1" to the dataflow node that is directly connected to the Exec node (to the left). Each node passes the frame number upstream until it reaches the source, where the image data for that frame is read and delivered back downstream, being modified by each connected node until it reaches the Disk Output node and can be written to disk. The Exec node waits for the nodes upstream to finish computing before delivering the number "2," and so on.

This is important to know because the purpose of some nodes is not to modify the image but to modify the sequence--to remap the frame numbers that are passed through the network:

  • Most nodes in Chalice will pass the frame number unchanged to the node connected on its left. Filters and composite nodes, for example, fall into this category.
  • Another class of node, however, modifies the frame number received on the right and delivers a new number upstream. These include some of the video-type nodes. For example, the 3:2 Pulldown node creates five video frames from every four film frames and therefore changes the length of a sequence. This category also includes the node we will discuss next, the Sequence node.

Resequencing Frames

Imagine that the Exec node passes the number "5" to the dataflow upstream. The actual processing of data will not occur until a source node is reached. Once that is found, the node will start data processing and pass the data downstream as it is calculated. As each node completes its own processing, it notifies the node or nodes connected to it downstream of the data that it is presenting, until the last node in the chain connected to the Exec node prompts the Exec node to hand out the next frame number (assuming there are more numbers to process). When the Exec node has no more numbers to hand out, the processing is complete.

In the simple example given above, in which the Exec node sends the numbers 1-15, it could be the case that the source imagery really starts on frame 101 and goes to 115. Or it could be that only frame 101 is used repeatedly for 15 frames. Or the 15 frames could consist of 6 frames from one source node and 9 frames from another.

The Sequence node--and the Sequence tab in the Disk Input node--allow us to "shift" time so that when we are trying to process output frame 1, we can actually use input frame 101 if desired. In fact, the Sequence node enables non-matched frame numbers to be combined in any fashion.

Using the example of source frames 101 to 115, the simplest way to remap them is to use the Sequence tab directly in the Disk Input node. The parameter controls on this tab will also enable you to add holds, loops, and so forth.

For the example of frames 1-15 originating from two separate sources, both Disk Input nodes would be connected to a Sequence node. If the first Disk Input node contained frames 101 to 115, you could remap frames 101 to 106 to numbers 1 to 6. Likewise, whatever the frame numbers of the imagery in the second Disk Input node connected to the Sequence node, any specific nine frames in the input could be remapped to frames 7-15.

The Sequence node can be inserted anywhere in a network to resequence frames, and it accepts as many different inputs as necessary. This is why the frame number being passed upstream is relayed through each node. The Exec node does not deliver the number "1" directly to all the nodes; it just passes that number upstream, where it may be altered by a Sequence node or any other node of the same class.

Developing a Grail Script

A grail script refers to the network of nodes you build in a grail file. Let's assume that we wish to blur some frames and have set up the Exec node to process numbers 1 through 10 with an increment of 1. A Disk Input node points to 10 files, which are labeled "sharp.0001.rgb" through "sharp.0010.rgb." The Disk Output node points to a path and filename of "blurred." The Blur node is connected between the Disk Input and Disk Output. If we were to run this grail script by specifying the Execute command in the Exec node, we would create 10 files named "blurred.0001.rgb" through "blurred.0010.rgb."

Debugging a Grail Script

Now assume that we have hooked this up for the first time and would like to "debug the script"--that is, we would like to examine the result and make any necessary changes to the dataflow. For example, we could decide to make the image a little more or less blurry.

Say we want to see what frame 5 looks like. We could conceivably use the Exec node to write frame 5 to disk and then look at the frame to make sure that it met our requirements. However, another technique is actually used that enables us to debug an image without requiring that we write the image to disk to review it.

Node Monitor Previews

We can use the Local Node Menu on the Blur node to open a node monitor. This has an effect on the system that is very similar to when we executed the network in the Exec node. The node monitor acts like an Exec node in this case, instructing upstream nodes to send it data, except that it gets the frame number from the Frame Controller.

Once the source image data is accessed and passed downstream, perhaps being modified by other nodes along the way, it reaches the Blur node, which processes it (in this case, blurs it) and presents it at the resolution specified when the monitor was opened. To view the effect of the blur operation on any specific frame, the Frame Controller would be changed to that number.

The Frame Controller is used to specify a frame number for whichever node is currently selected. (This is important both for viewing imagery at a node and for setting and animating node parameter values, as discussed in chapter 6, "Node Panels and Parameters .")

Both a Monitor actuation and the "execute" command in the Exec node cause the system to calculate, or "cook," the image data through all nodes connected to it upstream in the network--the difference is how they get the number they will subsequently deliver to the upstream node(s) and, of course, whether the processed image data is merely displayed in a monitor or written to disk.

By merely looking at the Monitor of a node we have not output any data to disk. Image data is only written to disk by issuing the Execute command in the Exec node. Then it is written in the format and to the location specified in the Disk Output node, which is connected directly to the left of the Exec node.

Comparing Node Monitor Views

You can view an image at any stage of modification in the network by opening a monitor at a specific node. In fact, you can open multiple monitors to view imagery side-by-side for comparison. For example, you can examine the unmodified source image by opening a Disk Input monitor. To examine the same image cropped, assuming this was one of the operations in the network, you would open the Crop node monitor. To view the cropped, blurred image, you would open the Blur node monitor, and so on. To view another frame of the sequence at any stage, you would specify that frame number in the Frame Controller.

This principle applies no matter how large the node network becomes. You can always open a monitor at any node in the network to display any frame of the imagery at that stage of processing.

Nodes as Building Blocks

The flexibility of the system whereby each node represents a separate image processing operation means that you could just as easily crop an image after blurring it by connecting the Crop node downstream of the Blur node. As it happens, for these two particular operations, the Crop-to-Blur order is preferable because it takes less processing time--only the pixels in the cropped image are blurred. If you discover this fact after creating a Blur-to-Crop connection, you can easily rearrange the nodes at any time, not matter how many more nodes are connected upstream or downstream in the flow.

For More Information

We recommend that you read chapter 5, "Building Chalice Networks ," for an overview of the Chalice interface and the steps involved in creating grail files; chapter 6, "Node Panels and Parameters ," for an explanation of how to set and change node parameters; and chapter 8, "Monitors and Flipbooks ," to find out more about the features of Chalice monitors and how to use them.

Image Representation in Chalice

The sophistication of today's image processing tools have made it possible for digital artists to create effects that were unimaginable even a few years ago. But these tools generate numerous image types and file formats that are often not inherently compatible. However, all of these disparate file types must be successfully merged during the compositing process.

The advantage of the Chalice system is that it is able to recognize these differences in image formats and types, and it gives the user full control of the technical and creative processing of the imagery.

The first goal of the Chalice system is to easily import any image, in any format. Then the challenge becomes interpreting the image data and, if necessary, converting it to be compatible with other imagery in the composite without sacrificing image quality.

How Image Formats Vary

Digital image file formats can vary in a number ways. These differences can include how much space is allotted to storing information about each pixel, and how that information is stored--as linear or log data, compressed or uncompressed, and so on.

Each file type is tied to specific rules; for example, one format may allot only 8 bits per pixel, while another format will require floating depth (32 bits per channel) precision. Or the data stored by the file may represent different colorspaces, such as RGB or YUV.

Furthermore, a file type may represent a single channel of image data, three channels, four channels, and so on. And a channel of data may represent color data, matte data, or z-depth data. Almost all these formats also support images of varying dimensions (height and width).

Most of these file types also support some kind of compression that reduces the file size of the image using an encoding process that requires an opposite decoding process before the user can display the image. Some compression techniques are "lossless" and some are "lossy." In the case of the lossless techniques, all data in the original image is retained. In the lossy techniques, some data--perhaps not enough to be discernible to the human eye--is lost in the compression stage.

Note:
A complete list of file formats is available in the section on "Image File Formats Supported by Chalice " in chapter 12, "I/O Nodes ."

Data Representation in Chalice

Once an image file has been imported into Chalice, the issue becomes how the data is represented. Chalice must concern itself with the number of bits that were used to represent the data, as well as what kind of data those bits represent.

The Chalice system provides maximum flexibility and control by separating the notion of file I/O from color representation. This enables you to control how image data gets converted within Chalice, based on the nature of the specific imagery and the project, so that you can preserve the most image information to get the highest quality output.

Bits per Channel

The Chalice system performs all its math internally as 8- or 16-bit per channel integer, or as 32-bit floating point operations, depending on the image data. You can work with image data in all of these bit depths in Chalice, even within the same file. At some point, however, this disparate data has to be combined in a composite operation.

Chalice enables you not only to control whether data is promoted to a higher bit depth or demoted, but also to customize the conversion, if desired, based on where the most important information lies in any particular image.

Nonlinear Data

There are two major categories of image representation: linear and nonlinear. Many commercial graphics software packages use linear data for their internal calculations, as does Chalice.

Linear data can be described as information that changes evenly no matter where you are in the metric space. The difference between 2 and 3 in the linear colorspace is 1. The difference between 105 and 106 is also 1 in linear colorspace.

Nonlinear systems, on the other hand, represent the data logarithmically. More of the metric space, the precious counts of the numbers you are using, is used where you need more color data and where you do not, it uses fewer counts. This data format is especially appropriate for representing visual imagery.

One of the most common nonlinear representations is that created by Cineon, a Kodak company. They chose to represent digitally scanned film data by taking the log base 10 of the linear data. In order to fully represent the negative film density range, Cineon determined that they required only 10 bits of log data. (To retain all the data found in this format and convert it to a linear form would require about 19 bits of linear data.)

In this nonlinear colorspace, the digital counts of the low numbers have more resolution--smaller increments of film density for each count--giving the blacks adequate information for proper representation.

On the other hand, the whites, the high numbers, do not need the same sensitivity and a count in the high ranges represents a larger increment of film density. This method applies the resolution where it is needed instead of applying the highest resolution to the whole colorspace, as with the linear method.

Cineon Conversion Options in Chalice

For Cineon log file conversion, Chalice offers a combination of flexibility and ease of use. By default, Cineon files are converted automatically when they are imported using a straight linear remapping to the full 16-bit linear space so that you can work with the imagery just as you would any other 16-bit linear format.

Unlike most other compositing programs, however, you can modify the default conversion, choose a different conversion method, or no conversion at all. You can convert Cineon log to floating point linear. (As mentioned above, it actually takes more than 16-bits per channel in linear space to represent all the log data.)

Or Cineon can be converted to 16-bit or floating point linear using the option we call "Cineon Linear," which takes film density factors into account when remapping the values. The Log 90% White value is mapped to Linear 90% White, instead of to the maximum value of the colorspace, and values above Log White are not clipped. This enables you to retain image data at the high end and to accommodate colorspace shifts later in the network. And you can change the default conversion values if appropriate for your imagery.

You can even convert Cineon files to 12-, 10-, or 8-bit linear, if necessary, using a conversion node that will allow you to specify the most important part of the image data to keep for any particular image.

This flexibility is also provided when converting imagery back to Cineon log for output.

You can also choose not to convert the log data at all. All Chalice operations expect to work on linear data, but this does not mean you cannot choose to perform Chalice operations on unconverted Cineon log. For certain operations the results could be unpredictable (although quite interesting), while for others, a crop, for example, you can expect reliable results operating on log data.

Whether converting log or linear data, Chalice always provides optional control over which segments of the input image colorspace are allotted the most room in the converted image.

For More Information

Refer to chapter 12, "I/O Nodes ," for information about importing, converting, and rendering image formats. For information specific to Cineon conversion, refer to the DPX and Fido Parameter Tabs section of the Disk Input Node description.

Chapter 14, "Conversion Nodes ," describes the individual nodes you can use to convert imagery at any point in a network.

Two documents from Kodak and Cinesite specify Cineon conversion, "Grayscale Transformations of Cineon Digital Film Data for Display, Conversion, and Film Recording," from the Cinesite Digital Film Center (1993), and "Conversion of 10-bit Log Film Data to 8-bit Linear or Video Data," from Kodak Motion Picture and Television Imaging (1995). These documents, in pdf format, are available for downloading from the Silicon Grail website.

How Chalice Facilitates Teamwork

Other sections of this chapter focus on issues that relate to the productivity of individual users working within Chalice. This section introduces another key way in which Chalice increases productivity: it encourages sharing work throughout a facility, not only among composite artists but also between the 2D and 3D departments.

For example, in a Chalice shop the 3D artists can prepare their temp comps with Chalice. Then when they hand their work off to the 2D people, some of the work has already been done. Not only that, but by definition, the artist will have tweaked the comp to make the 3D work better--these tweaks are now available to the composite artist, not as notes or as a discussion, but as an actual composite network. This also makes it possible to get feedback from the director or effects supervisor earlier.

This teamwork approach eliminates a lot of duplication of effort. The ability to easily share data among compositors not only saves time and effort, but it can help ensure consistency in the look of a finished series of shots. This concept is extended as far as possible by Chalice:

  • The Chalice architecture allows more than one artist to work on the same shot at the same time.
  • A 2D supervisor can stipulate a specific set of preferences for all compositors working on a project.
  • Using presets, several artists can share a look or a technique, without bothering to learn how it works.
  • Groups of nodes which have been customized for a particular task can be added to the node menus of all Chalice users, who can then add them to their networks as easily as they can any other node. For example, a supervisor can pass out the same color corrections to an entire staff.
  • Successful techniques and ideas can be saved for use on future productions--thus Chalice users begin to build an inventory of expertise that they can apply to future work, to either speed up that work or do a better job in the same time, or both.

For More Information

Refer to chapter 7, "Managing Large Networks ," which covers the creation of custom networks, to chapter 6, "Node Panels and Parameters ," which explains how to create and use various presets, and to chapter 11, "Setting Preferences ."

Memory Usage in Chalice

Image processing is, of course, memory-intensive. The following information about how Chalice 2.0 uses available RAM and disk space to cache data is provided to help you understand how to use Chalice caching options to your best advantage.

What Is Caching?

As each Chalice node completes its task, it saves, or caches, a copy of what it has just computed. This is so that if another request comes for the same image data, rather than go through all the computations again, the node can just hand off the cached result. This saves a lot of time, but uses a lot of memory space, as each node in a large network can potentially save one or more images.

Data is cached in two ways: in RAM and on disk. The RAM cache is kept in main memory. RAM provides much faster access, but there is less of it, and some RAM must be kept available for the operating system and for Chalice itself.

Disk cache refers to a section of the hard drive that has been allocated to Chalice. This memory space is potentially much larger, but it is also much slower to access, which is why disk caching is used only after RAM cache has filled up.

Also, Chalice 2.0 will only cache to disk if the time to recompute the data is greater than the time it would take to write it to disk. In other words, Chalice will not bother to cache data to disk if it would be faster just to recompute it.

Direct I / O

Chalice 2.0 uses direct I/O to write data to disk. That is, Chalice handles the write directly, bypassing the operating system. This makes all I/O, including caching, both faster and more memory efficient.

This is true for NT, Linux, and IRIX, but it is especially noticeable on IRIX systems. The problem with handing data off to the operating system is that the OS itself buffers data, so that handing 10MB of data to the OS to write to disk when RAM is tight could actually mean that another 10MB of RAM would be allocated by the OS to buffer it. This would cause a vicious circle of less RAM causing more disk writes, which would further reduce RAM, and so on, until performance ground to a halt.

How Caching Works

A simple two-node network in Chalice can illustrate how caching works. Assume that a Disk Input node is connected to a Gamma node. What happens when we ask Chalice to bring up a monitor on the Gamma node?

The Gamma node requests an image on which to do the gamma correction from the Disk Input node. The Disk Input node accesses the disk and reads in the image that is relevant at the current frame. To do so, it allocates a block of image memory, and then reads the image into it.

At the end of this read operation, the Disk Input node does not throw away the image; instead, it hangs on to it, assuming that it may be asked for that same image again in the future. This becomes the first cached image.

When the Gamma node receives the image from the Disk Input, it applies the gamma correction to it. As well displaying the result in a monitor, it also saves the calculations for any future request. This becomes the next cached image.

Controlling Individual Node Caching

Most nodes store a single image, or "cook." Using the Gamma node example, if the gamma value changes and is recomputed, the Gamma node throws away the earlier result and caches the latest one instead.

But the Info tab of every node provides parameters you can use to change this behavior. It is possible to tell a node to store up several images at once by increasing the value of the Cache Size parameter from the default value of 1.

Note:
Certain nodes, such as Time Convolve, will do additional caching anyway unless you turn off the "Auto Cache" feature, because by their nature they will be using data from more than one frame to modify the image.

How Chalice Prioritizes Node Caching

Chalice always tries to ensure that any image data that might be needed again is available without recomputing, and it always tries to avoid using the disk cache if possible.

But Chalice also tries to conserve memory, so when the cache begins to get full, it uses certain guidelines to decide which data is most likely to be reused. For example, a node whose output branches to several other nodes has a high priority, as its data is likely to be requested by more than one node branch.

Chalice never caches if it is not useful. Chal renders are not cached since there is no frame to frame coherence, and the Exec node doesn't save image data (since it has no output).

Image Slicing

Slicing is an option available when writing imagery to disk and when cooking image data in a monitor. Slicing is intended to dramatically reduce the memory requirements of Chalice by slicing an image into segments for processing.

Ideally, slicing an image into eight parts would use only one-eighth the memory, as each slice would be treated as a separate image. This would mean that instead of a node caching an entire image, it could cache a slice at a time for reuse.

But any node that is feeding a node which is being monitored or modified has to store not just one slice, but all of them, so that the complete image is available to the requesting node.

Shared Memory Segments

Each time a node allocates memory for an image, it allocates shared memory. This allows images to be shared between the work process (chal) and the UI process. It is possible for every node in a large network to contain an image, and thus use a shared memory segment. Because all allocated (image) memory is set up as shared memory, chal requires a lot of shared memory segments too.

If slicing is being used, the number of segments can go up still further, even though the total amount of memory used is smaller. This is because some nodes end up requesting a lot of small pieces of slices. The Blur node, for example, needs some pixels from slices above and below the current one to calculate the pixels at the top and bottom of the slice. That requires more memory allocation and thus more shared memory segments.

And in the Transform node, rotating can result in many little pieces of slices as images get rotated out of frame or out of the current slice. This means that grail files with numerous Transform nodes can result in high shared memory segment counts.

Fortunately, allocating large numbers (over 2,000, e.g.) of shared memory segments has no real effect on the operating system, except to increase the size of the kernal by a few thousand bytes. For most users of most machines, this will make no noticeable difference to performance.

For More Information

Use of the node caching parameters on the Info tab is covered in chapter 6, "Node Panels and Parameters ." The Cache Settings panel is accessed from the Chalice Admin Menu , which is covered in chapter 10, "Main Menu Bar . "




Table of Contents | Index



Copyright 1996-1999 by Silicon Grail Corporation