Personal View site logo
GH2 Flow Motion v2 - 100 Mbps Fast Action Performance - Series 2
  • 316 Replies sorted by
  • @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 In all of my tests so far, After Effects CS5.5 properly decoded the same video files that produced diagonal flickers in After Effects CS6.

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

  • @LPowell. I concur with your finding. I use CS5.5 and I have not seen that problem.

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

  • @BurnetRhoades I've seen claims from both 5DtoRGB and CineForm that their upsampling algorithms produce smoother chroma gradients than standard H.264 decoders. They use interpolation and/or dithering to upsample the 4:2:0 color components to 4:2:2 and imply that other decoders use coarse line-doubling instead.

    If you do any color grading or exposure compensation on the original video before transcoding it, the modified frames will contain finer details than those in the original 4:2:0 file. These modified details will be better preserved in a transcoded 4:2:2 file, rather than writing them back to a 4:2:0 H.264 file.

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

  • @BurnetRhoades

    1) After Effects working space set to sRGB

    2) 32bit float

    3) linearized

    If you use After Effects in ICC Color Managed mode, it will examine the color space metadata in your footage, and if different, it will remap the colors to your Working Space. You can check the Interpret Footage properties of your imported clips to see if After Effects has remapped your footage or left its colors unchanged.

    If you don't want After Effects to remap the colors in your GH2 AVCHD footage, you should set your Working Space to HDTV (Rec. 709). This is the color space metadata tag that is found in GH2 MTS files. Rec. 709 uses the same color primaries as sRGB and in practice, they look virtually identical. But if you set your Working Space to sRGB, After Effects will remap your MTS files.

    When importing GH2 MTS files in 32-bit mode, After Effects will also interpret them using linearized math, so you'll want to set Linearize Working Space as well. However, in 8-bit or 16-bit modes, Linearize Working Space should be turned off. In my view, there's no good reason to run After Effects in anything but 32-bit mode.

  • @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 "there's no good reason to run After Effects in anything but 32-bit mode."

    You're preaching to the choir, brotha'man. What's sad is, since at least 2001, Adobe hasn't been able to get their act together and make all of their supplied filters work at their highest bit depth. Back then, when working in 16bit was the best you got, half the app only worked in 8bits.

    I was ready to dump After Effects completely there for a while in favor of Commotion, which was written to do all the things After Effects did poorly, but then Puffin had to go get sucked into the Pinnacle black hole never to be updated again.

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

  • @BurnetRhoades

    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.

    Right, but Rec. 709 is not necessarily 16-235. If you examine After Effects' list of Working Spaces, you'll see two Rec. 709 selections:

    HDTV (Rec. 709)

    HDTV (Rec. 709) 16-235

    The "16-235" variant is the original Rec. 709 "studio swing" spec used by broadcast studios. The plain "HDTV (Rec. 709)" Working Space is a "full swing" 0-255 spec that was appended to Rec. 709 as a VUI metadata option. Fortunately for us, the GH2 tags its MTS files as containing full-swing Rec. 709 color data. That is why setting After Effects to use HDTV (Rec. 709) will stop it from remapping the colors in your video, while using the same color space as sRGB.

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

  • Recorded with Panasonic GH2 Hacked Flow Motion v2.02 Patch

    Filmed and edited:Chema Gallardo Actors:Cristina girl / Rassel the dog Recording area: Valencia-Spain Barrio del Carmen Music by: "Siesta" for Jahzzar (

    For Thanks to Vitaliy's and LPowell for patches to GH2

    "Mi Perro" Test Video GH2 + Canon Fd 50mm f1,4 Hack Flow Motion v2.02 from Grabacion Aerea HD on Vimeo.

  • Nice Perro - and love Valencia :)

  • ugh, just filmed about 8 interviews for a doc and have diagonal rain artifacts in all the footage, never using flowmotion again

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

  • It's not the setting, it's the decoder. Transcode with 5DtoRGB and you'll be fine.

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

  • Has anyone reported the decoder issues to Abode?

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

  • This was 90% flowmotion (one interview angle was 5D). I've gotta get back to the caves for something fictional. (Skip a couple of minutes in to see some montage stuff)

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

  • @SeekingHeartwood:

    Your only solution is 5D2RGB; However, you can play it smart:

    -Cut your material and achieve picture lock on the "raw" .mts; ignore the rain.

    -Locate each .mts (Reveal in Project, then Reveal in Explorer) file and run it through 5D2RGB, with meaningful output names. 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; if you finish directly in Premiere you're probably fine with 2.3.x

    -Replace Footage for each clip with the transcoded files, with Rename Clip ticked.

    You're now good to go, with a reasonable expense of time and disk space. The downside of this workflow is you have to go through each file by hand.

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