Personal View site logo
100Mbps Flow Motion v1.11 Failsafe Patch with HBR 25p & 50p modes
  • 574 Replies sorted by
  • @Lpowell thanks

    I think that the dreams of many of us Pal users hit a wall! :(

  • As a pal user, I'd be delighted with 75Mbps in flowmotion. Remember that nick driftwood is likely to concentrate his efforts on the best possible, no bit-rate barred patches so I wouldn't get too depressed yet - ultimate picture quality is not what Flowmotion is about.

  • @LPowell

    "In the AVCHD encoder, Panasonic chose to crush the bottom 16 levels (out of 256) of the luma scale to zero, probably to make dimly-lit amateur videos look cleaner"

    Certainly not to safe amateurs from screwing up their shots. This is due to TV standards - broadcast signals (for instance ITU-R BT.709) have different levels than computer signals. TV = 16-235 (also called "studio swing"); computer = 0-255 (also called "full swing"). The GH2 respects this standard so that blacks below RGB 16/16/16 are clipped (while there is some headroom maintained for the whites ... whites do not clip at RGB 235/235/235) This is why the display and also the Histogram changes on the GH2 when you start to record video (on the left end of the Histogram the blacks switch from full black to TV-black and the contrast of the image on the LCD consequently is increased).

  • @towi Yes, good point, but to implement broadcast-legal standards properly, Panasonic should have scaled the RAW data so that the full range of analog sensor response was scaled to fit within the 16-235 studio swing. Instead, they shortchanged us by encoding the RAW data into the 8-bit full-scale, 0-255 range, and then crushed the near-black data in the range of 0-15 to zero. That's why a negative pedestal correction needs to be done in post-production.

    @LongJohnSilver As an NTSC user, I share your disappointment in HBR mode. I was hoping that HBR 1080p30 mode would serve as an alternative to 24p for music video production. But compared to 24H 80% Slo-mo mode, which genuinely records in Native 30p, HBR 60i is second best. I will be using HBR only in cases where I need a synced sound track.

  • " will be using HBR only in cases where I need a synced sound track." We've already done so on one big job and it was a godsend! So much easier to sync to the audio when there's an audio track on the camera too. And while HBR may never catch 24p on the GH2, an 80mbps 30 with audio is nothing to sneeze at!

  • @LPowell Not possible to optimise HBR settings to the same level at expense of 24H then?

  • @LPowell

    "Panasonic should have scaled the RAW data so that the full range of analog sensor response was scaled to fit within the 16-235 studio swing. Instead, they shortchanged us by encoding the RAW data into the 8-bit full-scale, 0-255 range, and then crushed the near-black data in the range of 0-15 to zero"

    actually this is not what I am seeing...?! Of course the LCD crushes the blacks but the actual footage in fact contains the full range of luminance as measured with the "photo"-histogram (or "full" histogram). The whole image then get's "compressed" into studioswing. Or to put it simpler: I don't see any crushed blacks (other than really underexposed scens). Or did I get you wrong?

  • @Lpowell

    What´s wrong with panas HBR mode? I don´t see any differences between HBR and 24H.

    Here are my snapshots, do you see differences?

    24H.png
    1920 x 1080 - 2M
    30pHBR.png
    1920 x 1080 - 2M
  • Yes, I do, in fact, see the difference. The most obvious is the lower resolution of the HBR shot. It could be just that particular frame that you chose or some inadequate de-interlacing, but it’s there and it’s very obvious.

    Noise-wise, I can’t say much. There’s difference in the noise, but to truly compare it, I’d have to look at the actual footage, not individual frames.

    There’s also some difference in the way the “rainbow bar” of the Transcend card has been rendered in the two shots, and macro-blocking is more visible on the vertical black plastic part in the center of the videotape cartridge on the HBR shot. That, however, is also not very representative, as I might be looking at a 24H I-frame vs., say, an HBR B-frame.

  • Mr_Moore, I'm not seeing the res difference. There is a noise in the shadows dif but not great.

    No, don't bum out about HBR vs 24. 24 is mind-bogglingly good. HBR only great. So glad to have the HBR tool in the toolbox now.

  • assemble the 2 images in Photoshop on layers and compare them turning on/off the upper layer. The difference is remarkable! This is a close shot where resolution difference is not so apparent. The same comparision with a wide angle shooting a highly detailed landscape scene will make the difference very clear.

  • I can see the drop in resolution easily. Look at the writing at the bottom of the DVD where is says “Specifications subject to change without notice,” and compare the lowercase i in without, for example. It’s not that that spot is particularly telling, but it demonstrates what I mean very well.

  • @LPowell

    How does one do "a negative pedestal correction in post-production"? I have no clue but it seems as if I should. I short explanation would be really appreciated.

  • @towi - "...the actual footage in fact contains the full range of luminance as measured with the "photo"-histogram. The whole image then get's "compressed" into studioswing."

    Yes, as you pointed out earlier, Panasonic encodes the full range of luminance up to the 8-bit max of 255. It then leaves the bright end of the range untouched and simply clamps anything that's below level 16 to zero. This creates a noticeable gap in shadow noise distribution that you can often see when you boost the gamma in post (since pure black does not get boosted). That's what I mean by "crushing" shadow noise to black, and it is a consumer-grade substitute for properly scaling the sensor data to the 16-235 studio-swing standard.

  • @LPowell

    Interesting. Here’s what wiki has to say about NTSC-J:

    The black level and blanking level of the NTSC-J signal are . . . at 0 IRE . . . , while in American NTSC, black level is slightly higher (7.5 IRE) than blanking level.

    I wonder if that has something to do with the problem you’re describing.

  • "It then leaves the bright end of the range untouched and simply clamps anything that's below level 16 to zero."

    "clamps" = "clipps"? So everything below level 16 is cut off? This would mean the range from 16-255 is compressed into 16-235 whereas the range form 0-15 is lost, correct? Well, if so I got you right. But this is not what I am seeing on my camera. What I am seeing is that the whole range of luminance from 0-255 is translated (compressed) into 16-235 (with some headroom in the highlights).

  • @Mr_Moore

    ok, you won, but it`s extreme pixelpeeping, noone would see the differences watching this clips on tv. Ok, testing and pixelpeeping apparently has become a popular sport, at least on these websites.

  • @towi - "...So everything below level 16 is cut off?"

    Yes, and that's it, nothing more. On the GH2, there's no "compression" used to convert 16-255 into 16-235. As you pointed out earlier, the entire 8-bit luminance range is used all the way up to 255 for the highlights, and nothing is done to limit or reduce that to 235.

    The MTS file evidence doesn't support your claim that Panasonic was attempting to implement the studio-swing standard. My hunch is they were simply using a cheap consumer-grade technique to crush low-level shadow noise to black.

  • okay - I got it now. Thanks!

  • @lpowell, the GH2 is using studio levels properly. Black is 16 and white is 235. Occasionally you see levels below 16 or above 235, but it's just compression errors, and the errors will be clipped away when the video is converted to RGB for display.

    Y-channel histogram attached. The brown bars show 0-15 and 236-255.

    gh2_histogram.jpg
    2176 x 1080 - 117K
    gh2-histogram_dark.jpg
    2176 x 1080 - 196K
    gh2-histogram_light.jpg
    2176 x 1080 - 336K
  • @LPowell "HBR mode is actually nothing more than FSH mode scanned at 25p and encoded at 50i, and is not even flagged as a 25PsF progressive file. As a result, you may need to manually indicate that it is progressive rather than interlaced when bringing it into an editor."

    Same like Blu-Ray Standard: 50i or 24p with 1080. Pal world is a mess. 99% percent of Computer Monitors are derived from NTSC´s 60Frame/Fields timebase. No way to watch fluent motion in 25P/50i without dedicated video cards like matrox/Aja etc. Even many Pal-Flatscreen TV´s i tested for editing demand 60i over HDMI when connected to my Mac or a PC. Was lucky to buy an old Viera Plasma from a friend which demands 50I/50p over HDMI

    Hope, those examples help a bit. Again, just for testing blacks. I am not able to export a mts frame grab directly. Have to export to prores422HQ using 5dtorgb, then I export the frame. Hope it does not alter things too much. Interesting the blacks on my flatscreen with Flow Motion. When raising the black level on "Flow Motionv11Blacks", I see large dark areas with a slight tint of red, but blocks of pure darker black in those ares as well... This effect is not so apparent with Quantum.

    QuantumX25pWindow.jpg
    1920 x 1080 - 1M
    Flowmotion11_25pWindow.jpg
    1920 x 1080 - 1M
    Flow Motionv11Blacks.jpg
    1920 x 1080 - 692K
    QuantumXBlacks.jpg
    1920 x 1080 - 715K
  • @Frame - "I am not able to export a mts frame grab directly. Have to export to prores422HQ using 5dtorgb..."

    Really?

    This is the second time today that I have encountered opinions voiced about Flow Motion still image quality that are actually based on evaluations of transcoded 5DtoRGB videos.

    I thought the whole point made by advocates of 5DtoRGB is that they prefer the enhanced filtering of its transcoded images to the originally recorded images?

    http://nofilmschool.com/2010/06/is-5dtorgb-the-dslr-post-production-solution-weve-been-waiting-for/

    Frankly, if you like the qualitative effect produced by 5DtoRGB, that's great and I'm not about to criticize your chosen workflow. However, I will object to your labeling these files as "Flow Motion" footage, not because I think 5DtoRGB sucks, but because these transcoded videos have been adulterated, regardless of whether it is for better or for worse.

  • @balazer Good work, I see what you mean about luma being scaled to 235 even though it occasionally extends up to 255. I think that probably is due to minor encoding discrepancies which are handled safely by the extra headroom above 235. This does support @towi's claim that the GH2 follows the studio-swing standard, with input levels to the AVCHD encoder limited to a range of 16-235.

    On the dark end of the scale, however, I've seen decoded AVCHD files that produce RGB values below 16. Here's an example of a Color Finesse screen in After Effects:

    image

    In the upper left panel, you can see how close the luma channel gets to the IRE 0 line. Notice also that the Pedestal setting is at zero, i.e. uncorrected. On the right just below the image frame is an eye dropper that I used to grab a sample from one of the darkest spots in the image. It reads:

    Red: 3

    Green: 0

    Blue: 15

    This is the smoking gun. Although technically, this pixel value is close to the studio-swing black level of 16, in practice, its perceptual luminance is near zero (because G = 0). If we boost the gamma of the entire image, these near-black pixels will remain perceptually close to zero. The result in this sample footage is the appearance of blotchy dark spots (AKA "blocking"), as seen in the cropped image on the left:

    image

    The cure for this encoding flaw is a small negative Pedestal adjustment that lowers all pixel RGB values by 15. This eliminates the black-level gap and allows us to then boost the gamma without producing blotches. The result is shown in the cropped image on the right.

    GH2 black-level Color Finesse.jpg
    850 x 478 - 150K
    GH2 pedestal correction.jpg
    850 x 480 - 158K
  • Ill agree with LPowell on this - be careful with 5DtoRGB especially if you are using Adobe Premiere:

    From Adobe themselves:

    "Inside Premiere Pro, the images will stay exactly as they were recorded in-camera for cuts-only edits. If there’s no color work going on, the 4:2:0 values remain untouched. If I need to do some color grading, Premiere Pro will, on-the-fly, upsample the footage to 4:4:4, and it does this very well, and in a lot of cases, in real-time. Going to a 4:4:4 intermediate codec does have some benefits – in the transcode process, upsampling every frame to 4:4:4 means that your CPU doesn’t have as much work to do, and may give you better performance on older systems, but there’s a huge time penalty in transcoding. And, it doesn’t get you any “better color” than going native. Whether you upsample prior to editing or do it on-the-fly in Premiere Pro, the color info was already lost in the camera."

    Nobody has ever proven to me at least, much of a difference using 5DtoRGB apart from chroma smoothing (not always a good thing).

    Edit: Damn Lpowell you really are busting your ass on this patch - Kudos!

  • @LPowell. Lee, I tested the Flow motion v1.1 today. I used Panasonic 14-140mm lens, AF(on), OIS(on), zooming, Sandisk Extreme 32GB 30mb/s card. Outdoors was overcast shooting mountains and trees. I am an NTSC user.

    All of the NTSC recording modes (24H, 24L, 1080i60 FSH/FH, HBR, 720p60 SH/H, MJPEG HD, VGA) worked flawlessly in normal and EXTC mode. 80% slomo worked fine too. Bit rates ranged from 15mb in FH to 70+mb in 24H. 1080i60 FSH and HBR had the same bit rates.

    An hour later, sun came out and I did some more testing under sunlight and more detail shots of the trees with zooming. I was able to push 24p to over 100mb with no problems. However, 1080i60, 720p60 and HBR began to have write errors once pushed above 65mb.

    The video quality is very good and motion is smooth also specially with 720p. This is one of the most all around capable and stable patches I have tested. It took the combo patch of driftwood Seaquake and Ralph_B Sanity to have similar stable results. Congrats for a nice patch and kudos for all the hard work.