@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.

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.

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.

@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.

@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.

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 good to know, thank you. Damn video engineers, lol.

Nice Perro - and love Valencia :)

@SeekingHeartwood Be interested to see an example. My personal experience of Flowmotion is that it is the most reliable of hacks. I have had 100% success with it and now don't even give it a second thought. My route to post is via Clipwrap converting to Avid DNX or ProRes depending on edit.

@SeekingHeartwood In all the tests I've run so far, the "digital rain" artifacts that appear in Adobe After Effects CS6 did not appear in After Effects CS5.5. If you have access to either CS5.5 or CS6, I'd be interested to hear more details of your results.

I would imagine so, but they are a really, really slow moving company. If it enters the queue behind the "make every part of the program work at the bit depth of the project setting" support ticket it may never get resolved internally.

so for my flowmotion hack footage i'm only getting the "diagonal rain" artifacts in CS6 on a PC. I no longer have CS5.5. I just played the flowmotion back in potplayer and the diagonal rain was gone. i then played back intravenous 2 footage and got no artifacting in CS6. adobe premiere pro cs6 has something going haywire when playing flowmotion footage . also, for what it's worth, i get no artifacts on the GH3 footage in premiere.

next i took the flowmotion footage and ran it through 5dtoRGB. it transformed a 4 gb, 12 min clip into a 100 gb clip. after importing it into CS6 and playing it back, no diagonal rain! but i'm going through a dozen interviews that are 2-6 hours long each, and each interview filmed with 3 different cameras! my storage needs would become preposterous if i were to transform all of my interviews with 5dtoRGB.

lastly, i rendered some of the original flowmotion footage in premiere pro into a youtube format, with the hope that the diagonal rain would be gone after an export and conversion, but unfortunately, it the diagonal rain showed in my final .mp4 footage, no matter what player i used.

going forward, i'll try to contact adobe, but i doubt they'll help me out with hacked footage. since i'm still filming, i've changed the hack on my 3 Gh2s from flowmotion to intravenous 2. the intravenous looks astoundingly better than flowmotion anyways, i wish i had filmed all of those interviews in intravenous2, and now i don't have to deal with any artifacts or 5dtoRGb. i hope a solution comes up for all the hours of flowmotion footage i've already filmed.

@radikalfilm

If on Windows I suggest exporting to DNxHD (the older 2.2.x codec!), as 2.3.x has a colorspace conversion bug in 32bpc AE projects;

That must be what happened to me. On the 32bit timeline it looked almost like some kind of "zebra pixels" feature that was showing, in some scenes, the hottest or most deeply saturated parts of the image. Ugh, good to know about the version, thanks! I had to go back and re-transcode the whole lot of clips to ProRes.