The Need for Speed!
Comparing the Performance of Colour Correction Systems
by Kevin Shaw

This paper looks at how to compare the true performance and speed of different data-centric colour correction systems.

Introduction

Colour correction systems are so different that it can be quite difficult to compare them in an objective way. Consequently, many people settle for a simple test. For better or worse hardware colour correctors are most often judged by how many windows they can do. It is usually a flawed comparison, but it is easy to make. Software colour systems however, can have an infinite number of windows, so a new method of evaluation is needed. One current favourite is to compare speed. That seems simple enough, but actually it is quite complicated.

I have always maintained that colour correction needs to be real-time so that the hand can correct faster than the eye adjusts. In video, real-time is easily defined as the correct playback speed. Admittedly, there are an increasing number of correct playback speeds; 24fps for film, 25fps for PAL, 29.97 fps for NTSC and more recently 23.98 fps but the speed of video is defined by the standard not the equipment.

Software systems are not limited to fixed standards and system speed is measured by playback, transfer speed, render speed, control interactivity and workflow. Playback and transfer speeds are directly related to the performance and number of processors, the amount of RAM, and the performance of the storage. The render speed and control interactivity are further affected by the efficiency of the software and the interface design. All of these are useful ways to evaluate a system, but equally important is how efficiently they integrate into the workflow.

Real-time control is most important of all. Changes must take effect as a knob is turned because it is hard to fine-tune the image if there is any delay. When slow processing causes the delay, changes step and are applied in bursts. When a buffer causes the delay, changes are smooth but not immediate, which is not quite so bad. Real-time control needs to be just fast enough and can be as little as twelve updates a second on a static frame.

MORE