Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
GH2 Hack Technical Tests
  • Lately there has been much debate about whether the hack actually improves image quality. Following are the results of a controlled technical test. Measuring image quality with AVCHD files can be a daunting task, The codec operates in subtle and unintuitive ways. Because most processing is done in the frequency, rather than RGB domain, improvements will not often not make sense with ordinary pixel peeping (because that is in the RGB domain).

    To accurately measure quality improvements you have to see how footage reacts to the processing that takes place when it is converted to the RGB domain - in other words, when it is rendered. For these tests I used this chart:

    image

    In order to make the effect of the raised quality reatures most visible I set AQ to 4 (all to detail) for these tests. Frame grabs were exported in a lossless format to Photoshop. In Photoshop, I used levels to examine image portions in a restricted range in the shadows. Photoshop interpolates values within this range to produce the final image. The quality of that interpolation is very dependent on the quality of the image. It's very similar to how any kind of editor will work. As a reference I also took a still image of the chart using the highest quality the GH2 can prduce and processed the raw file. Following are histograms taken from these processed images. The lines in the histograms show quantization artifacts - you can actually see how fine (or coarse) the quantization is. This relates directly to image quality, and how far you can go with post processing and still have a good image.

    Still Image:
    image

    Factory Firmware at 24H:
    image

    24H set at 44M with AQ=4:
    image

    24H set at 66M with AQ=4
    image

    As you can see there is a significant improvement at 44M and an additional, but not as big an improvement at 66M (mostly in the deep shadows).

    Chris
  • 69 Replies sorted by
  • 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 :-) )
  • Great write-up Chris. Do you get the same result each time or do they differ between takes?
  • 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
  • @sohus

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

    Chris
  • @cbrandin

    Did you tried manual quantizer set to highest possible value?
  • 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..
  • @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
  • @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
  • @cbrandin
    what do you think is lowest possible qp value for 88 mbit and to codec preserve the integrity.
  • @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)
  • @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
  • @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
  • @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.
  • @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"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.

  • @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"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!
  • @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? ;-)
  • @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
  • @Mihuel

    I think it works the other way around - bandwidth not allocated to higher quality macroblocks is made available for other things - like better motion fidelity. The QA parameter sets the balance between the two. I have noticed, however, that with higher bitrates even at QA set to 4 all the additional bandwidth is not consumed by higher quality macroblocks, so even at that setting there are probably still significant improvements in motion rendering.

    Chris
  • @cbrandin
    If I understand correctly if we set bitrate and give constant qp codec will be forced to work in
    that bitrate limits . if bitrate is low we get rubbish.
    and no control over loop filter :(.
    Chris please kill loop filter :) .

  • Thanks for the info Chris... makes sense.
  • @cbrandin
    Thanks,its very very promising :-)
  • @VK

    Interesting suggestion. It seems like a lot of work, though. I'm not sure I want to devote all that time to it right now.

    Chris
  • @vladnik

    I'm looking into the loop filter. It's proving to be a little difficult because Panasonic has implemented it in a non-obvious way, like most things.

    Actually, the codec is not fixed QP - it's more like QP within a fixed range with a fixed minimum. All real time codecs have to do this because the CPU can't keep up with actually trying all QP values. The QP range is typically limited to a range of 5 in I frames, and P & B frames use one value - although the exact value can vary slightly from GOP to GOP.

    Chris