Video Conservation: Preserve the Superwhites
![Lightworks V14.0.0 editing software.](/cache/uploads/content_images/hero-lightworks_monitor_at_1920_wide_789_686_70_s.jpg)
Lightworks V14.0.0 editing software.
Today’s cameras can provide more dynamic range than ever before and video editors need to be sure their equipment protects that quality. In this Lightworks 14 tutorial, Steve Mullen shows editors how key production tools can monitor the dynamic range of captured video throughout the process.
Figure 1 shows, using Resolve, a typical digital camera’s recorded waveform. It reveals a signal that extends from 0-percent (binary code 0) to ≈109-percent which is either binary code 1023 (10-bit data) or binary code 255 (8-bit data).
Figure 2 presents a table of these data values. The binary codes assume a 10-bit word-length that offers 1024-levels. Depending on a camera’s and codecs specification, some binary codes are not employed. Codes below 64/16 are not generally used as they represent negative signal values—which were possible with analog signals.
What do these codes mean to a photographer? Let’s start with an interpretation of Ansel Adam’s Zone System. Figure 3 shows that “black” extends from 0- to 19-percent while “white” extends from 90-percent to 109-percent. Thus, black and white need not be defined by absolute minimum or maximum binary codes as one might expect.
When grading using Resolve, one does not reduce Lift to shift the bottom of a waveform to binary code 0, but to between 96/24 (≈10%) and 128/32 (≈13%). Thus, “black” is ≈12%. Broadcast white (100%) is found at 940/235. Cameras can record up to codes 1023/255 (≈109%) providing additional dynamic range. The range from 941/236 to 1023/255 is called “Superwhite.”
When cameras shoot using Hypergamma or Log gamma modes, important information is carried by the Superwhite data range. See Figure 4. Therefore, it is critical that an NLE not clip away this data. (See Looking Deeper into Log Gamma.) Thus, I was surprised to find clipping when I field tested Lightworks V14.0. See Field Report: Lightworks Reimagined: Version 14.
Lightworks Scopes
Lightworks V14.0 Vectorscope has a much needed skin-tone (hue) line. See Figure 5.
The new RGB Parade scope is a necessary and welcome addition. Figure 6 shows the Lightworks’ WFM while Figure 7 shows the new RGB Parade display.
You’ll notice both displays have scale markings from “0” to “100” although no units are specified. The V14.0 Quick Start guide makes no mention of the scopes. These unit-less values are not helpful for those of us who rough-grade “by the numbers.” (A very useful practice when one grades on a laptop.) The logical maximum value is 100-percent so it is reasonable to believe Lightworks will clip data above 100-percent.
Unlike most all WFM displays there is no provision for values less than 0-percent or greater than 100-percent. Thus, a colorist would never see the Green-channel anomaly shown in Figure 8.
Lightworks’ Clipping?
Figure 9 shows a frame from an HD ProRes 422 file displayed in FCP X. There is nothing unusual or unique about the signal nor its display.
This is a perfect test image because not only can we see the RGB signals extend above 100-percent—we can see sensor clipping on a patch of bright blue sky. I imported this video into Lightworks and then exported it as ProRes 422 file. Were Lightworks and its codecs correctly calibrated, what went in should come out.
Figure 10 shows the data after the Lightworks export and subsequent import into FCP X. Clearly, what went in did not come out. The entire Superwhite portion of the signal is missing.
Could Lightworks have performed an “auto legalize” compression on the imported data? This certainly doesn’t look to be the case because, as we can see in Figure 11, the peaks look to have simply been sliced away.
What if it’s Not Just ProRes
What if ProRes 422 were not the only codec to clip Superwhites? As I write, a report has been posted on the Lightworks forum that an AVCHD codec may have the same problem as ProRes. As a further test, I imported a number of different formats into FCP X and Lightworks. Comparisons of both NLEs are in the Comparison Sidebar at the end of this article. Figure 15 shows that when the peak waveform is less than 100-percent in Resolve (≈90%) the same value is found with Lightworks. Moreover, the minimum values are approximately the same at 12-percent.
The same correspondence is not found in Figures 16 through 19. FCP X and Lightworks scopes do not agree. Comparisons show the more a waveform that exceeds 100-percent in the FCP X scope, the greater distortion in the Lightworks “scope 90” to “scope 100” range. And, the distortion certainly looks to be clipping.
Looking More Closely at Video
At the same `93 NAB, where I first saw Lightworks, Data Translation introduced its Media 100. As I described in my 1996 review of Media 100, Data Translation's Vincent Video Engine includes the following video components: a luma/chroma separator, an A/D converter that converts analog video to 4:2:2 YUV (YCrCb) digital data, a variable bit-rate Motion-JPEG compressor, plus a circuit that loads YUV video into an RGB 160x120 frame-buffer that can be displayed within a window of any QuickTime application.
The entire video path in the Media 100 was YCrCb from the A/D converter forward. Today, cameras record YCrCb as compressed digital data. (See: Field Report: Canon EOS C300 Mark II Digital Cinema Camera, Field Report: JVC GY-LS300 4K Super 35 Camcorder,Field Report: JVC GY-LS300 Working with J-Log - Part 2, and Field Report: Canon XC10 Camera.) Once these data have been decompressed by a codec the result can be either YCrCb or RGB data. Lightworks employs RGB data, but these data are available only after they have passed from a codec to Lightworks itself. Tests made with RGB images aren’t valid because images are not compressed YCrCb video that must pass through a codec before being used by Lightworks.
A codec can either deliver binary codes 16 to 235 or binary codes from 16 to 255. Under OSX, when Lightworks imports a file, the codec(s) employed seem to transfer digital data ranging from 16 to 235. However, when Lightworks V14.0 is running under Windows 10, ProRes 422 imports are not clipped. Neither are formats such as H.264. Waveforms that peak at 960 with Resolve appear on the Lightworks at “scope 90.” Waveforms that peak at 1023 with Resolve appear on the Lightworks at “scope 100.” (See Figure 20.)
During my work with Lightworks, I bought a PC running an i7 3.4GHz 6700 with an NVidia GTX-1080 so I now run Lightworks under Windows 10. I export using the 2160p capable Sony XAVC-I format. (YouTube and Vimeo both accept XAVC-I.) When necessary, I transcode XAVC-I to ProRes using the Jihosoft converter. Also available from Lightworks, H.264 up to 2160p with an up to a 70Mbps bit-rate.
Lightworks Scope Scale
Although it does not explain why clipping occurs—the Lightworks tick-marks are erroneous. It seems “100” is 110%-percent. For confirmation I imported a color bar chart image (Figure 12) into both Resolve and Lightworks.
Figures 13 and 14 show the value of maximum white in Resolve—where it is 1023 and Lightworks where it is “100.” (Black, in both cases, is zero.)
The Lightworks upper-bar represents 109-percent (code 1023/255). Therefore, when grading one should use the Lightworks’ Highlights control to keep whites between “scope 90” and “scope 100.” Because, 0-percent black is at the zero bar, when grading, one should use the Lightworks Shadows control to bring the bottom of a waveform almost to “scope 0.”
Update: What You Should Do
When working with BT.709 gamma material—whether a camera/NLE handled Superwhites was of limited importance. The Superwhite data added about half-stop greater dynamic range. Lightworks was designed to support BT.709 video—which does include Hypergamma material. Lightworks can be used to color-correct BT.709 footage.
Lightworks was not designed to color-grade log-gamma video nor to work in the DCI-P3 or BT.2020 colorspaces increasingly being employed today. (See A Zero Math Understanding of Log Gamma.) However, if you have shot log-gamma footage, Lightworks can load and use a LUT to convert your material to “BT.709 gamma-like” video so it will look more normal when editing. Of course, an appropriate LUT can also be used to directly create a desired “look.” (See Here a LUT…There a LUT.) (Added 5-23-2017)
Download my Lightworks V14.0 Addendum.
Download my LWshortcuts.prefs file.
Comparison Sidebar
You may want to explore other articles and tutorials written by Steve Mullen, some titles are listed below.
![Steve Mullen](https://www.thebroadcastbridge.com/uploads/content_images/_Small/Steve_Mullen.jpg)
Steve Mullen
You might also like...
HDR Picture Fundamentals: Brightness
This article describes one of the fundamental principles of broadcast - how humans perceive light, how this relates to the technology we use to capture and display images, and how this relates to HDR & Wide Color Gamut
AI In The Content Lifecycle: Part 4 - Pushing The Content Distribution Boundaries
Generative AI is poised for another round of disruption across key aspects of media content distribution. These include recommendation, streaming, quality control during transmission, and video encoding.
Virtualization - Part 2
In part one, we saw how virtualization is nothing new and that we rely on it to understand and interact with the world. In this second part, we will see how new developments like the cloud and Video Over IP…
Essential Guide: LED Walls For Virtual Production
This Essential Guide explores the technology of LED wall displays for virtual production. It discusses fundamental requirements and the relationships between the LED wall and the other equipment required for virtual production techniques.
Designing IP Broadcast Systems: Part 4 - System Management Software
Welcome to the fourth and final part of ‘Designing IP Broadcast Systems’ - a major 18 article exploration of the technology needed to create practical IP based broadcast production systems. Part 4 discusses the increasing role of system management and configuration software in …