Exclusive: here is the first app to resample Panasonic GH4 4K 8bit to 10bit 4:4:4

[Thomas Worth]

Just tried it and works to output the DPX, the files look superb. I opened frames in Premiere, which does not treat it like a clip, but the frames grade superbly and look amazing.

 

However Resolve 10.1 gives me flickering playback with some frames shifted, some half black, to a random degree. Anyone else had success with Resolve yet?

 

So the frames play back in Premiere, but Resolve has trouble? Can you check the frames that are half black in Photoshop or some other program to confirm they're ok?

[clump]

I'm with the chorus of sceptics calling bull on 10-bit recovery from an 8-bit quantized source. Basically, all this downsampling 8-to-10 bit business will accomplish is reduce any banding / blocking in the image by a factor of 2.

 

Think about the original logic -- if you record video at 43444x24437 in 1 bit (i.e. each pixel has a value of either zero or one), then the claim is that with sufficient downsampling you'd end up with an image that is 1920x1080 in 10-bits, and everything would be hunky-dory. Do you expect this situation to allow even a modicum of grading? Say the camera records a light source that is a horizontal gradient. The 1-bit image that we get would be basically a bunch of zeroes followed by a bunch of ones (or vice versa). There is absolutely no way you can grade this no matter how much you downsample it (well, maybe if you go down to a width of 2 pixels).

 

When an analog source is quanitzed some information will be lost, and I don't see what we can do to recover any part of the missing data.

Edit: Small correction in downsampling numbers.

[jcs]

If grading in a 32-bit float app as with most modern NLEs, the 8-bit integer source will be converted to 32-bit float- it won't really matter if you edit in a 4k sequence or 1080p sequence: nothing magical will happen regarding grading latitude if downsampling first other than perhaps higher performance.

[alexcosy]

After reading most of this thread, one of the conclusion can be that the headline to this post is very misleading!
The developper himself tells us that you get 10bit in the luma channel only! Which is nice.
But never does he mention full 10bit 4:4:4...

[Thomas Worth]

After reading most of this thread, one of the conclusion can be that the headline to this post is very misleading!
The developper himself tells us that you get 10bit in the luma channel only! Which is nice.
But never does he mention full 10bit 4:4:4...

 

The DPX files written are most certainly 10 bit 4:4:4. As you mentioned, the luma channel has "real" 10 bit data which contributes to all three RGB color channels when combined with the chroma information via matrix math.

[see ya]

The GH4 files are flagged Rec. 709, which implies broadcast range levels. I use the Rec. 709 matrix in gh444, which seems to be correct so this all looks like good intel. However, I've seen cameras that output full range even though they're flagged broadcast range. As you mentioned, QuickTime clips the data which is why 5DtoRGB is a good tool to recover the lost highlight detail.

 

FFmpeg's H.264 decoder doesn't care about levels/ranges. It just outputs whatever is in the file. It's up to the programmer to make sense of that depending on what type of file they're writing. In this case, it's uncompressed 10 bit RGB (full range) so I leave the levels alone. That said, nothing is getting clipped with DPX, obviously.

 

Yeah, I understand the difference in handling between QT & FFmpeg/libav it's why I asked which you were using. When I decompress a native GH4 h264 file I see full range levels, well above 235 as it's a CineD lifted blacks type of profile used so shadows didn't go below 16, so then it's a case of is the mov container flagged 'fullrange' in the VUI options as QT decompresses the same native file and shows no full range levels, in fact I've never been able to get 4:2:0 planar out of QT it's always been 4:2:2 interleaved but I'm sure you could clarify that anyway I'm no programmer.

 

So taking the fullrange flag off the source appears to show full levels, therefore if flagged like the GH3 mov's then rather than a typical broadcast file we have a jpeg levels encoded file, luma and chroma normalised over full range like a jpg image.

 

But anything out of QT will have had those jpeg levels scaled into broadcast range 709 it would appear. I was just wondering with all the talk of 8bit 4:2:0, which doesn't actually use 8bits worth of levels range has any impact on calculations to 10bit assuming 8bit?

 

QT only clips full range levels if they are not flagged fullrange otherwise it scales levels into broadcast and would appear at the moment to screw up chroma in the highs introducing a lot of noise in a very small range of higher levels. Can't remember it ever doing that before. Had you noticed anything? Best to check with a full and limited range encoding of the same file, adjusting the luma coeffs calculation to suit and using QT as the decompressor.

[see ya]

The DPX files written are most certainly 10 bit 4:4:4. As you mentioned, the luma channel has "real" 10 bit data which contributes to all three RGB color channels when combined with the chroma information via matrix math.

 

Just not 10bit 4:4:4 YCbCr as suggested now and previously. It is a bit misleading, it's also missleading to suggest no one has ever done it before, anyone using Matlab, Avisynth or even I'd guess a nodal compositor like Nuke may well have done the necessary math on 1080P to 480P 4:4:4 or RGB in the past, who knows, who really cares. And on any camera, doesn't have to be the GH4.

[Orangenz]

If grading in a 32-bit float app as with most modern NLEs, the 8-bit integer source will be converted to 32-bit float- it won't really matter if you edit in a 4k sequence or 1080p sequence: nothing magical will happen regarding grading latitude if downsampling first other than perhaps higher performance.

Of course there is better latitude in grading a 10 bit sky than a 8 bit sky. And you're creating a 2k master to edit then having the higher quality will absolutely give better delivery results. I get the point about the 32bit float but you do indeed have the possibility of just magnifying 8bit grading problems. But the question is, as always, how does it work in practise. If process A ends up looking betting than process B then A wins.

 

On something else. I love listening to Phillip Bloom but his comment at the end of that video bugs me. "It's not the camera it's how you use it," etc etc. That may have been the case back when the best cameras where $50k but you can get close enough to "the best" for under $2k now. "Get a good camera" is actually not a bad thing to say. I don't want to say to someone that yes there's great cameras out there but I want you to have a crap camera for 10 years so you can learn the ropes just like me. :/ That's annoying. You can learn with good equipment that doesn't cost a lot. Vegas studio, dr40, and a notable video camera is a great starting point. If you don't suggest something good they'll go for 720p mush from you-know-who. Nothing wrong with starting out with a GH4 either.

[mastroiani]

So, potentially same thing could be done with the A7s 4K footage that was recorded to an external 4K recorder?

[Thomas Worth]

Just not 10bit 4:4:4 YCbCr as suggested now and previously. It is a bit misleading, it's also missleading to suggest no one has ever done it before, anyone using Matlab, Avisynth or even I'd guess a nodal compositor like Nuke may well have done the necessary math on 1080P to 480P 4:4:4 or RGB in the past, who knows, who really cares. And on any camera, doesn't have to be the GH4.

 

It's not 10 bit YCbCr, and I've been careful not to mention that. Everyone knows you can't get 10 bit YCbCr from an 8 bit source even with a 1/4 downres (maybe an 1/8 downres, though). The claim is that the result is 10 bit 4:4:4, which it is. The DPX file wouldn't work otherwise. :) I think I've been clear that due to the limitations of the 4:2:0 color planes, only the luminance channel contains "true" 10 bit information. The color planes are 8 bit, and since there's only 1/4 the resolution in color (4:2:0), I can't sum the color planes and maintain the full resolution. There are still discrete chroma samples at 2K (so it's true RGB/4:4:4), albeit with a combination of 10 bit luma and 8 bit chroma. Keep in mind, however, that luma contributes to RGB, so all three color channels are being derived from a mix of 10 bit and 8 bit information. Green is almost all from luma, so the green channel is going to be almost all 10 bit.

 

Oh and as others have suggested, this app should work with other H.264/4:2:0 cameras just fine. If people find that it offers a real benefit, I'll consider adding a GUI and ProRes 4444 export. Or just maybe add the functionality to an existing product.

[sunyata]

It's also not the same as sampling the original light at 2k 10bit, even in the luminance (Y) channel... which is the real issue, not the fact that you're short a few samples in the chromatic channels. This is confusing a lot of people.

 

Someone should just do a test that shows banding in green (just use a ramp that goes from 0,1,0 to 0,10,0).. then resize with the app and compare to the same ramp made in 2k 10bit uncompressed. I'm not on a mac.

 

You will need a program that can save out a native 10bit dpx file like Nuke to generate the 2k 10bit ramp.. (not sure about AE).

 

People need visual proof to sort all this out I think.

[yiomo]

So, potentially same thing could be done with the A7s 4K footage that was recorded to an external 4K recorder?

+ 1  I am wondering the same thing...

[sunyata]

see what i mean

[Thomas Worth]

People need visual proof to sort all this out I think.

I completely agree. I wrote the app with the hope that others would test the theory. I'm anxious to see what happens.

[duch]

so it's true RGB/4:4:4

 

There is a confusion here. Y'CbCr 4:4:4 is NOT R'G'B' and you won't ever be able to get back to "true" R'G'B' (ie having every legal codeword representing a discrete color) once your signal went through the matrix transform that convert it to luma and a pair of colour differences, whatever you do. Transcoding to Y'CbCr (with or without chroma subsampling) means that 3/4 of the codewords won't represent a valid R'G'B' combination : you lose signal to noise ratio and won't get it back when transcoding to R'G'B' again. Using 8, 10 or one million bit per channel won't change the fact that you'll still ditch 3/4 of your possible colors when going through this matrix transform and won't get them back.

 

More complete explanations : http://www.poynton.com/papers/Discreet_Logic/index.html

 

Green is almost all from luma

 

Another confusion, luma is mostly (0.7152 coefficient for BT.709) computed from G' but that doesn't mean the inverse is true. As far as I understand the Y'CbCr to R'G'B' decoding matrix, it isn't.

 

Regarding the 8 to 10 bits stuff, what does your app exactly do Thomas ? Averaging the luma value of 2x2 blocks of pixels ?

[Thomas Worth]

There is a confusion here. Y'CbCr 4:4:4 is NOT R'G'B' and you won't ever be able to get back to "true" R'G'B' (ie having every legal codeword representing a discrete color) once your signal went through the matrix transform that convert it to luma and a pair of colour differences, whatever you do. Transcoding to Y'CbCr (with or without chroma subsampling) means that 3/4 of the codewords won't represent a valid R'G'B' combination : you lose signal to noise ratio and won't get it back when transcoding to R'G'B' again. Using 8, 10 or one million bit per channel won't change the fact that you'll still ditch 3/4 of your possible colors when going through this matrix transform and won't get them back.

 

What I meant by "true" RGB is that the RGB recovered through the matrix transform is based on discrete YCbCr samples at 1/4 res. In other words, there is one Y,Cb and Cr sample for each pixel prior to transforming (YCbCr 4:4:4). The RGB is recovered from these full res planes. You say I "won't ever be able to get back" true RGB, and this is correct since R,G, and B are mixed when matrix encoded. However, in the context of an H.264 4:2:0 camera the meaning should indicate that the limitations of subsampled color have been overcome.

 

 

Regarding the 8 to 10 bits stuff, what does your app exactly do Thomas ? Averaging the luma value of 2x2 blocks of pixels ?

 

It sums the 2x2 luma samples to a 10 bit value.

[see ya]

It's not 10 bit YCbCr, and I've been careful not to mention that. Everyone knows you can't get 10 bit YCbCr from an 8 bit source even with a 1/4 downres (maybe an 1/8 downres, though). The claim is that the result is 10 bit 4:4:4, which it is. The DPX file wouldn't work otherwise. :) I think I've been clear that due to the limitations of the 4:2:0 color planes, only the luminance channel contains "true" 10 bit information. The color planes are 8 bit, and since there's only 1/4 the resolution in color (4:2:0), I can't sum the color planes and maintain the full resolution. There are still discrete chroma samples at 2K (so it's true RGB/4:4:4), albeit with a combination of 10 bit luma and 8 bit chroma. Keep in mind, however, that luma contributes to RGB, so all three color channels are being derived from a mix of 10 bit and 8 bit information. Green is almost all from luma, so the green channel is going to be almost all 10 bit.

 

Oh and as others have suggested, this app should work with other H.264/4:2:0 cameras just fine. If people find that it offers a real benefit, I'll consider adding a GUI and ProRes 4444 export. Or just maybe add the functionality to an existing product.

 

Thanks for the clarification, many equate 4:4:4 to YCbCr not RGB. And the title of this thread and previous mislead.

 

Just to query, you say 8bit chroma planes but they are not full 8bit worth of levels (16 - 240) does this matter and chroma is the difference in terms of red & blue once the luma is extracted from the original RGB value at any given point, then mixed back in with interpolation to averaged luma values in the scaling down process and conversion to RGB? So is it even true 4:4:4 RGB full sample? Isn't the whole thing about using the bastardized term 4:4:4 RGB is to differentiate between RGB captured natively 'full sample' via a camera or film scanner from something like a 3CCD sensor, 1 for each of the color channels, to diffentiate from interpolated RGB from say 4:2:0 or 4:2:2 such as described in this thread?

 

And to say green is mostly from luma, depends on white balance and even the temperature of the light captured to determine which derives most luma, how does low light stand in conversion particularly with a codec like h264 which generally throws away data from low end of the luma range as part of the compression?

 

Interesting to see if there's any real benefit in doing this over just 4:4:4 upsampling by 32bit linear in the NLE or grading app at the point it's actually needed ie: grading rather than filling hard drives with 10bit dpx's in advance, assuming that's how it'll be used or cuts only, export 4:2:0 and then do the upsample before going to the grading process.

 

Had you seen the 8 to 10/16bit process using a modified denoiser to extract 8bit worth of LSB, keep the 8bit MSB and create 16bit per channel, then range convert to 10bit?

[Joseph Moore]

 

 

a combination of 10 bit luma and 8 bit chroma

This!

 

It seems like many people are getting hung-up on 8-bit vs. 10-bit, but to me the real plus of utilizing this method is that the oversampled 4k 4:2:0 data yields a 2k image that is 4:4:4. The bonus is that one of that the luminance channel happens to additionally increase to 10-bits of resolution.

[Andrew Reid]

Thanks for the clarification, many equate 4:4:4 to YCbCr not RGB. And the title of this thread and previous mislead.

 

Really? Misleading? Read the damn article Yellow.

[geppoitaly]

fantastic! but noone can try with a 4k fotage from hacked samsung note 3 ???, thank you