Nice Perro - and love Valencia :)

@LPowell good to know, thank you. Damn video engineers, lol.

Oh, and I work in linearized not so much for anything it may or may not do for GH2 footage but because that's the standard for film manipulation now that we have boxes fast enough to do it. I use it because that's the only mode that mimics how light actually works and it lets me do optical-style blending that's always had to be "faked" in other spaces.

It's just a drag since I'm currently using the plug-in version of Film Convert I have to write that out as a pass and then re-read the FC'd footage so that I can play with it in a linearized project.

@LPowell if I'm not doing something I know is going to be broadcast...scratch that...if I'm not doing something that I know some TV station engineer isn't going to QC there's no way I'm working in 709. Black should be black. White should be white.

@LPowell that makes sense, though I'd understand a difference in appearance more if it were from looking at the footage in a simple playback app and not something like AE where I'm looking at it further up-sampled to 32bits and 4:4:4 on the timeline. Maybe they're doing very little though, in an attempt to faithfully preserve the incoming information.

Apple got knocked for that in DV codec comparisons, back in the day, because they left it good and ugly where Avid and other competing codecs offered some kind of chroma smoothing.

In addition to my theory that ATI versus NVIDIA libraries somehow in the mix might be influencing these results there's also a question of the colorspace used in CS6-AE that could be be a factor.

I get the "rain" in all footage touched by CS6-AE if it has large areas of underexposed midtones. Broad areas of midtone falling off into shadow is the perfect environment for "rain". Patch, not-patch, Mac or Windows. Every shot, every video since I got my camera, until I started using 5DtoRGB (and I'm still using the free one, so it's not like I'm plugging it because I have any interest other than good looking footage).

In addition to both of my machines having ATI chipsets I also follow the following paradigm which may or may not be involved in CS6-AE messing up the footage when it also has to read MTS:

1) working space set to sRGB 2) 32bit float 3) linearized

...some folks not getting any problems it could be they stay working in rec709, or they might be staying in 8bit, or maybe 16bit. Maybe it's just folks working in 32bit or maybe it's those of us that take it all the way to linearized 32bit.

That last bit, that messes up other tools. Currently Film Convert doesn't work properly in linearized 32bit. Certain functions in ColorGHear don't work as expected either but that's because the internal AE filters it relies on don't always work consistently in linear. Nodes that modify gamma, in particular, can get wonky.

I'll go even further to say that I've noticed an overall increase in visual quality within CS6-AE once I was dealing with 5DtoRGB ProRes clips instead of stock firmware, camera-original MTS files. I'm seeing better skin tones, better tonality in skies and better color rendition. I've been going back through older projects and re-doing those that got "rained on" with MTS sources.

This goes against the conventional theory that you have nothing to gain qualitatively doing your own transcode+decode to an online codec like ProRes or DNxHD. The theory goes, once in a 32bit AE timeline it's all supposed to even out. That theory, however, is predicated on the assumption that CS6-AE isn't broken when it comes to MTS files.

@matt_gh2 I've got plenty of footage shot with stock firmware that looks bad when rendered with CS6-AE if I use the MTS directly. Run it through 5DtoRGB and it looks great run through the same CS6-AE project instead of the camera-original MTS. This didn't change when switching to a hack and didn't even change when switching operating systems.

If it's in the results of running unpatched camera MTS run through CS6-AE then patching has nothing to do with the problem. Perhaps something in the patch exacerbates CS6 getting fucktarded with the pixels, but it's not the cause. If patches were somehow to blame then it only stands to reason that would mean that these patches have evolved into some kind of virus that's spread to the Panasonic factory, infecting cameras coming directly off the assembly line and that there's no such thing as "stock" firmware.

But that isn't the case. Patched or stock, Mac or Windows, camera MTS rendered through CS6-AE produces scheisse if you rely on the Adobe transcode+decode functions.

5DtoRGB is obviously doing something right that Adobe is doing wrong.

@BurnetRhoades I've seen other cases where a commercial decoder was unable to correctly render the contents of a perfectly valid H.264 file. Unfortunately, the H.264 specification encompasses such a wide range of encoding techniques that it's a real challenge for a manufacturer to test and verify that their decoder correctly handles all possible permutations of H.264 encoding syntax. PTool gives us the ability to dramatically alter the behavior of the GH2's encoder, and it's quite possible that our hacked MTS files could expose latent decoder flaws that testing with ordinary H.264 files has failed to reveal. In that case, it may be more prudent to tone down problematic patches in order to stay within the safe region of the decoder's functionality.

It's not like Adobe needs even more encouragement to be lazy bastards.

@Zaven13 I'm currently investigating the cause of the elusive diagonal flickers that are sometimes seen in Adobe CS6. I have a sample video that produces flickers in After Effects CS6, but shows no flickering in After Effects CS5.5. If the flicker is exacerbated by certain patch settings, I may be able to find a way to suppress it. If so, I'll release an updated version of Flow Motion v2.

Don't know if you've seen this already, but this seems like a nice job with Flow Motion and Zeiss glass. http://www.noamkroll.com/splitting-bethany-feature-film-shot-on-gh2/