Maybe you should re-read my post. I said if Panasonic implemented the conversion in-camera properly, you could easily do that. I have no idea how Panasonic did it though. If they skipped implementing a few lines of code, you will average about 8.5 bits rather than 10 bits.

@burnetrhoades - are you tech enough to write such a thing? I think there's a real market for a piece of software like this. I've done a lot of down convert experimenting over the last few days, and its definitely a weak spot for some nle's

@BurnetRhoades I'm still curious too. Can't wait too see these new techniques : ) But until that, we have only "ifs", haven't we comrad @tosvus?

It's doing the down-conversion and re-sampling as a standalone tool rather than loading the footage into an editor or package like After Effects. That's all. The re-sampling isn't doing anything especially fancy or solving issues related to ugly digital noise or banding present in the 4K file by the sound of it.

The advantage in this case, however, is that it can be easily batched to do the conversion straight away on a whole folder full of clips, or you could even do it as part of the pull off the memory card, if you were so inclined. No messing with project settings or temporary project files or any of that, just straight away conversion.

It's how I wish 5DtoRGB worked.

@BurnetRhodes thanks. I'm still a bit confused by the practical implications of this downsampling. Is the idea that one should have more grading latitude in a downsampled 4K file than one would have in the native 4K file? If so I'm not seeing it.

Is the idea that one should have more grading latitude in a downsampled 4K file than one would have in the native 4K file? If so I'm not seeing it.

Maybe new magical or ingenious methods of down-sampling will realize this promised return, but it's certainly not apparent in downsampled GH4 footage. The average bit rate of driftwood's downloadable .mov files is 50-60 Mbps, or about 13 Mbps per quadrant. How much can anyone reasonably expect to wring out of that data rate?

Then again, it may not really matter: the enthusiasm for the supposed image quality of GH4 4K stuff is incomprehensible to this viewer, so the same parties enthusing over the 4K samples seen so far will likely be delighted with the 1080p down-sample.

I used the gh444 tool by Thomas Worth to convert Driftwoods "Face" footage to 2k DPX files and compared them to a simple 50% downres in After Effects.

Then applied the same curves to both clips. Those are 800% Crops.

Depending on the implementation, it can get up to 10-bit out of the footage.

Note that it will not fix macro-blocking or limited dynamic range. For Dynamic Range, consider the picture as a 12" long ruler (12-stops DR from sensor). The benefit with the program is that instead of having say a measurement line once every inch, it now has one every 1/4 inches (best case). However, the ruler doesn't magically get longer (say to 14" (meaning 14 stops)).

The gh444 conversion is on the right. Macroblocking is exactly the same but there seems to be a smoother highlight roll-off.

This is why there needs to be a temporal component and, I think, a stochastic methodology applied to the sampling. This should have the double benefit of not only de-emphasizing residual issues from low resolution chroma but artifacts from the compression. It should end up looking more organic. Digital noise on these cameras, whether it's 1080P or 4K looks like what it is, whether it's a GH2, a GH4 or a RED and nothing like film grain.

edit: your results further support that Thomas Worth does a better job of re-sampling low resolution chroma than Adobe does, since 5DtoRGB does a better filtered conversion to full-bandwidth color from AVCHD than Adobe, assuming he's using similar routines in 'gh444' as he uses in 5DtoRGB. It looks like it.

@jbpribanic a true 10bit 444 would have 10 bits (1024 shade values) for all luma and both colors in all pixels.

Just looking at the bits, a good down conversion of Luma from 8bit will take the 256 shade values of each of the 4 pixels that are being downsampled into 1, and adding them together 256 * 4 = 1024, so you get a full 10bit of luma, obviously your actual dynamic range is not increased, just the shades of grey.

For color, it gets more tricky. We are starting with 8bits again, but in reality since it's 420, we only have 1 actual original 8 bit value for Blue and Red out of the 4 pixels we are to downsample to 1, but when you factor in the luma for each pixel which are unique, you have a bit more data to work with.

You can still do a 256 * 4 = 1024 to get a "10bit" value, but the color accuracy will not be as good as if you had recorded the color data for each pixel. Essentially the variance in color "shades" when spread out to 10bit will rely on variance in luma which won't look as good when pushed and pullled.

I would expect a "444 10bit" 1080p image from a 420 8bit 4k source to look really nice, it will be sharp, and would take to green screening very well. However, I don't expect it to grade super well, better than 420 8bit 1080p, but colors will break apart fairly quickly if graded heavily.

The below is a very abridged version of what I originally was going to post... ;-)

I guess I'm confused. The title of this thread is about chroma subsampling methods/spaces, but changed to one of bit-depth. These are two completely different methods of lossy "data compression", even though they are related like apples and oranges... both are fruits, but are are very different in structure.

Below is my understanding of how these work. Perhaps someone else can correct my misunderstandings of this topic? I'm including Wikipedia links as cites and examples of points. Please do similar in a contrary response so I can read up on the background information and learn from it.

444, 422, 420 deal with chroma subsampling. 444 contains all of the information in the "original" colors. 422 and 420 use different horizontal and vertical subsampling to try to closely, visually (re: Vitaliy's point) the original 444 colors for a certain area of the video frame. Unfortunately, once video is converted from 444 to a subsampled space, that data can never be fully recovered (@Ze_Cahue 's point).

The colors may be close (depending on the quality of the codec), but will almost never be perfectly accurate when converted back to a 444 color space. Because of the way our visual system works, we may not SEE (i.e. notice) it, but, technically, the resultant colors will almost never perfectly match the original 444 source. (This also has consequences when correcting/grading in post.)

This can be seen visually here: (about 1/3 of the way down)

http://en.wikipedia.org/wiki/Color_sub-sampling

Then the conversation changed over to bit depth. And dynamic range (DR) even made an appearance.

Visual (i.e. light) DR refers to the number of doublings of light that a sensor (camera sensor, in this discussion) and is referred to as "stops" in the photographic world (i.e. every doubling of light is another stop). In that sense it is binary like the bits (powers of two) used to record shades of color/gray, but it is not digital (i.e. bits).

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

Because of this, we can have cameras that have 12 stops of DR, but only record 8 bits of that data and throw away (lose) the gradations in between. Contrarily, we can have a sensor with only an 8 stop dynamic range, but record 12-16 bits of gradations in that light range (DR) like my old D70. With the first example, while there will be a huge variation of light from dark to "full" (12th stop) bright, there will likely be banding because 8-bits is just not enough to capture that range. With the second example, while the apparent DR is not close, the gradations between full dark and bright will be very smooth.

Anyway, bit depth represents the number of shades of a each color in a pixel after debayering. Debayering itself is an attempt to reconstruct what would be present if each pixel actually had a RGB sensor in each pixel, so will not be perfect.

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

Bit depth has a correlative relationship to DR, but they are not the same.

Alright, back to bit depth. If we start with a 10-bit source and down convert it to 8-bit, then we are throwing away ¾ of the information (gradations) we started with. (Note that this has nothing to do with chroma subsampling.)

As an example, if we look at the 10-bit file at the top end, let’s say we have 4 single color pixels with values of 1020, 1021, 1022, 1023 (0-1023 for 10-bits gradation recording). If we down convert it to 8-bit, then we will have to (simplistically for the purpose of this example) record all four pixels as 255 (0-255 for 8-bits gradation recording).

If we want to “reconvert” back to 10-bit, then we don’t know what the original values are and (simplistically) look to surrounding pixels for clues as to what those values may have been. And those surrounding pixels are “damaged” also, so those clues are compromised. Regardless, it is almost impossible in the real world to accurately reconstruct what the original values of those pixels were other than through luck.

Similarly, once we have converted to 8-bits, we lose the ability to have as smooth gradations (which results, in many cases, in visible banding). Even though software can "smooth out" the banding by going to a higher bit depth space (and dithering), it isn't the same as the original data (though it might be very close).

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

The bottom line is GIGO (garbage in, garbage out). However, many codec engineers do wonders sorting value out of garbage.

Even with a 422 10-bit 4K vid, converting from that to a 2K 444 10-bit vid will still not be as accurate as a 2K 444 10-bit capture. Of course, we can't get 2K 444 10-bit out of the GH4, but the point is that the colors will be compromised, even if it appears sharper due to perceived sharpening artifacts from the downscaling process. It may look better, but it won't be as accurate as a native capture.

Hmm, I should note that I'm not saying that 2K 444 10-bit can't be CREATED, I'm saying that it isn't the same as a 2K 444 10-bit SOURCE. It is a created product that only replicates, not duplicates, the original.

Anyway, please correct me if I have this wrong... or if I'm going off on a tangent (i.e. I didn't correctly understand what the original discussion was about.

Sounds weird, but looking into the RAW data it is possible to get 2k 10bit from a 8bit 4k. It would require a complete different algorithm. My initial thoughts were regarding the final output from a "normal" camera. The dammy dummy 8bit will never be a real 10bit, the data that was already destroyed could only be simulated to get smoother gradations. But if the camera stores each of the original 10bit pixel from a 2k into the "extras" 4k pixels, the final output could be reverted again into a 2k 10bit, because all the "original data" would be arranged intelligently into these extra pixels. RAW -> 4k 8bit -> 2k 10bit I see possible this way, but the camera should write the right pixels into the right place, for later recovering, this mean a fresh new or hacked firmware. If you guys meant that, I'm sorry, was not that clear for me. But with a "smart bit arrangement" I see this very possible. Who's gonna write the code and put inside the cam? : )