Personal View site logo
GH2 Flow Motion v2 - 100 Mbps Fast Action Performance - Series 2
  • 314 Replies sorted by
  • 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 (betterwithmusic.com)

    For GrabacionAereaHD.com 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.

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

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

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

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

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

  • 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. I concur with your finding. I use CS5.5 and I have not seen that problem.

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

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

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

  • @matt_gh2 Yes, I'd be very interested to examine your unhacked footage that provokes digital rain. PM me and I'll send you my email address.

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

  • @LPowell @BurnetRhoades I have some footage that is just Panasonic stock GH2 firmware where I got the diagonal digital rain. If it's helpful to either of you, I can email original MTS file.

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

  • @LPowell What could your or any patch possibly be doing that 5DtoRGB wipes clean? Or has someone produced original camera MTS files that have the problem even after using 5DtoRGB?

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

  • Good to see a nice stable patch for 30P.

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

  • @LPowell. Lee, you have been pretty quiet for a while. I was wondering, is there a new version of FM in the works or you are done with GH2 and waiting for GH3?

  • 1080p 24P H and HBR 30p Flowmotion absolutly stunning THX Lee

  • Thanks for your comments mate. I was blown away at how well FM handled the lighting situations, very pleased with the results. The lenses I used, aside from the kit for the big wide, were actually old Minolta Rokkor lenses. I cannot rave about them enough, sharp and clear, built like tanks and buttery smooth focusing. But the best part is that they are almost giveaway prices. A 50mm 1.4 will cost nothing much more than £40/$70! I bought a 28mm 2.8, 50mm 1.4 and a 135mm 2.8 all for little over £100/$150 from eBay! Check them out if you want a steal.