Personal View site logo
GH2 Hack Technical Tests
  • 69 Replies sorted by
  • @proaudio4

    Yes. It's not just the black part, though - it's the density of all vertical levels of the histogram as well. The less sparse, the better. With crude quantization you'll see a small black part and sparse lines. As quantization improves energy is reduced in the tall lines and allocated to the somewhat shorter lines in between.

    Chris
  • @cbrandin
    I hope you understand a little bit, but as you know, in the audio, the same effect you get in different ways;-)
    So ( my reasoning), our desire is to maintain the lowest QP, but we must limit the bandwidth allocation in order to have enough for a proper mapping of motion ? Is there such thing as a bandwidth allocation limiter? ;-)
  • @cbrandin"Unfortunately, it isn't that simple. The dynamic range isn't necessarily affected, it's the quality of rendering within that range that is. "

    Spot on.
    This is the difference between image latitude verses dynamic range. Chris is right, this will not improve the overall dynamic range, but will improve the quality of useable image in low IRE as it rolls into the black level.
    Again, Nice test Chris!
  • @vladnik

    true... theoretically. The GH2 codec, however, uses pre-calculated parameters and hard limits, so assumptions about how things are calculated on the fly per the standard often do not apply.

    Chris
  • @cbrandin"If you look just at the left part of the histogram you'll notice that 66M is doing considerably better; it's in the other parts where it doesn't seem to make much difference, which makes sense to me."

    +1
    You're refering to the low IRE side of the waveform, correct?
    Yes, it appears to be rendering more useable image data; hence, the thicker dark part at the bottom left.

  • @cbrandin

    As the test is static, I suggest different approach.
    Fix bitrate at something like 66Mbps.
    And step from 25(worse than default) down to 0 quantizer using manual patches.
    And plot 3D waterfall from histograms using this approach.
    Same as used to measure loudspeaker resonances.
  • @cbrandin
    in full implementation h264 if you set constant qp you can not control birtate.
    codec takes how much its need .
    like qscale in canon hack.
    plus low qp values lower loop filter .
    i m not sure but i think that aq has tendency to allocate low qp values in the shadows and flat part of frame like sky.
  • @Mihuel

    Unfortunately, it isn't that simple. The dynamic range isn't necessarily affected, it's the quality of rendering within that range that is. This would show up in scenes where a macroblock contains both high contrast and subtle features. The codec will scale the macroblock to cover the total range, but because of high quantization the subtle parts will suffer.

    It's like trying to understand how filters work in audio - they operate in the frequency domain so it's very difficult to conceptualize in the time domain, which is more intuitive.

    Chris
  • @vladnik

    I have no idea... I suppose it would be possible to determine what the lowest QP setting that makes any difference is. At some point there will be a diminishing return where additional quality is wasted. Aside from that you would have to do motion testing to determine when it suffers because so much bandwidth has been allocated to low QP (high quality) macroblocks.

    Chris
  • @cbrandin
    Does this mean that the larger the bitrate the higher dynamic range of the image? (Sorry, but I'm a sound engineer, and these criteria to my reasoning)
  • @cbrandin
    what do you think is lowest possible qp value for 88 mbit and to codec preserve the integrity.
  • @proaudio4

    If you look just at the left part of the histogram you'll notice that 66M is doing considerably better; it's in the other parts where it doesn't seem to make much difference, which makes sense to me.

    Chris
  • @VK

    I assume you mean the lowest possible value (which means highest quality). No, I haven't tried that yet. I thought using the AQ setting would be most useful for now. I'm pretty sure there will be improvement up until the limitations of the camera and 8-bit data have been met. If I set QP too low, the codec will have problems keeping up with motion - which this test, because it is static, will not show.

    Chris
  • Great test. Thanks Chis. This just confirms what I'm seeing at 66Mb/s AQ4; Although, it certainly appears 44Mb/s AQ4 faired very well. Hmmm..
  • @cbrandin

    Did you tried manual quantizer set to highest possible value?
  • @sohus

    I ran several takes, and the results were utterly consistent. That's the purpose of "controlled" tests, after all.

    Chris
  • The crops are even more difficult to get because they are the lower 32 bits expanded to full range, which is really ugly because it just shows the limitations of the printer I used to make the chart. The test was designed for the purpose of making technical measurements - visually it doesn't show anything understandable - that wasn't the goal.

    I guess the best way to explain the histograms is to say that the more lines you have the better. Also, the smaller the ratio in size between the lines the better. Finally, the fatter the dark part on the bottom the better. With AVCHD, you will always get quantization artifacts - that's how it works.

    Chris
  • Great write-up Chris. Do you get the same result each time or do they differ between takes?
  • Thanks for tests, Chris.
    May be you have also processed crops to show for average user (you know, histogram is kind of hard to get :-) )