Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
100Mbps Flow Motion v1.11 Failsafe Patch with HBR 25p & 50p modes
  • 574 Replies sorted by
  • @towi "...there is only one explanation that really makes sense: when you shoot video the GH2 switches to studio swing (it remaps the fullswing range into the studio swing range respectively). If the GH2 would utilize the full tonal range (fullswing) there would be no change on the histo and also the image on the LCD would display the same tonal range as in photo mode. Many softwares interpret MTS files as being fullswing..."

    Nice try, but while it is an appealing explanation of the LCD's behavior, the evidence proves it be incorrect. After Effects identifies GH2 MTS files as Full Swing Rec. 709 standard for good reason: they actually do contain 8-bit luma values that range from 0-255. Download this short sample video to see for yourself, and compare it with the luma waveform in the Color Finesse screen grab below:

    What's crucial, however, is to import the MTS file into a video editor, such as After Effects, that can be set to Full Swing Rec. 709 mode. It will then decode the file without altering the Full Swing luma components. If you instead import it into an editor in Studio Swing Rec. 709 mode, such as Avid, it will automatically remap the luma components to fit within the Studio Swing 16-235 range. (After Effects will do this as well if you set it to Studio Swing Rec. 709 mode.)

    towi, given Avid's under-the-hood Studio Space alterations of MTS files, it makes sense why it appeared to you that they were encoded in the restricted 16-235 Studio Space range. But in all seriousness, you've made a number of authoritative claims in recent posts that are contradicted by direct evidence, indicating that your advice and assumptions are incorrect. I'd appreciate it if you'd go back and edit those misleading claims appropriately.

    GH2 Full Swing Rec 709.jpg
    960 x 540 - 166K
  • Actually talking about advice and assumptions I think I too have been giving the wrong impression. This is mainly because I really didnt want to get into an argument over this (so I backed down and gave a rationalisation of your adjustments, which I'm not happy about), and only continued when towi was pointing out what was also bothering me. and got a similar reaction. also then people started to ask about the 'correct' fix etc, etc.

    Premiere is working/interpreting correctly, no adjustments are necessary (this is why I said to DrDave if you 'really' want to do this). I have never seen the artifacts in the blacks you showed in your original example and your reason for them being there cannot be correct to me, it just doesn't make sense. If premiere wasn't working/intepreting correctly, you wouldnt see the full range that you are seeing in the scope images you've posted. I've been working with nothing but lowlight GH2 shot footage for the last few weeks too. I've also spent the last few hours trying to recreate/find the same problem in Premiere and haven't been able to. All I can guess is that color finesse isn't intepreting correctly, or isn't setup correctly, or Premiere is communicating with it badly (and none of those explanations actually make sense either). Saying all that those blocks just look like well... blocks from compression that you'ld see when you altered the gamma (or any number of things), and your solution is just like setting a clamp. This is a perfectly good solution too. Can you show us the same problem using Premieres color correct effect, or any other effect on the Premiere preview screen ?

    If such an adjustment needs to be done (and I am hopefully clearly saying it doesn't) as you are suggesting then the correct way is to fully expand/alter your range at the same time.

    Edit : Maybe if you just increased the length of the toe of your gamma curve that would solve the problem. After all, gamma adjustments are supposed to leave your black levels mostly untouched.

  • @LPowell

    you provide yet another conclusion raised from software behavior (in this case AE). Who cares what a certain software reads from the file.

    It's not "LCD behavior" I am talking about... it's the histo I am talking about. Quick and dirty handheld iPhone shots of the GH2's histo. 1: the scene in "finder"-mode which shows the photo-histo... levels go from (almost pure) black to pure white. 2: record mode... the black and white values get shifted (blacks and whites get "compressed"). 3: play mode of the respective shot with RGB histo... levels do NOT go from 0-255. Only levels within 16-235 are utilized.

    BTW: technically rec709 video levels always live within a 0-255 signal ... but only the range from 16-235 Y' is actually utilized for image content (exactly what the RGB histo below shows). There is no "color space" or "profile" that cuts off levels below 0-16 and above 235-255 (at least not that I know). This is why "rec709" is a very misleading term. re Avid: again, Avid's import-setting "rec709" simply means: no remapping applied / original levels are preserved - either way wether the original levels go from 0-255 Y' or from 16-235 Y' or from 7-45 Y' or you name it. Obviously AE behaves different in this regard. But again, who cares. The GH2's histos say it all.


    edit: Avid's RGB histo of the respective file matches the exact same levels as the GH2's RGB histo. Strange, isn't it? I think I have to re-think my workflow ...

    1-scene.jpg
    800 x 533 - 112K
    2-record.jpg
    800 x 533 - 121K
    3-rgb_histo.jpg
    800 x 533 - 107K
    levels.jpg
    1920 x 414 - 170K
  • @towi I know what you're talking about, and I've seen the histogram shrink when I hit the record button. But whatever's going on there, it doesn't dictate what's actually in the MTS files. But who cares what a certain software encodes into the file, right? So let's put it this way: In your world, where everything complies with the Studio Swing Rec. 709 standard, all levels stay within a 16-235 range. The rest of us will just have to deal with what we see and what we get.

  • cool - so be it.

  • its my first post here so please be gentle with me! :)

    i just wanted to add that Vegas 10 also sees GH2 footage as only within the 16-235 range (ITU 709). i even shot a short take with the lens cap on to test: of course before pressing REC the in-camera histogram was at zero. after pressing REC it jumped up a few notches (to around 16 i guess) for the duration of recording.

    in Vegas playback and VLC the scene was not quite black but very dark grey (on a well calliberated computer monitor and not a broadcast monitor). the Vegas histogram and waveform monitor show the level of the black to be around 16 (histogram) and %7 (waveform) respectively.

    all of this is OK for me. i know how to deal with 16-235 levels in Vegas when i need the full swing ouput.

    but its just that LPowell's contention that GH2 uses the full 0-255 range has made me think that maybe i have made a mistake with my all my footage previously.

    does anyone have a final answer? are GH2's levels 16-235 or 0-255? (my experience and all i have seen tell me 16-235!) any word from Panasonic on this?

    many thanks (also for a fantastic forum and to VK of course!).

  • Tried this patch this morning for MJPEG timelapse of sunrise. Congured frame rate in ptool to 2FPS. Set shutter to 1/2 second. Very pleased with result. Problem was I was only able to record for 40 minutes (1.86GB) onto 64GB Sandisk Extreme Pro card before recording stopped. No error message. Just stopped recording. Footage is fine. Has anyone else experienced short recording times with MJPEG at 2FPS?

  • @rorykane : Try this: http://www.personal-view.com/talks/discussion/2135/gh2-2fps-avchd-timebuster-settings-the-day-is-not-over/p1

    If all goes well, I'l be releasing 2.0 tonight. I'm just short of computing which base QP does it need to reach 24h. There will be two base versions, one for 24p and another for HBR. For each one I also plan to publish a FlowMotion merged variant.

  • @duartix Thanks for the tip. Look forward to 2.0

  • @mozes is correct!

    female humans, by nature have more fat percentage in their body..

    silly, right? dead wrong.

    fat is an amazing conductor of electricity; as we all know...

    females have higher fat content in middle of brain from birth..

    therefore,

    the two hemispheres can communicate more effective and give 0 - 255 colourspace, whereas males is 16-235..

  • @theojo

    HOW DID U GET THAT SCREENSHOT on p.7... thats lil wayne!

  • @LPowell. Lee, you have had one of the best all around settings in Flow Motion 1.1. I am hoping you are working on a new release based on the new scaling and quantization tables and what we have collectively learned so far.

  • @Siddho The GH2 outputs 16-235 within a 0-255 space. Also, in reference to all the general 'adjustment' discussions, IRE is NOT RGB.

  • I've experienced some crashing recording at 720p60 with auto-exposure, auto focus, etc. on a SanDisk Extreme card (30MB/s). Is this normal?

  • 720p60 crashes on SanDisk Extreme Pro 45MB/s cards, too, manual exposure, manual focus with Panasonic/Leica 25mm D. To address the 720 issue, which setting should I start with?

  • @Siddho Vegas 10 will typically do a behind-the-scenes conversion of AVCHD video files into 16-235 Studio Space, but it depends on the codec and it's not always clear what to expect. If your project is in 8-bit color mode, all AVCHD videos will be converted into Studio Space 16-235 range, regardless of what the file actually contains. Here's a link to extensive details on the pitfalls of color management in Vegas:

    http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

  • @CurtisMack. You can increase the value of the quantiser for 720p. Originally, LPowell had it at 18 in Flow motion 1.1. Then he changed it to 20 in Flow Motion 1.11 for failsafe. If yours is still failing with 20, then increase it to 22. However, as you increase the quantiser value, you reduce the resolution and bit rate.

  • @lpowell could you please post an example of an mts file that exhibits the behaviour of containing data outside of 16-235 ? Sorry, I can't drop this because you have made a lot of people question their workflows, workflows that there probably isn't anything wrong with.

    Your pedestal 'fix' ,if such a problem existed, would be not the best approach to take, and would result in posterisation further drown the line. I still don't see how the example you posted could not be explained away as a simple blocking/posterisation result from the codec. Also IRE is not RGB, its a very old analog representation of your range from black to white, what you see there is an interpretation of the digital and not a measure of the amplitude proper. Frankly, a Y/C waveform is not the tool for monitoring digital color correction at all, but thats a whole other can of worms, I'm digressing. If you look at your RGB levels/histograms and see something below 16 then that would be the 'smoking gun'. Also if your shot doesn't ever reach down to zero IRE accross its frames (especially likely if you ETTR), what do you make a pedestal adjustment against then ? If you don't make one in those cases then you shouldn't be making one at all. The applications being used, if they do get it wrong, can be forced to reintepret the footage correctly.

    Why not fix that leap in that shadow instead by adding a very, very, tiny blur through a roto mask. Or you could even make a mask by inverting a luminance map and pushing up its levels (threshold/clamp etc) so it only covers the deepest shadows where the problem occurs. There are many ways to deal with that kind of problem (and I have seen it myself), and none of them involve knackering your dynamic range.

    Edit : Remember the IRE in that Y/C waveform your looking at is based on what you've told it that its looking at range wise.

  • @lpowell

    you are right of course. in Vegas choosing a 32bit float full range project decodes the mts files to linear range (0-255) and choosing a 32bit float or 8bit vider range project (2.222) decodes them to studio swing (16-235). but judging by the massive hit which my CPU takes when working in a linear range project Vegas is actually expanding the 16-235 levels to 0-255. also, every other program which i have used to view those mts test files (of a black image recorded with the lens cap on) show the black level to be around 16 and not zero!

    why would otherwise the in-camera histogram also jump upon recording to around 16? that must surely also be a pointer that the GH2 is using ITU709?

    is there any way to objectively judge the cameras levels bypassing how certain programms decode thsoe levels?

  • @Siddho

    "is there any way to objectively judge the cameras levels bypassing how certain programms decode thsoe levels?"

    Yes. Look at the camera's histos in record- and playback-mode.

  • @Siddho When working in a linear mode it would actually be expanding it to a float range of 0-1. What it should be doing is taking the 16 as zero and the 235 as 1. So your RGB values would resemble the red green and blue numbers below the viewer in this screen grab. those numbers are the average of the values in the red marquee.

    linear_screengrab.png
    1175 x 828 - 926K
  • @towi & @Stray

    thanks for your informed posts and replies. all the tests i have done confirm your points. glad to know my workflow hasnt been wrong.

  • @Stray Yes, please download the MTS file that I posted last week at the top of this page, it contains the smoking gun you're looking for. As I've pointed out, however, you must verify that your editor is not surreptitiously converting the file's luma components to fit within the Studio Swing 16-235 limits. That built-in conversion is what has been causing the confusion as to what's actually encoded within an MTS file.

    Your point about IRE levels not being technically applicable to RGB levels is of course correct. In an ideal workflow, the notion of a "7.5 IRE Setup" would remain a videotape/broadcast adjustment added to NTSC analog output signals that would never encroach into the digital domain. The reason I use IRE terminology is because that's what NLE waveform displays use to label their luma charts. "7.5 IRE" is also an unambiguous way to refer to the Studio Swing black level offset, whereas "black level at 16" is only correct for 8-bit color spaces, which have quickly become obsolete. (For example, the reason that Pedestal adjustments do not cause the posterization you mentioned is because there are no significant round-off errors in an NLE's internal 32-bit color space.)

    Basically, what my recommended pedestal adjustment does is crush the noise and artifact-contaminated bottom end of the sensor's range into solid black. The luma components that lie just above that threshold are legitimate image details and the pedestal adjustment fades them gradually, rather than raggedly, into black. When you then boost the gamma, you get smoother shadow gradients as a result. (There is sometimes however a saturation issue with dark shades that I'll try to find time to illustrate in a later post.)