Video Conservation: Preserve the Superwhites

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 1: Camera data waveform viewed in Resolve.

Figure 1: Camera data waveform viewed in Resolve.

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.

Figure 2: Signal values at the lower and upper end of their range.

Figure 2: Signal values at the lower and upper end of their range.

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.

Figure 3: Black is not 0-percent and white is not 109-percent.

Figure 3: Black is not 0-percent and white is not 109-percent.

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.

Figure 4: Hypergamma and Log Gamma use Superwhite data.

Figure 4: Hypergamma and Log Gamma use Superwhite data.

Lightworks Scopes

Lightworks V14.0 Vectorscope has a much needed skin-tone (hue) line. See Figure 5. 

Figure 5: Adjust skin tone using HUE control under the HSV tab.

Figure 5: Adjust skin tone using HUE control under the HSV tab.

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.

Figure 6: Lightworks’ not very useful WFM.

Figure 6: Lightworks’ not very useful WFM.

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.

Figure 7: Lightworks’ RGB Parade display--100-what?

Figure 7: Lightworks’ RGB Parade display--100-what?

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.

Figure 8: Why a WFM usually shows 20% below zero-percent and 20% above 100-percent.

Figure 8: Why a WFM usually shows 20% below zero-percent and 20% above 100-percent.

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.

Figure 9: Superwhite data are present—before import into Lightworks.

Figure 9: Superwhite data are present—before import into Lightworks.

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.

Figure 10: Superwhite data are lost—after import into Lightworks.

Figure 10: Superwhite data are lost—after import into Lightworks.

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.

Figure 11: In Lightworks the Superwhite data seem to have been sliced away.

Figure 11: In Lightworks the Superwhite data seem to have 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. 

Figure 12: Color bar chart.

Figure 12: Color bar chart.

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.)

Figure 13: Color bar chart in Resolve—under Windows.

Figure 13: Color bar chart in Resolve—under Windows.

Figure 14: Color bar chart in Lightworks—under Windows.

Figure 14: Color bar chart in Lightworks—under Windows.

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

Figure 15: 2160p29.97 Canon C300  AVC  . MXF.

Figure 15: 2160p29.97 Canon C300 AVC . MXF.

Figure 16: 1080p59.94  H.264   .MOV.

Figure 16: 1080p59.94 H.264 .MOV.

Figure 17: 2160p29.97  H.264   .MOV.

Figure 17: 2160p29.97 H.264 .MOV.

Figure 18: 2160p29.97  ProRes 422   .MOV.

Figure 18: 2160p29.97 ProRes 422 .MOV.

Figure 19: Under OS X -- 1080p29.97  H.264   .MOV.

Figure 19: Under OS X -- 1080p29.97 H.264 .MOV.

Figure 20: Under Windows 10 -- 480p29.97  ProRes 422   .MOV.

Figure 20: Under Windows 10 -- 480p29.97 ProRes 422 .MOV.

You may want to explore other articles and tutorials written by Steve Mullen, some titles are listed below. 

Steve Mullen

Steve Mullen

You might also like...

Designing IP Broadcast Systems - The Book

Designing IP Broadcast Systems is another massive body of research driven work - with over 27,000 words in 18 articles, in a free 84 page eBook. It provides extensive insight into the technology and engineering methodology required to create practical IP based broadcast…

Demands On Production With HDR & WCG

The adoption of HDR requires adjustments in workflow that place different requirements on both people and technology, especially when multiple formats are required simultaneously.

NDI For Broadcast: Part 3 – Bridging The Gap

This third and for now, final part of our mini-series exploring NDI and its place in broadcast infrastructure moves on to a trio of tools released with NDI 5.0 which are all aimed at facilitating remote and collaborative workflows; NDI Audio,…

Designing An LED Wall Display For Virtual Production - Part 2

We conclude our discussion of how the LED wall is far more than just a backdrop for the actors on a virtual production stage - it must be calibrated to work in harmony with camera, tracking and lighting systems in…

Microphones: Part 2 - Design Principles

Successful microphones have been built working on a number of different principles. Those ideas will be looked at here.