Static - All four settings are very close to each other, however I feel 66M AQ3 holds slightly finer detail than the others.
Motion - Once again, very close, but there are differences. 132M AQ2 holds fine detail the best, followed by a tie between 66M AQ2 and 66M AQ3. 44M AQ4 brings up the rear by a whisker.
COMMENT: When it comes to holding fine detail, the static picture is more important one. The eye has time to linger and pick it up. The 66M AQ3 holds the edge here and personally I would like to use it as my standard setting. But there's a problem - for the first time since using the hack, I had an image break up. It lasted about five seconds and then corrected itself. Could a stable version of 66M AQ3 be made?
Lastly, cosimo_bullo requested that I shoot still JPEGS during the tests, which I did. I'll post them after the clips.
Now I know what I want from GH3. 8Mp and 16Mp MJPEG movie format (with 4:2:0 and 4:2:2 option) with two SDHC UHS card slots and simultaneous write (200-380Mb/s). No spanning, exFAT support.
Attached are two 800% jpegs from the 132 motion test. The first are from Ralph's 132 motion test. I'm amazed by how close they look in the shadows around the door.
Really great results and great to compare new settings with HDMI output. This really tells the difference. Would it be possible also to compare it with standard setting to receive a better understanding what is possible between min and max results.
@cosimo_bullo Now I do see that the 132M version is almost identical to HDMI...
I am thinking...would it be technically possible to hack the firmware in such a way that it allows "HDMI recording" directly to the SD card? This may essentially bypass the AVCHD codec altogether and simply store "raw" video. With the Lexar Class 10 128gb card it might be feasible. What I'm suggesting would be tweaking the firmware, adding an HDMI output option "SD" so when selected, the HDMI data is written to the SD card rather than being written to the HDMI output on the camera.
I think the bitrate are enormous because it is fully uncompressed. You need ssd to write uncompressed as with the blackmagic recorder. The Ninja compress them to proress before they can write it to normal 3.5 inch hdd. Now I think the SD would be even slower than the hdd.
It would be nice to see some trans-coded example with 5dtorgb or cineform, because the file size are so enormous (600+ gygabyte per hour if I am not mistaken) that in the end 99.9 % of people would have to transcode to proress, dnxhd or cineform to work with the hdmi output, thus diminishing the quality that the difference would be irrelevant compared to the avchd hacked footage.
I contributed on PayPal tonight and this is my first posting. I thought I would share the video I made with footage made mainly from the hack (Ptool 3.61d). I have a SanDisk Extreme Pro 16 GB card from Amazon that's supposedly rated to 45MB/s.
I shot AVCHD in 720/60fps mode with a data rate set to 42000000, GOP = 3, and AQ = 1. The camera crashed quite frequently and it always required me to first shoot a short 1080 AVCHD before shooting in 720, otherwise a crash was certain to occur. I kept seeing messages about the card being "too slow." When I have more time I will experiment with other combinations of settings.
The movie was edited in iMovie (haven't splurged for Final Cut yet) and some scenes were slowed to 30fps (iMovie reportedly honours the true frame rate conversion from 60fps to 30fps but I have not verified this for certain).
I was happiest with the shots where the camera was held steady on a ledge or table; the handheld shots just didn't have the same crispness, and in some cases, I had to apply iMovie image stabilisation (which deteriorates the details further).
"For yucks, here's one more set of the 44AQ4 pushed in even harder."
Yes, the degradation of AVCHD is quite apparent here, but to be fair, remember this is motion that you're looking at. When you watch this clip playing back at speed it's absolutely impossible to see any of this. It goes by in literally less than a wink of the eye. That's why for this type of pixel peeping, I would put more emphasis on evaluating the static picture.
This is the way an interframe codec works. It first throws away information the eye can't detect. And one thing the eye can't see is low contrast detail in rapid motion.
I tested your 44 settings in rc car track while i was not driving. Result was stunnig. I need faster sd to be able to test yours higher settings, but in a moment i am really pleaced with 44 settings. Those settings worked eaven with really fast movement.