Jump to content

Discovery: 4K 8bit 4:2:0 on the Panasonic GH4 converts to 1080p 10bit 4:4:4


Andrew Reid
 Share

Recommended Posts

Another way to see it, if you only have photografic background, is to compare it with enlarging (it's somehow similar). Let's say you have a good enlarger and a bad enlarger and are trying to make a good black and white. Enlargers are not digital, so with the bad enlarger lens you get some kind of interpolation but you won't reach certain tonalities of the grain that you will reach with the good enlarger.

Link to comment
Share on other sites

EOSHD Pro Color 5 for Sony cameras EOSHD Z LOG for Nikon CamerasEOSHD C-LOG and Film Profiles for All Canon DSLRs

Think about how bracketing, or HDR, works in photography.  You take 3 images at different exposures.  Software then uses any large patches of detail-less pixels to be replaced by pixels with detail.  It is essentially USES the 8bit truncated data to tell the computer that it has to try to get other data that was truncated higher or lower.  It looks in the images under or over-exposed.  

 

With a RAW image, you can do close to the same thing in photoshop by selecting detail-less pixels and then using the RAW data to bring out detail (from the 14bit per channel data), to essentially move the center exposure point of those pixels only.  

 

A way the GH4 could potentially use its resolution in a way that would approach RAW is to take multiple frames and then HDR them.  That is, if the GH4 exposed 1920x1080 pixels in one exposure a bit above, and another, a bit below, THEN the downsampling could use the extra range to bulid a more detailed image.  

 

People at Magic Lantern have discussed such ideas and do it in a limited way, though I don't follow it.  Perhaps someone reading this can explain more about that technique.

Link to comment
Share on other sites

At first I was very excited, but thinking this over I don't really see how 8bit would turn into 10bit. 4:2:0 to 4:4:4 is definitely right (and I'm wondering if there are any DNxHD flavors to save that info) but one thing is to change the color sampling by downrezzing, and another to increase the color palette by doing this.

I guess some testing needs to be done. Probably 4K footage from the 1DC would be a good subject?

Link to comment
Share on other sites

This really is NOT the same as "truncating" to 8 bit and then re-inventing data to get 10 bit.    More data really is there to begin with!

 

David lays the math out neatly:   4,  8-bit values combine to make one 10 bit.  Easy math isn't it?      (256+256+256+256=1024).  In other words you have 4 pixels each with a value between 0 and 255, which gives you 1024 possible combined values.

 

I asked David Newman the same general question about downsampling earlier in the week and got this reply:

 

"Very nicely, overkill even. 4:2:0 maps to an effective 4:4:4 with root-2 the image size. So 2.7k 4:2:0, is a nice 1920x1080 4:4:4 -- notice 2.7K is one of GoPro video modes partly for this reason."

 

For those who don't know, David Newman is not just "some software guy from Gopro" -  He invented the Cineform Codec and is clearly technically/mathematically gifted.

 

I don't think the workflow needs to be complicated either.  Set up your NLE with cineform codec installed (free from GOPRO) and then render an intermediate file with the correct resolution/luminance bits/colour sampling specified in the codec dialogue box.

 

Looks to be a really good camera!

Link to comment
Share on other sites

Agree. I get the feeling people confuse this with something like a 8-bit gif picture where they could have 256 colors, stored in a palette and that is all each pixel could pick from.

 

While this is not my area of expertise, I will say that I have seen examples ranging from video-compression to disk storage algorithms that give mind-blowing results, and few normal people would understand how it could even be possible.

 

If someone like David Newman is confirming this is real, I don't see any reason to doubt it.

This really is NOT the same as "truncating" to 8 bit and then re-inventing data to get 10 bit.    More data really is there to begin with!

 

David lays the math out neatly:   4,  8-bit values combine to make one 10 bit.  Easy math isn't it?      (256+256+256+256=1024).  In other words you have 4 pixels each with a value between 0 and 255, which gives you 1024 possible combined values.

 

I asked David Newman the same general question about downsampling earlier in the week and got this reply:

 

"Very nicely, overkill even. 4:2:0 maps to an effective 4:4:4 with root-2 the image size. So 2.7k 4:2:0, is a nice 1920x1080 4:4:4 -- notice 2.7K is one of GoPro video modes partly for this reason."

 

For those who don't know, David Newman is not just "some software guy from Gopro" -  He invented the Cineform Codec and is clearly technically/mathematically gifted.

 

I don't think the workflow needs to be complicated either.  Set up your NLE with cineform codec installed (free from GOPRO) and then render an intermediate file with the correct resolution/luminance bits/colour sampling specified in the codec dialogue box.

 

Looks to be a really good camera!

Link to comment
Share on other sites

Minor comments, its quite easy and its been done many times before over the years to use a tool like Avisynth and create 4:4:4 from 4:2:0 by scaling luma and chroma individually without having to go to RGB first and without the need for Cineform and AE.

The output from the Cineform process does not appear to be 4:4:4 YCC but 4:4:4 RGB. Technically they are not the same.

I know EOSHD write up about YCC is for illustration but the chroma difference is almost certainly left of rather than cosited as the diagram and the codec used by the Panny, the write up says is RGB, but it won't be.

Minor nit picking but just see this "4:2:0 as 4:4:4 major discovery" as a bit off, to suggest 4:2:0 intetpolated and averaged 4k 4:2:0 to 1080p is going to give equivilant to 4:4:4 1080p shot in camera. However it will be interesting to see the results comparing Cineform route and straight forward Avisynth rescale luma route.

Link to comment
Share on other sites

I found out a similar thing for the Canon via C100/C300. It seems like there is coming out a "smoothed out" version of 8-bit out of these cameras and when recorded with a Ninja2 with ProRes or DNxHD 220x in 10-bit it makes a difference to the just pure 8-bit codec of the C100/C300.
http://ntown.at/blog/2014/02/05/canon-c100-ninja2-10-bit-workflow/

 

- Patrick.

 

Link to comment
Share on other sites

This really is NOT the same as "truncating" to 8 bit and then re-inventing data to get 10 bit.    More data really is there to begin with!

 

David lays the math out neatly:   4,  8-bit values combine to make one 10 bit.  Easy math isn't it?      (256+256+256+256=1024).  In other words you have 4 pixels each with a value between 0 and 255, which gives you 1024 possible combined values.

 

I asked David Newman the same general question about downsampling earlier in the week and got this reply:

 

"Very nicely, overkill even. 4:2:0 maps to an effective 4:4:4 with root-2 the image size. So 2.7k 4:2:0, is a nice 1920x1080 4:4:4 -- notice 2.7K is one of GoPro video modes partly for this reason."

 

 

Ok, on 4k 4:2:0 to 1080p downscale, we get 4:4:4. because at 4x oversampling with 4:2:0 we just manage to get 1 chroma per color channel sample per pixel when we downscale. Everyone seems to agree on this.

 

I get the 4 8 bit -> 1 10 bit part, and agree with it, but once again this is only for luminance, because this is the only channel we actually have oversampled data for! The whole 8 bit to 10 bit thing only works if you have genuinely oversampled data. As per above, we only have one 8 bit chroma sample per pixel per channel after the downscaling. Thus not possible to do any neat math, from a pure mathematics perspective. Thus, yes 4:4:4, no not proper 10 bit.

 

Where it gets murky for me is this root 2 of the image size scaling factor that Mr. Newman has stated. Either he is talking 4:2:0 to 4:2:2 instead of 4:4:4, or there is some other fancy stuff going on based on human perception and not basic math. In any case, still not going to get proper 10 bit chroma at 1080p out of 8 bit 2.7k footage.

Link to comment
Share on other sites

My understanding is that the downsampling can yield 10 bit Luma, because there are 4 8 bit Luma samples getting combined into one, not full 10 bit color sampling. Anyone else get that?

 

4k 8:2:2

Luma : 10bits ( 256+256+256+256 = 1024 possibilities)

Chroma : 9bits (256+256 = 512 possibilities)

 

4k 8:2:0

Luma : 10bits ( 256+256+256+256 = 1024 possibilities)

Chroma : 8bits (256 possibilities)

 

 

let's make this even simpler, and use a dynamic range to show why you can't always resurrect higher bit depth (even with error diffusion):

 

Assume there are two types of A/D conversion:

 

1 bit (taking on the value of 0 or 1) 2 choices 

2 bit (taking on the values of 0 1 2 3) 

 

Let's assume that analog values are:

 

(0.1) (1.2) (2.0) (2.1) (3.0) (4.1)

 

and that A/D conversion assigns the closes possible digital value. 

 

1 bit A/D conversion becomes:

 

(0) (1) (1) (1) (1) (1)

 

2 bit A/D conversion becomes

 

(0) (1) (2) (2) (3) (3)

 

at half resolution you get either:

 

(0) (2) (3) or (1) (2) (3)

 

either one represents 3 levels of light , which you cannot represent in just 1 bit. 

 

Is this a contrived example, yes. But the point is to try and show they are not mathematically equivalent. 

 

Your A/D conversion is not right. You are mixing dynamic range and encoding.

 

If you have a 12 stops DR sensor (let's use a regular single amp sensor - not a dual amp one like on BMCC/Arri), you will get a 12bit linear signal : on each stop you double your value = on each bit you double your value.

 

However, when there is encoding (not RAW), your signal is processed. When it is converted to 10 or 8 bit, the signal is first converted to log (eg. 2.2) so your 6th stop is not anymore the value 64 (2*2*2*2*2*2) on 4096 but 2048 on 4096. After that you'll divide your value by 4 (10bit) or 16 (8bit). In a log encoding, each stop will have the same number of steps, compared to linear where you have one step for your first stop, 2 steps for your second stop, etc....

Link to comment
Share on other sites

I've been trying to find the reference, but haven't found it yet. But will post now/update later.

 

Here is how I think it might work. Exactly how many bits of luma or color depth will be recoverable is going to depend in part on how sophisticated the processing of the original file is. In particular, it will depend on the extent to which dithering is used in the original algorithm. 

 

Using the example of one bit/two bit used earlier: Yes, if all the algorithm does is round each value at each location, then bit depth is lost and is unrecoverable in some instances (though the equivalent of pixel binning gets you some increase in many contexts). So 0.2, 0.4, 0.6, 0.8 becomes 0, 0, 1, 1.  But if dithering is used, then there can be more information. What that means is that you randomly vary your values so that they average to be a desired value that is not actually in your bit depth. So 0.7, 0.7, 0.7, 0.7 might be represented as 1, 0, 1, 1. If this is the case, then there are bits to be recovered beyond those is the bit depth.

Link to comment
Share on other sites

"Very nicely, overkill even. 4:2:0 maps to an effective 4:4:4 with root-2 the image size. So 2.7k 4:2:0, is a nice 1920x1080 4:4:4 -- notice 2.7K is one of GoPro video modes partly for this reason."

 

For those who don't know, David Newman is not just "some software guy from Gopro" -  He invented the Cineform Codec and is clearly technically/mathematically gifted.

 

Video compression has some unfortunate terms, like "chroma sub-sampling".  More accurately, it is "chroma removal".  The whole idea behind video compression is we are more sensitive to luma and sharpness and less so to color.  That why 4:2:0 works as well as it does.  Is 4:4:4 really necessary for broadcast video?  Is 4:2:2 even?  

 

The problem with 4:2:2 vs 4:4:4 is that you are doubling up on color values; that is, using one value for 2 pixels.  Sounds bad, but again, in practice works very well.  

 

My guess, because I am not an expert in this stuff like David, is that with 4K you can shift pixels over, and therefore use a neighboring chroma pixel to bring one next to it from 4:2:0, to 4:2:2: and then 4:4:4.  Will the quality be visually better--we shall see!

 

What I worry people interpret that as is the 4:4:4: equaling a 4:4:4 created from the the ORIGINAL data.  I don't see how it can be.  Though I grant it will be close if the dynamic range is fairly flat.

 

Again, I think that is all most knowledgeable people are talking about.

Link to comment
Share on other sites

It would be great if someone with access to a Canon 1D C tested this.

I second you. I don't know if there's anyone in this forum that has a 1DC, but if you do or have access to one that'd be great.

Oooor does anyone know if there's any raw footage, a clip that comes from the camera and is uploaded in some site?

Perhaps we could ask Philip Bloom? :P

Link to comment
Share on other sites

Still fairly new to all this, but I'm guessing 4:2:0 8bit 4k -> 4:4:4 10bit 1080p, there's no gain in dynamic range, but at least big leap in sharpness?

 

I have a Galaxy Note 3 that does 4:2:0 8bit 4K at the moment.  Can I put that through GoPro Studio 2.0 and convert to Cineform Filmscan 2, and get this result?

 

Or can I do this in Premiere Pro CC by scaling down to 1080p inside a DNxHD 350X sequence?  Or does it have to be AE?  If someone can share a defailed workflow, that would be awesome.

Link to comment
Share on other sites

The math from 8 bit to 10bit is sound.

 

Just like the color is sound.  You have to change your perspective.

 

Everything operates in groups of 4.  4 boxes have the same color value...each box has a different luma value in example:

 

1: 50 2: 100

3: 25 4: 220

 

But all 1 - 4 have the same color value whatever that may be.

 

They all share the same full range color, aka 10 bit color which is why we have a "4" in front of 4:2:0,

 

So add the values together when you down sample to 10bit and you get 395 in a 10 bit luma space.  Do the math and you hit 38.57% of the full 10 bit range.

 

Now take the values and average them 1-4 and guess what you hit the same 38.57%  Which is more accurate however, the 10bit is.  Why? not only does it expand the space but it also retains all the data.  When you average the values you will lose data as it rounds off information.  The funny part is, I bet this is even more accurate then just strait captureing 10-bit at 1080p...you should get better roll off and easily exceed the range of 10-bit 4:2:2.  Anyone who thinks other wise needs to check their math.

Link to comment
Share on other sites

im exactly where svendson is right now, so i dont give you the long form of my comment.

 

however. i do respect mr newman and im certainly not the person to say somebody is wrong just for kicks, but im at least 90% sure that 2.7k 4:2:0 sampled to 1080p will NOT give you 4:4:4.

 

if he'd said that 2.7k 4:2:2 samples to 1080p 4:4:4 or 2.7k 4:2:0 samples to 1080p 4:2:2, then i had to give it to him. i never actually thought about this. genius. BUT i absolutely do not see his statement as true. BUT i would also like somebody to prove me wrong :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • EOSHD Pro Color 5 for All Sony cameras
    EOSHD C-LOG and Film Profiles for All Canon DSLRs
    EOSHD Dynamic Range Enhancer for H.264/H.265
×
×
  • Create New...