How about small app that could load png, set levels and plot unscaled histogram, and in the case of multiple files, plot 3D waterfall also? May be we'll find someone who'll be able to make it?
Note that Photoshop auto-scales the histogram. Although the peaks look the same size, they're not - they are actually lower for the high bitrate settings.
The 66M sure does push the data to the left a little bit, couldn't really tell until it was blown up. I'd like to see 88+ on this histogram to see if it makes even more of a difference.
Thanks for posting those histograms, sure makes more sense to me displayed that way.
The chart I attached is just a thumbnail, so it won't work. The actual chart file is big (15MB+). It has to be printed using absolute colormetric color management settings and with a very good printer (I used an Epson 4800 with the Colorbyte RIP). If you want, I'll upload the file to you. No way it will work with most people's email.
I have a resolution chart as well, if anybody is interested - it's even bigger:
I have 48-bit super high-res version Photoshop files too, but they are 300-400MB each.
Capture (make sure exposure is exaclty right) - import to editor (I use Vegas), export frame in lossless format (like PNG, not JPG). Import frame to Photoshop. Set levels to 0-31 (approximately, to spread out shadow details). At this point the image will look terrible. Use Photoshop's histogram tool. The chart you use should have a mix of detail stuff (like resolution targets) and (this is important) gradients. The GH2 camera outperforms most (if not all) printers, so you will see a quantization artifacts that are actually caused by the printer.
@mpgxsvcd Print out the testchart, take video clips, extract frames, import into photoshop or lightroom, and capture the histogram chart? Not sure if editing tools like Premiere Pro has a histogram.
@cbrandin Thanks for showing us how to do such technical tests. I'm sure some of us who can't bear to find out more stuffs would test out more cases :)
Yup. Although sometimes P frames also get QP+2. The most common pattern I've seen with real world subjects is I=QP-2 to QP+2, P=QP, B=QP+2. The base QP appears to be decided at the beginning of each GOP and can vary according to image characteristics (motion, light changes, etc...). The QP setting in PTool determines what the lowest value can be - and you'll see that commonly reached with highly detailed static subjects.
I could, but it takes a lot of time to do there tests. I just did this test to prove, objectively, that quality does indeed improve with 1080p. I chose that because the 1080p rendering is already so good that the difference is less obvious than with every other mode. Running more tests seems like gilding the lily.
Lower QP (higher AQ) will always improve quality - that's the very purpose of it and the AVCHD standard states that unambiguously. I just wanted to prove it empirically for the skeptics. I think I have done that. At this point I think it's reasonable (ridiculous not to, actually) assume that the GH2 codec behaves like it is supposed to when quality is raised. If it behaved any differently in another mode, like 720p - well... that would be truly bizarre.
I'd rather focus on other things now - like loop filter adjustments and film modes, for example.
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.
@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 :) .
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.