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

And with thousands of 4-pixel clusters across the area of the sensor, the aggregated statistical measurement error is close to zero.

I dare doubt this assumption. If you want to go the statistics or dice way, that's just a different story. Let me try to explain.

If quantity is what matters to you, then you can completely ignore how many bits your data is in the first place.
If you need to have thousands of pixels to get rid of any error, then that would apply to 8 bit values as well. You'd better stick to your higher resolution, then, to which those values apply.

Now this dice story doesn't apply at all. You want 10-bit values and those have a range 4 times of 8-bit values by definition.
Adding numbers on dices results in totally different ranges by definition. You just can't compare those.
And if you do, just stick to the correct units: you are only adding 4 values to get 1 sum. A quantity of 4 isn't that strong if you want to apply statistics. You just get 4 times the original error.

Even if you want to argue that errors "cancel out" over big quantities, that doesn't mean they do for real values. It's statistics. It's about anonymous numbers.

Statistics say the likelihood of throwing any number with a dice, is equal to that of any other number. It's an equal distribution.
Your expectations or best bet would be to count on that, but if you throw a dice 6 times and the number 6 doesn't show up once, it's not a problem at all.
If you throw that dice 600 times and 6 doesn't show up, you might suspect something is wrong, but you have no proof. It's a perfectly valid outcome.

Nature's disasters are acknowledged likelihoods in the same way, just because of the fact that they were observed in certain numbers.
But you can't count on them. You could also apply counterlogic: if something has happened, then the likelihood it happens again is lowest.
This may apply for plane hyjacking just after 9/11 but that's only because people act (decide) upon that, by increasing safety regulations.

But if there were to be a flood last year and you only expect them once every century, who are you to blame if it happens again next year?
Are you going to state that it is impossible?
 
So..um..how bout them Yankees? ...wait...I don't follow Baseball (rats). So...how bout those Kardasians?? Wait...they were yesterday's news. Um...Wassup with that weather??? Yeah... The weather. :)
 

How can those messages be answers to a question I asked later?

You still gave me no sufficient explanation that allows treating 4 summed 8-bit values as a valid single 10-bit value with 10-bit precision.
 
This is getting a little odd.

Why don't you try it instead of thinking about a picture as math. Take HD footage, convert it to SD and see if you gain any color precision. It really amazes me that people don't think of trying this with footage they already have access to. Has anybody ever heard of turning 8bit HD into 10bit SD footage? If this is such a perfect method why hasn't it been done in the past?

the HD to 4k transition is really no different than the SD to HD transition. Same arguments, same hopes and dreams and the same realization in the end that we just have more of the same.

I used to convert 8bit HD footage to SD to enhance the quality and deliver superior SD material. I could get 4:4:4 but was never really able to get true 10bit. At the time I was using AVIsynth with some rather intense image processing formulas. Tried a lot of methods including adding a bit of noise to dither the color but only helped a bit. Banding is damage just like other forms of image compression. You can do some tricks to reduce that but it will never really be the same again. I think in the end the only thing that made the color space look better was the fact that it was now 1/4 the size and therefore the areas of visible banding were made smaller. So banding that was 2 pixels wide was eliminated and so forth. The wider areas of banding still were wide strips of banding in the image.

Honestly is 10bit even enough for 4k? Back in the day the professional standard for SD was 10bit because it had more color samples than the resolution of the image. You could push it a lot and still have a full amount of color samples to span 720 pixels. If 10bit has 1024 samples and 4k has 4096 pixels across it is already dealing with limited color space.
 
Hehe... basically if everything in real life was dithered this theory would work really well.

Here is my ASCII take on it...

The image would be a very, very, dark, diagonal gradient going from top left to bottom right.

10-bit 4K image - 8-bit 4K image
45 44 43 42 41 40 39 38 - 44 44 40 40 40 40 36 36
44 43 42 41 40 39 38 37 - 44 40 40 40 40 36 36 36
43 42 41 40 39 38 37 36 - 40 40 40 40 36 36 36 36
42 41 40 39 38 37 36 35 - 40 40 40 36 36 36 36 32
41 40 39 38 37 36 35 34 - 40 40 36 36 36 36 32 32
40 39 38 37 36 35 34 33 - 40 36 36 36 36 32 32 32
39 38 37 36 35 34 33 32 - 36 36 36 36 32 32 32 32
38 37 36 35 34 33 32 31 - 36 36 36 32 32 32 32 28

10-bit 2K image - 10-bit 2K image from 8-bit 4K data
44 42 40 38 - 43 40 39 36
42 40 38 36 - 40 39 36 35
40 38 36 34 - 39 36 35 32
38 36 34 32 - 36 35 32 31

Using my very simple downscaling algorithm (average of four points) you can see that the downconversion gives really smooth edges on your banding :)

The 8-bit recording cannot capture the smooth gradients because everything is rounded off to the nearest bit while you are capturing it.

The increase in "bits" only works if the group of bits captured includes values higher and lower than the value you want to approximate which a smooth gradient will never do. Let's not forget that the original image is only 422 and has noise...

It doesn't matter what scaling algorithm you use, the data just isn't there.

DISCLAIMER: If the GH4 has some incredible dithering algorithm that uses the 12-bit(?) raw sensor data to create perfectly dithered 8-bit files then it could work, but I'm going to assume it doesn't, just because

Basically this reply answered the question perfectly
from my basic understanding, from the four pixels on the 8bit 4K frame which will be used to make the one pixel on the 1080 frame, you are still limited to the 256 levels. Even though the four pixels might contain slightly different shades of a colour, you are still limited to a selection of 256 on each. So adding them together, you don't get 1024 but still 256.

p.s. I should have checked the date on this thread. Sorry. It was an interesting read regardless. I studied Electrical Engineering (quite some time ago) but I never worked as an Engineer after graduating. I had a little trouble with the rain collection analogy but perhaps that is just old age kicking in
 
Last edited:
Using my very simple downscaling algorithm (average of four points) you can see that the downconversion gives really smooth edges on your banding :)

The 8-bit recording cannot capture the smooth gradients because everything is rounded off to the nearest bit while you are capturing it.

The increase in "bits" only works if the group of bits captured includes values higher and lower than the value you want to approximate which a smooth gradient will never do. Let's not forget that the original image is only 422 and has noise...

It doesn't matter what scaling algorithm you use, the data just isn't there.
Sorry, but you failed this particular DSP quiz. The correct algorithm does not average the 2x2 array of four pixels, it simply adds them together. The sum of four 8-bit quantities is a 10-bit result, with no loss of precision. (To be explicit, each 8-bit pixel ranges from 0-255. When you add four of them together, the sum ranges from 0-1020, a 10-bit result.)
 
LOL, I know binary arithmetic, Six of one is 00000110 of the other, I upconverted the 8-bit numbers to their 10-bit equivalents and used those numbers.
(4a+4b+4c+4d)/4 = a+b+c+d
You can see my "downscaled" results have a 10-bit "precision".

I think our disagreement is based on one key assumption which neither of us really know the answer to.
Let's imagine a frame composed of almost pure white represented by the 10-bit value 1019

I think your assumption is as follows:
8-bit = 10-bit sum
255 255 255 255
255 254 255 254 = 1019 1019

Which is completely true if the camera is smart enough to dither the image to represent the color 1019

I assume that it does not dither the color with that level of precision
8-bit = 10-bit sum
255 255 255 255
255 255 255 255 = 1020 1020

I could add a million of these numbers together and it would still be the same 8-bit number.
So it is not a question of the maths, it is a question of what the 8-bit 4K image actually is.

If the 8-bit 4K image is a dithered representation of a higher bit depth image then your theory holds true. If it is simply a 8-bit image recorded without dithering your theory is not true.

If you have a GH4 handy you could film something like the sky and pixel peep the values to see what sort of dithering it does.

I would like to keep this disagreement intellectual, so even if you disagree with me I would like you to try and understand why I have made the assumption that I have. My assumption is that DITHERING is the key to whether your theory is correct or not.



EDIT:
Another DVXuser user wrote an interesting article on this topic with nicer pictures than my ASCII ones. Unfortunately it doesn't address our point of contention

So I got some free time and wrote a short bit on the topic of tonal precision gain with downscaling: Shooting 4K Video for 2K Delivery: the Bit Depth Advantage
 
Last edited:
Let's imagine a frame composed of almost pure white represented by the 10-bit value 1019

I think your assumption is as follows:
8-bit = 10-bit sum
255 255 255 255
255 254 255 254 = 1019 1019

Which is completely true if the camera is smart enough to dither the image to represent the color 1019.
The camera doesn't "dither", it quantizes the sensor's analog photon counts to 12-bit precision. In video mode, the RAW sensel data is then debayered and processed through the selected tone curve and converted to YUV format. The H.264 encoder transforms the luma and chroma pixel data separately into 8-bit macroblock spatial frequency components and uses lossy compression techniques to compact the data within the available bitrate.

When the H.264 macroblocks are decoded back into YUV format, the luma data is converted into monochrome pixels scaled to an 8-bit, 0-255 range (assuming you chose the 0-255 option on the GH4). The decoder does not use pseudo-random dithering to produce pixels, it instead uses a built-in Deblocking Filter to smooth off macroblock artifacts. If you performed the 4K->1080p downscaling at this point, you'd find arrays of 8-bit pixels with values covering the full 0-255 8-bit range.

EDIT: jcs, are you seriously referencing EOSHD to back up your dithering claims?
 
Last edited:
Compression, noise and everything else are just red herrings. Everything you have said is correct but there is one big concept we are at odds over.
The decoder does not use pseudo-random dithering to produce pixels
This is where the misunderstanding is happening. There should be absolutely nothing random about the dithering. I'm talking about adding dithering during the conversion from 12-bit to 8-bit to simulate intermediate tones. Pure pixel-for-pixel quantization to 8-bits won't give a good approximation of higher bit depth tonality.

The DSP has a choice to make, resolution or tonality. You can't have both. Unless an adjacent pixel has enough of a tonal difference to be quantized to the next 8-bit level it will be represented by the same 8-bit value. This is a really big problem for this theory. My personal opinion is that the DSP does not add dithering to the recorded image.

Did you follow my example about tone value "1019"? There is no way to represent that tone using 8-bit quantization.
This is why I think dithering is the only way to increase tonality on subtle gradients.

I wish we could discuss this in person... it would be fun
 
Last edited:
The camera doesn't "dither", it quantizes the sensor's analog photon counts to 12-bit precision. jcs, are you seriously referencing EOSHD to back up your dithering claims?
The link I shared is for a post I wrote, along with example images I created showing how simple noise removes banding (as well as discussing dither, Mach banding and 8/10-bit displays). His later blog post regarding GH4 dither/noise is based on my post and examples in the link above.
 
I think you guys are overfocusing on the dither thing.
While dithering is a very good way to handle gradients on downsampling and in general adding grain is a common way to cover issues - banding, lack of sharpness, etc - you don't necessarily need it, and you will generally get original noise in the image anyway (and, hopefully, detail), so that there will be some inherent variation in source pixels. Add to that the significantly big number of samples ( >> 4) per output pixel in a real-world scaling application and things look even better.

Also, even if you ignore the precision thing you do gain chroma samples: no subsampling/4:4:4 from both 4:2:0 and 4:2:2 sources. Even that alone is significant.
 
It's like watching people use a micrometer while riding a roller coaster... my DSP and statistics professors must be rolling in their graves

P.S. not you cpc
 
Last edited:
I'm talking about adding dithering during the conversion from 12-bit to 8-bit to simulate intermediate tones. Pure pixel-for-pixel quantization to 8-bits won't give a good approximation of higher bit depth tonality.

The DSP has a choice to make, resolution or tonality. You can't have both. Unless an adjacent pixel has enough of a tonal difference to be quantized to the next 8-bit level it will be represented by the same 8-bit value.
The DSP unit in the GH4 has no need to convert its 12-bit RGBG sensor levels into 8-bit precision, dithered or otherwise. Its debayering, tone curve processing, and YUV subsampling are no doubt done at signed 16-bit precision (or 32-bit, when convenient). The YUV data is then transformed by the H.264 encoder into 8-bit macroblock spatial frequency components and quantized to fit within the available bitrate. At no point is there a need to "dither" any pixel values, RGB, YUV, or otherwise.
 
Well, my eyes glazed over a few pages back. But here's my question about Gh4 4k footage, in regards to keying for a 1080 delivery:

Would the best practice be (A) to pull your key and do all of your compositing at 4K?

Or (B) pull your key, downsample footage + key to 1080 and composite at 1080 (which would give you the benefit of not needing 4K source material for your backgrounds, plates, 3d renders, etc.)...

Or (C) downsample to 1080 to get beyond 422 (I've read plenty of arguments bout whether you'd get true 444 or not), pull your key then, and composite?

My gut tells me A is overkill, and you would be hard pressed to tell the difference between B and C in the final.

My primary interest in 4K is keying. But I'd much rather be doing color on prores or raw files. Just darkening a sky with even the best 8 bit DSLR footage is a disaster... so I guess I need 4K raw or 422 Prores in my perfect world...
 
...here's my question about Gh4 4k footage, in regards to keying for a 1080 delivery:

Would the best practice be (A) to pull your key and do all of your compositing at 4K?

Or (B) pull your key, downsample footage + key to 1080 and composite at 1080 (which would give you the benefit of not needing 4K source material for your backgrounds, plates, 3d renders, etc.)...
For keying, you'll want to decode into a 32-bit editor at 4K resolution. If you downsample the footage to 1080p, edge details will be blended with your background, producing small gradients in the borderline between foreground and background objects. It's also best to key on the original footage, before converting to Prores or any other format.
 
I can't tell you what is best, but I have been getting great results dropping my 4K footage into a 1080 timeline and keying there. I'm really looking forward to using the Shogun.
 
Back
Top