GH4 : Convert 4K 8bit to 1080p 10bit?

I've tried downconverting in an avid symphony to 1080p from a full 4k file, and it introduces significant aliasing. I'm hopeful that the Ultra HD 4k mode (as pixel dimensions divide exactly in half for 1080) might show a significant improvement in that regard. Going to try Resolve for a down convert and see how that works as well.
 
Thanks for everyone's input!

The math is beyond me so defer to your opinions.

Still I wish someone with access to the GH4 would shoot a simple gradient test & let the internet have at it. Love to see footage of a grey gradient, & another of blue. Never used an 8bit camera (including C300) that didn't band under these conditions.
 
Not sure if that's actually true. Remember, this is 4:2:0 chroma sampling we're talking about. That means that while luma may be 10-bit, chroma is still 8-bit - one chroma value every 4 pixels.
Yes, this flavor of 4K->1080p downscaling is based on the idea of working directly with the 4:2:0 YUV data encoded in the H.264 file. Since the UV chroma data is already subsampled at half the horizontal and vertical resolution as the Y luma data, the chroma data could be used directly as 1080p 4:4:4 UV data without resampling it. The luma macroblocks would be decoded into 8-bit monochromatic pixels. Each 2x2 block of 8-bit luma pixels would then be summed to produce a single 10-bit subsampled luma pixel. The major advantage is that the original precision of the data samples is preserved without averaging - the only thing that is downscaled is the spatial resolution of the image.

To make use of this technique, you'd need a custom decoder that works directly in YUV color space with the original 8-bit 4:2:0 H.264 video to produce the equivalent of a decoded 10-bit 4:4:4 H.264 video. While the luma blocks would contain genuine 10-bit data, the chroma blocks would contain the original 8-bit values. In practice, this would look nearly indistinguishable from full 10-bit 4:4:4 video.
 
Last edited:
Yes, this flavor of 4K->1080p downscaling is based on the idea of working directly with the 4:2:0 YUV data encoded in the H.264 file.
There seems to be some controversy and varied opinion about the validity of this concept. I don't yet have an opinion. But I do have a question.
How would this technique differ from simply bringing an 8-bit 4:2:0 clip into a program that can color correct in a 32-bit color space? In other words, would the results be any better than bringing a 4k clip from the GH4 into a 1920x1080, 32-bit comp in After Effects?
 
Since Edius is designed to work in the YUV color space wouldn't decoding the GH4 3840x2160 video file with the Edius AVCHD decoder to 1920x1080 produce the desired results?
 
... Each 2x2 block of 8-bit luma pixels would then be summed to produce a single 10-bit subsampled luma pixel. The major advantage is that the original precision of the data samples is preserved without averaging...

This may not entirely be true. You can add 4 time 255 but you will never get 4 * 256 -1.
If data was preserved more accurately, you would get a real 10 bit value, but with 8 bits for individual values, always something is lost. If All would have x,3 then the total value would be 4 times x + 1,2. You'd lose the 0,2 of course, but you would have the extra 1. You lose that now.
 

Why only DPX files? Pro-res4444 is 10bit and has 444. This is a much more logical format for editors to use. Seems kind of like a silly venture since most NLE's out there today will be able to do the same thing. The one advantage he could have is by using his already pretty decent chroma up sampling methods he could bring the native 4:2:0 4k recording back to a interpolated 4k 4:4:4 before doing the down conversion. This could give 1024 unique chroma samples albeit from an interpolated source. Adobe may already be able to do this without any other special tools since it also up samples the chroma in certain formats and certain situations, color correcting and keying.
 
This may not entirely be true. You can add 4 time 255 but you will never get 4 * 256 -1.
If data was preserved more accurately, you would get a real 10 bit value, but with 8 bits for individual values, always something is lost. If All would have x,3 then the total value would be 4 times x + 1,2. You'd lose the 0,2 of course, but you would have the extra 1. You lose that now.
You're confusing dynamic range with bit-depth. The theoretical discrepancy you describe results in a loss of 0.3% at the bright end of the luma dynamic range, which is equivalent to clipping the highlights at 99.7 IRE instead of 100. In practice, neither the camera sensor nor the human eye can resolve such a minute difference in highlight intensity. Aside from this imperceptible discrepancy, with pixel summing the sensor's entire dynamic range is preserved intact at 10-bit resolution, all the way down to the noise floor in the darkest shadows. The reason there is no loss of data is because each 4-pixel sum is accumulated in a 10-bit register, but not averaged (i.e. it's not divided by 4). The result is an undegraded, downscaled 10-bit luma signal that ranges from 0 - 99.7 IRE.
 
Last edited:
In practice, neither the camera sensor nor the human eye can resolve such a minute difference in highlight intensity.

If that would be true, then what's the point in converting to 10-bit (at all)?

What I mean to say is this: if your source is a 8-bit value, it has an 8-bit error in it and if you combine 4 of those, the error (measurement value) will be 4 times as well.
So you may think you get more precise numbers in a 10-bit scale, but in fact this may be only because of errors in them.
Anyway, you won't get a fully 10-bit value at all, because there are at least 3 values that you will never get.

http://en.wikipedia.org/wiki/Accuracy_and_precision
 
Are you just trolling us or what? If it's all ruined for you because the 10-bit summed pixel values only go up to 1020 instead of 1023, you'll probably go ballistic over this:

No, of course I am not trolling. I am only doing math. It's not only those 3 pixels lost on the high end, it is the distribution of "lags" all over the entire range.
To me, it has no use "claiming" you get a 10-bit value, when you can't tell if the extra bits contain real detailed data or just error information.

If you want to take out the error component, you will have to average the data. You then get a more realistic 8-bit value, which may or may not differ from any 8-bit value acquired in another way.
 
If you want to take out the error component, you will have to average the data. You then get a more realistic 8-bit value, which may or may not differ from any 8-bit value acquired in another way.
The 8-bit luma values are produced by debayering and binning the sensor's 12-bit sensels into a 4K array of pixels. The results are then quantized into 8-bit H.264 macroblocks at 4K resolution. Since the 8-bit round-off errors you're referring to are distributed in a numerically even manner, they statistically cancel out whenever pixels are combined to produce a lower resolution version of each frame. That's why their 8-bit precision is not degraded by subsampling.

What you don't seem to understand is where the extra 2 bits of precision comes from in the summed 10-bit subsampled pixels. It's not in the least significant bits - their statistical precision is neither degraded nor improved. Where you get an additional 2 bits is in the most significant bits, which now range up to 1020 rather than 255. That, by definition is a 10-bit result, subsampled from 4K down to 1080p, with no loss of precision in the numerical results.
 
What you don't seem to understand is where the extra 2 bits of precision comes from in the summed 10-bit subsampled pixels. It's not in the least significant bits - their statistical precision is neither degraded nor improved. Where you get an additional 2 bits is in the most significant bits, which now range up to 1020 rather than 255. That, by definition is a 10-bit result, subsampled from 4K down to 1080p, with no loss of precision in the numerical results.

It may be just me, but I can't find the logic in this.
As far as I understand, it is similar to this:

You take 10 numbers ranging from 0-9999 ("12 bit"). You reduce this to 10 numbers ranging from 0-99 ("8 bit").
Now you take 10 of those to form one number ranging from 0-999 ("10 bit"), you think. (You take 10 because these digits are not bits.)

But because those numbers are rounded or truncated to integer values, you will never get the values 991 to 999. It's obvious you lose precision here.
But the same goes for all those values that are in the range 0-999. You add 10 of them, but if you originally had 10 values of 2345, the result will be 230 and not 234 or 235 which you might expect.

If you would have used the original values to "downscale" without "upscaling" you would have had 234 or 235, depending on rounding.
But you don't. You only got 230 because you definitely lost that 1 digit and you can't get it back.
 
IMHO, if you are really that concerned about 10 bit, and or high quality 4K from the GH4, then you have the option of adding something along the lines of the Atomos Shogun to satisfy clients needs.
 
You take 10 numbers ranging from 0-9999 ("12 bit"). You reduce this to 10 numbers ranging from 0-99 ("8 bit"). Now you take 10 of those to form one number ranging from 0-999 ("10 bit"), you think. (You take 10 because these digits are not bits.)

But because those numbers are rounded or truncated to integer values, you will never get the values 991 to 999. It's obvious you lose precision here.
No, it's not numerical precision that is lost, it's only the top 1% of your numerical range that is lost (9 values out of 1000). As I explained earlier, that's like clipping your output to 99 IRE rather than 100, a virtually imperceptible difference.

But the same goes for all those values that are in the range 0-999. You add 10 of them, but if you originally had 10 values of 2345, the result will be 230 and not 234 or 235 which you might expect.
That's true only when all ten original pixels contain precisely the same numerical value. In real life, due to minute variations in light dispersion and sensor noise, a cluster of photosites will only rarely produce identical readings. When you sum them all together, those variations are combined without loss in precision, which effectively filters out the high-resolution noise just as a single large photosite would have done.
 
Lee, what tool would you choose at this moment to convert the GH4 4k to 1080 prores HQ. We're in production and cranking out footage.

Mpeg streamclip does a nice job from 4k to 1080 in our tests so far.
 
Back
Top