Thomas Worth

Hey y'all. I'm the developer of 5DtoRGB. If you're wondering what happened, well, I stopped working on it a long time ago to concentrate on mobile apps. I removed it from the App Store because it needed a lot of bug fixes and I didn't feel right charging for an app that I knew wasn't going to live up to people's expectations. I still have all the code, and if there's enough interest I can take a look at it. I actually planned on releasing a major 5DtoRGB update a while ago that would have dramatically sped up transcoding, but never got it stable enough to release. Then our Rarevision VHS mobile app happened, and uhm, yeah. That took priority, obviously.

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. It sums the 2x2 luma samples to a 10 bit value.

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

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.

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.

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?

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.

Here's a 16 bit PNG file, converted from a DPX file output by gh444: '>

It's typically easier for the CPU to process uncompressed data, but disk bandwidth is more of an issue. Since this app is designed mainly for testing, the DPX files will be large and require lots of storage bandwidth. If it makes sense, I can add the ability to save ProRes 4444 files at 2K. Generally speaking, ProRes footage is much easier to decompress and display than H.264 footage, even when it's 444/RGB. I haven't run into any problems with GH4 footage, though. The files are relatively small and any recent system should have enough CPU power to play them back in realtime.

Hey guys, I've written a really simple command line app for Mac that will resample GH4 footage from 4K 4:2:0 to 2K 4:4:4 using pixel summing. This will give you real 10 bit data in the luminance channel, so it's not just doing a brute-force bump from 8 bits to 10 bits. There actually is some interesting pixel finagling going on here: http://www.mediafire.com/download/f7h950spj5hrn9f/gh444.dmg There's no GUI, so you'll need to run it from the terminal. Do this by copying the app into the directory that contains the GH4 MOV files and using the following command in a terminal: ./gh444 INPUTFILE.MOV Make sure you cd to the current directory first if necessary. You can do this by typing "cd" into the terminal, add a space, and then drag the folder containing the MOV files into the terminal window. It will automatically add the path to the cd command. It'll look like this: cd /path/to/gh4/files The app will spit numbered DPX frames out in a folder named "dpx_out." I'd love for you guys to give it a try and see if you find it useful!

Here's a quick-and-dirty GH4 downscaler app for Mac I wrote that will sum four luma samples and write each frame as a 10 bit, 2K DPX file: http://www.mediafire.com/download/opo43u4xv5bdgxo/gh444.dmg There's no GUI, so you'll need to run it from the terminal. It's very easy. You just type this: ./gh444 INPUTFILE.MOV It'll spit the numbered DPX frames out in a folder named "dpx_out." I'd like to know if this really does offer an advantage, or if it's just wishful thinking...

5DtoRGB isn't set up to do this at the moment, but I'm looking into adding this capability.

That's correct, which is why the results so far aren't showing any benefit. Testing them should be put on hold until we have the camera originals and can process them specifically for ~10 bit output.

The 10 bit figure is achieved by summing the values of four 8 bit pixels, which automatically downsamples to 1/4 the resolution as a result. This requires special image processing designed for this exact purpose, and is most likely not being done by Compressor, etc.

Let's test this to be absolutely certain. If it is indeed an artifact of the color sampling, then the artifact will not be present in the Y channel. This can be verified by transcoding the original with 5DtoRGB using the "None" setting for decoding matrix. It will show Y, Cb and Cr as R,G, and B in the output file. Any way you can post originals? I'd like to do some experimenting over here. :)