GH4 Pullingl up the blacks?

[dvbrother]

c3hammer, what NLE are you using? I think you are absolutely correct in using 16-235 with the NLE you are using.
However, I edit in Premiere on a Mac, and with Premiere, 0-255 and 16-235 look exactly the same on the waveform. It's only when I set the GH4 to the goofy 16-255 that the waveform does exactly what it does in your example...clipping highlights. From my understanding, this is a flagging error. With Quicktime on a Mac, 0-255 and 16-235 are flagged correctly.

But in your example, and I can assume you are on a PC (sorry for my ignorance of what program you are using), it looks like 0-255 is also incorrectly flagged and is clipping your highlights. This is not a camera issue.
However, in your circumstances, at this point it looks like 16-235 is the way to go.

 

[c3hammer]

...it debayers the RAW data...

I don't believe this is true. There is no debayering in 4k. It's pixel for pixel directly from the sensor.

...the YUV data is always scaled to the equivalent of 16-235 range, at 16-bit signed precision or better

Again, I don't believe this is true in the case of the GH4. First, it is not ever YUV data but RGB that is converted to Y'CbCr before encoding. 0-255 is not being scaled at all, but simply a math conversion from RGB to Y'CbCr. If I select 16-235 luminance it appears to be scaled to that range. Though we have no idea with this new cam what precision it is being done at or how.

...The H.264 encoder then transforms the YUV data into 8-bit macroblock spatial frequency components, at quality levels quantized to fit within the available bitrate. There are no "pixels" in the encoded H.264 data, 16-235 or otherwise, it's all 8-bit macroblock components...

Which can be 4x4, 8x8 or 16x16 with a motion vector depending on how the encoder is programed. Again from Y'CbCr not YUV.

...the encoder to When you select the 16-235 option, the GH4 scales its RGB data to fit within this range (but does not reduce its internal data precision to 8-bit)...

Yes, I'm assuming this is done before conversion Y'CbCr and then the encoder to h.264. We aren't getting the same precision out of encoding 0-255 in this process as only 16-235 and we surely aren't getting the same precision between the two when decoding back to RGB with this much information from 4K in only 100mbps.

...The H.264 encoder then sets a metadata flag in the video file that instructs H.264 decoders to scale their RGB pixel output to the same 16-235 range. Whether this makes any difference at all depends on the bit-depth of the decoder. If you edit in a 16 or 32-bit video editor, the decoded 8-bit 4:2:0 YUV data will be converted into high-precision RGB data, and there will be no perceptible degradation in image quality. If you had originally selected the GH4's 0-255 mode, the decoder would scale its high-precision RGB data to that range instead.

Vegas is an interesting beast in this regard. It doesn't scale anything. It simply displays what is in the file. The metadata is irrelevant and it just shows what is there.

LPowell, if you have a GH4, do the test and see if you don't see the difference this particular camera is producing between the to luminance levels. It's not simply doing a levels adjustment before encoding. If you don't have the cam, you need to get one to see. I can't say for sure exactly how it is doing it, but there's a distinct difference. I'm sure part of it might be my PC / Vegas system, as it handles levels radically differently to Apple and Premiere, but the GH4 is a unique beast to say the least.

Cheers,
Pete

 

[c3hammer]

dvbrother, I'm on PC with Vegas. If I view the clips in quicktime everything is mapped to 16-235. 0-255 and 16-235 clips look identical on my PC in quicktime. All washed out

Interestingly, it looks like quicktime maps 16-255 clips as 0-255 and displays in 16-235. It boosts the shadows even more making the files completely washed out on the low end. Surprisingly all the other players I have look correct. 0-255 show full range with white whites and full black while 16-235 is pushed to the middle on both ends, 16-255 is pushed up on the low end and white white on the top. It's only quicktime that tries to convert to some other range.

As for the Vegas waveform, I'm pretty confident that it is displaying the actual levels in a relative IRE range. IRE has a nominal range of 140 (-20 to +120) It should be consistent with 0-255, but that depends greatly on what the cam is actually capturing. Many cams will actually capture quite a bit outside this range.

Interesting discussion for sure.

Cheers,
Pete

 

[Lpowell]

H.264 encoding doesn't work the way you may think it does. The GH4 digitizes its RGBG sensor channels to 12-bit precision. In video mode, it debayers the RAW data, applies the tone curve settings, and converts to YUV format. Internally, the YUV data is always scaled to the equivalent of 16-235 range, at 16-bit signed precision or better.

I don't believe this is true. There is no debayering in 4k. It's pixel for pixel directly from the sensor.

Before you take this misconception any farther, I'd recommend some study of the basic properties of Bayer filters:

http://en.wikipedia.org/wiki/Bayer_filter

If, as you claim, the GH4 did not debayer its 4K video frame, you would see a mosaic of red, green, and blue pixels instead of a full-color image. It is for this reason that debayering is necessary, even when the sensor pitch matches the frame resolution.

The rest of the technical points you attempted to make are founded on similar misconceptions. For example, this claim is too incoherent to decipher:

"First, it is not ever YUV data but RGB that is converted to Y'CbCr before encoding. 0-255 is not being scaled at all, but simply a math conversion from RGB to Y'CbCr."

BTW, "YUV" is a generic term commonly used when it's not necessary to use a term as specific as "Y'CbCr". In this case, the technical distinctions are irrelevant to the discussion.

...The H.264 encoder then sets a metadata flag in the video file that instructs H.264 decoders to scale their RGB pixel output to the same 16-235 range. Whether this makes any difference at all depends on the bit-depth of the decoder. If you edit in a 16 or 32-bit video editor, the decoded 8-bit 4:2:0 YUV data will be converted into high-precision RGB data, and there will be no perceptible degradation in image quality. If you had originally selected the GH4's 0-255 mode, the decoder would scale its high-precision RGB data to that range instead.

Vegas is an interesting beast in this regard. It doesn't scale anything. It simply displays what is in the file. The metadata is irrelevant and it just shows what is there.

Sony Vegas' color space issues have a long and convoluted history of their own:

http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

My impression is that Vegas color space pitfalls arose from an incomplete implementation of a Managed Color system like the one used in Adobe After Effects. In 32-bit mode, Vegas requires you to set up your project as either Full Range or Studio Swing (i.e. 16-235). The problem is that not all of Vegas' built-in decoders were originally able to scale their output appropriately for each case. I'm not sure whether those issues have been fully resolved in the current version of Vegas.

In editors like Premiere and FCP, you don't explicitly choose the project's color space. The editor uses each video file's metadata tags to automatically set its video color space and IRE scaling. This works transparently in 32-bit floating point mode, with no clipping or degradation of out-of-range composited data. Scaling restrictions are imposed only when the project is rendered to a particular video output format.

 

[c3hammer]

Before you take this misconception any farther, I'd recommend some study of the basic properties of Bayer filters:

Sorry I misread 'debayer' as 'binning', which the GH4 doesn't do in 4k mode. I actually do know the difference, but be careful you might still be able to teach me something

...For example, this claim is too incoherent to decipher:
"First, it is not ever YUV data but RGB that is converted to Y'CbCr before encoding. 0-255 is not being scaled at all, but simply a math conversion from RGB to Y'CbCr."

This is from your statement Internally, the YUV data is always scaled to the equivalent of 16-235 range, at 16-bit signed precision or better in your previous post. I don't believe there is any scaling when 0-255 luminance is selected. Isn't the 12 bit raw simply rounded to 8 bit without any scaling here as the conversion from RGB to Y'CbCr is done? Scaling only takes place if 16-235 luminance is selected.

Isn't the h.264 encoding only taking either 256 levels with 0-255 selected or 219 levels when 16-235 is selected? If this is incorrect, might you have a link to a flow chart of how the GH camera's are getting from sensor data to h.264 to help clear up my misconceptions here?

Thanks for your patience with me

Cheers,
Pete

 

[Lpowell]

This is from your statement Internally, the YUV data is always scaled to the equivalent of 16-235 range, at 16-bit signed precision or better in your previous post. I don't believe there is any scaling when 0-255 luminance is selected. Isn't the 12 bit raw simply rounded to 8 bit without any scaling here as the conversion from RGB to Y'CbCr is done? Scaling only takes place if 16-235 luminance is selected.

Isn't the h.264 encoding only taking either 256 levels with 0-255 selected or 219 levels when 16-235 is selected? If this is incorrect, might you have a link to a flow chart of how the GH camera's are getting from sensor data to h.264 to help clear up my misconceptions here?

YUV (and Y'CbCr) formats are based on analog video broadcast standards for CRT displays of the paleolithic era. At the time this analog technology was first converted to digital video, 8-bit precision was the highest quality available. Consequently, the YUV color space was defined specifically in 8-bit terms with analog 0 IRE set to digital level 16 and 100 IRE set to 235. In those days, all equipment and software was physically calibrated (often by eye) to operate in this standard broadcast range, often referred to as "Studio Swing" to distinguish it from 8-bit RGB computer graphics, which used a "Full Range" 0-255 color space.

A subtle point that is often missed is that YUV formats always use Studio Swing levels by definition, while RGB formats may be calibrated to either Studio Swing or Full Range levels. Some feel that 8-bit RGB video should use the same 16-235 range as YUV, but on a technical level, 8-bit RGB and YUV scales aren't precisely matched to each other. To convert cleanly without perceptible quality loss from 16-235 RGB to YUV format, you would need more precision than 8-bit YUV. Likewise, precise conversion from 8-bit YUV to RGB requires more than 8-bits of RGB.

With modern hardware and software, however, these historical 8-bit issues have become moot and vestigial. In the GH4, RGBG sensor data is digitized at 12-bit RAW precision, and there is no need to internally degrade it down to 8-bit precision. The camera's processor and RAM manipulate the data in 16-bit (or 32-bit) registers, where there is plenty of room to handle transient calculations without overrange data loss. As a result, debayered RGB data can be efficiently converted to YUV format without perceptible quality loss.

In video mode, the GH4 must prepare subsampled YUV data for encoding each frame into H.264 format. To properly interface with the H.264 encoder's built-in IRE standards, the camera must scale its internal data levels to either Studio Swing or Full Range levels. Since the camera has 12-bit RAW data to work with, this is easily accomplished without perceptible quality loss. The H.264 encoder then converts the high-precision YUV data into quantized 8-bit macroblock spatial frequency components. At no point is it necessary to degrade either RGB or YUV data down to 8-bit precision.

When an H.264 file is decoded in a video editor, its 8-bit macroblock components are converted back into YUV format. While this YUV data is inherently scaled to Studio Swing levels, there is no need to confine it within an 8-bit video mode. A modern 32-bit editor will decode it into a high-precision floating point RGB format where the subsampled U and V channels can be blended smoothly into the full-resolution Y channel. In doing so, it will use the video file's Full Range Flag to determine whether the data should be scaled back to Studio Swing or Full Range levels. The RGB pixels are thus reconstructed without ever passing through an 8-bit stage of processing, and the quaint notion of "16-235" levels is moot in a 32-bit context. It is only necessary to impose 8-bit restrictions at the point when a composited video project is exported into an external 8-bit encoded format.

 

[jcs]

Coming from a computer graphics / video game / image processing background, I always use YUV when describing a luma + chroma color model. http://en.wikipedia.org/wiki/YUV
The difference between the flavors of YUV are the chroma differences for UV and the matrix coefficients.

For embedded system performance reasons, I would expect the 12-bit values to be quantized to 8-bit either just before or just after the DCT and matrix quantization. If using 16-235 (or any other range limiting), it would make sense to have that math effectively performed before (or part of) DCT (matrix) quantization so as to get more zeroes after quantization. More zeroes means more elements to throw away and better compression. If one is seeing under 100Mbps 4K recorded bitrates, there won't likely be any benefit for compression if using 16-235. My understanding of the range limited option is it's only useful when dealing with production pipelines which need that range right out of the camera. Otherwise, full range is the better choice, where only 16-235 is used after final grading and rendering for distribution (for systems which don't properly handle the Full Range flag).

 

[Lpowell]

For embedded system performance reasons, I would expect the 12-bit values to be quantized to 8-bit either just before or just after the DCT and matrix quantization. If using 16-235 (or any other range limiting), it would make sense to have that math effectively performed before (or part of) DCT (matrix) quantization so as to get more zeroes after quantization. More zeroes means more elements to throw away and better compression.

In the RGB->YUV conversion stages before the video is encoded into H.264, the processor and RAM work efficiently with 16-bit or 32-bit data. Within an H.264 encoder, optimizing the most efficient DCT format often depends on whether hardware acceleration is available for motion compensation calculations. With the GH2 and earlier Lumix cameras, the encoder was implemented entirely in software, and many H.264 encoding features had to be curtailed due to real-time performance issues. The GH3 and GH4 use proprietary hardware-assisted encoders, and Panasonic have not disclosed details of their internal data formats. I'd agree that 8-bit quantization is most likely done in the DCT matrix quantization stage, rather than earlier in the YUV processing stages.

 

[c3hammer]

Thanks for the reply's fellas !!!

I'm still not convinced how or when along the line the GH4 is getting from 12 bit to 8 bit. My probable mistake and assumption all along is that the GH4 has been doing strict BT.709 RGB to Y'CbCr calculations which are in full range 8 bit 0-255 values before the encoding. Lpowel=not so much jcs=that would be wise

Lpowell, do you have any links to where some of that might be laid out? Did you know if Vitaliy ever publish or describes the exact work flow of any of the GH cams? Just curious to see more clearly how these things are working.

On a side note, I don't have single piece of software on my PC the scales 0-255 to 'studio swing' other than quicktime. VLC, Media Player Classic, Mirillis Splash, Windows Media Player and all versions of Vegas all display full range by default. Apple and Adobe are the only ones who 'inherantly' scale that I'm aware of.

Cheers,
Pete

 

[Lpowell]

Did you know if Vitaliy ever publish or describes the exact work flow of any of the GH cams?

To my knowledge, neither Panasonic nor Vitaliy have published documentation on the internal processing workflow in GH cameras. For more background on how DSLR's process RAW sensor data, here are links to ROS.ORG's Image Pipeline firmware package, in particular, the video tutorial on "The Monocular Image Pipeline":

http://wiki.ros.org/image_pipeline?distro=hydro
http://wiki.ros.org/image_pipeline/Tutorials

I don't have single piece of software on my PC the scales 0-255 to 'studio swing' other than quicktime. VLC, Media Player Classic, Mirillis Splash, Windows Media Player and all versions of Vegas all display full range by default. Apple and Adobe are the only ones who 'inherantly' scale that I'm aware of.

Quicktime is notorious for its history of gamma conversion pitfalls, which are often conflated with 16-235 range issues. This is a thorny topic of its own, that both Mac and PC video editors should be aware of:

http://provideocoalition.com/cmg_keyframes/story/brightness_issues_with_h264_quicktime_movies

Adobe Premiere, however, does not "scale 0-255 to studio swing". It recognizes the Full Range Flag in the video file, and uses that info to appropriately scale each imported video file individually. As a result, Premiere's IRE charts do not indicate the scaling of the project's timeline, they are calibrated to the IRE scaling of each individual clip. The timeline itself works in 32-bit floating point mode, both compatible and independent of the color spaces found in the imported video clips. This allows you to transparently mix and match clips from different cameras without having to manually deal with color space conversions.