People are asking about the developing history and myy tests, here is a summarize:

In first moment of hack I just did datarate increase to improve the image without using the tester section of ptool. Problem was I was not satisfied with 720p quality, lots of macroblocks in dark areas.

I did attempts to increase datarate and lower the gop of 720p but camera was stop recording (sandisk 45Mbps card). So only thing I did at that moment was to use 42Mbps in 720p and 24p.

So I did a reseach about patches and I liked the FlowMotion description a lot. So I did a try. I liked the image, but camera was stop recording some times, also I found the noise to be gross.

People suggest me Nebula, I did a try, noise more fine I liked it, but for my taste it was too much fine. I would like something in between. Also Nebula was showing high changes in frames size in streamparser while flowmotion was very constant frames size. After researches and reading on topics I learned that the main matrix and fallback matrix and also gop tables was important to keep constant size on frames and flowmotion was good on this, but at that moment the numbers in the ini file about matrix was a mess to me, I never thought I could understand it.

I did a try on some other patches also, but the settings was not so fine tuned when I look in the ini file.

So I start pursuing my own settings...

I decided to start improving flowmotion because it was the best tweaked patch at that moment, so I started to believe I could make it more stable.

First thing I did was to adjust datarate and top and botom limits to find more stability, also I did lots of tests with the frame limit size and frame buffer size to find better stability. So I made the camera record without stop and freeze, this was the first important achievements using flowmotion as a base. The frame limit needs to be a little higher than the frames the camera generate, to tell to the camera that it will work with something with that size, It cannot be used to make the frames lower in size. If it is lower than the frames size the camera freezes. The buffer also big to handle the data.

Then I did some tests in low light to see the image noise/texture. when I say texture it is the word I found to include artifacts, banding, moiré, lines, noise, aliasing, flickering, and so on, the result of all them.

To see better the image I started to see it in 400% zoom and frame by frame. First thing I noticed was the P and B frames was poor quality, mud and artifacts, so I lowered the 720p gop to 3 to have more I frames and less P/B frames, in a maximum datarate I could use, 96Mbps was recording ok after the frame limit, frame buffer, bottom and top adujsts.

Then I started to think that the B frames could be worse than the P frames because B frames uses bidirectional temporal compression and are smaller. I asked for some help in forum and some members teached me how to make the 720p to be only I and P frames. This improved quality, P frames are biger than B and better temporal compression. This was the WorKHorse patches era.

So I got the idea to share better the datarate between the I and P frames in 720p and between the I and B frames in hbr and 24p. I did researches and learned that the GOP Tables was the settings to do this. But it was a deep mistery, nobody knows exactly how it works.

Then I did tests. Lots and lots of tests loading many firmwares to the camera, changing each number in the gop tables to understand what they do to the image. This way I found the behavior of it, not everything, but enough to do a good share of data among the frames, more data to I or more data to P or to B. Also gop tables are very important for stability.

In my tests I found the minimum size of the I frames and P/B frames which allow good compression without introduce mud, artifacts and mosquito noise. This was important to do a calibration between datarate, gop lenght and gop tables.

I perceived that I had two options, prioritize the details in good light with biger I frames or prioritize noise quality with biger P / B frames. So I created WorkHorse for details with biger I and Boson patches improved more for noise performance with biger P frames.

In NTSC 720p it is 60 frames each second and the datarate is in the limit to get a good size on the I and P frames, so I did a careful settings on it. If I rememenber correctly this was the GSpot patches where I found this perfect point for good details and noise in same patch with a finetune in I/P/B frames in all recording modes, pal and ntsc adjusting carefully the gop tables for all.

At this moment I perceived that the 24H and 24L could have different datarates, but the 720p SH and H could not. The SH and H have a different behavior, they change the amount of data between the I and P/B frames also and in the GSpot patches I tweaked SH more for noise and H more for details in good light. I foud a difference between SH and H datarate typed in ptool which made this to work. I called it H-Switch. Also the datarate configuration is important to make camera stable, not only the amount of data, but the difference of numbers in the recording modes needs to respect some difference limit to avoid stop recording.

In terms of time, the 720p50 gop3 and 720p60 gop 4 makes each group of P frames to be on the screen almost the same amount of time, so the noise/texture is similar, so gop4 for 720p60 was a good idea to make the I frames higher in size, a good solution.

One thing common in PV topic is people testing different memory cards to try to find a fast card to avoid stop recording. the card does not do this, this is done by the patch. a fast card will not improve camera stability if the patch is wrong, it helps but a little bit. After all developing the 95Mbps card makes little difference compared to the 45Mbps. Yes it can help using a higher datarate but not enouch to avoid stop recording some times if datarate is too high. If the patch is ok, most cards will work.

The GH2 has nice auto electronic features. OIS, iDynamic, auto focus, auto exposure, and more. Also native lenses uses some camera processor. I would like to use them so I did a try in different datarates and differences between the record modes to allow these features and lenses to work without stop recording. And try to get the best image under this datarate limit. And to have another patch with a higher datarate to use without the features and with manual lenses. But in "the end chroma luma denoise" I found the datarate stable to be good enough.

All the developing was done always using streamparser to see the frames behavior and doing tests on the death charts and death charts movie which allow to perceive if the camera will work without freeze and without stop recording. Also tests in low light and daylight real world and tests in green grass which is also usefull to stress the camera.

Then I perceived that I would need to understand matrices, the last thing to do. In a humble way I asked for help from the masters of hack. They showed me books and white papers about H264, and I did lots of reading to understand. After lots of study I understood matrices and how they work. I also learned a lot about DCT, discrete cosine transform, in wikipedia.

In my study I perceived that the DCT frequency must be respected to get a good image without problems in texture and most patches did not respect this. So I created the DCT patches with different DC numbers and matrix design with different noise/texture.

The DC number, it is the first number of the matrix which is important to determine all the matrix behavior. I found 6 to be the sweet spot for the noise /texture quality between fine and gross. So I started to try different matrices always with 6 as first number.

Then my intuition told me that It would be good idea to use same frequency increase or near same frequency increas in all matrix numbers, and also to use numbers multples of 6 or 3, numbers with a commom denominator.

This new design made the camera very very stable, and finished a problem that previous matrices had. Before this matrix tweaking the on screen information on the LCD used to be delaied, maybe due to the camera processor being stressed doing image compression. This new matrix desing made the on screen information to be ok, without delay, so I perceived that the camera processor was no more stressed.

Also my intuition told me to use same matrix in the intraframe and interframe which saves data for the temporal compression, to get a better texture with same quantization and design in both, and less work for the camera processor. also same design in fall back.

Another 400% zoom frame by frame in lots of matrix design showed me the best configuration to compress the image without mosquito noise, without artifacts. this was the Apefos Settings topic era.

When I found the best matrix desing I started "The Patch" topic because I was believing I had found something I could keep in the camera and no more firmware changing.

But then the iso problem showed up. One matrix design was better for low iso, another for high iso, because lower quantization shows better textures, but cannot handle heavy noise without artifacts. and higher quantization can handle heavy noise, but muds textures in low iso.

The fallback idea comes to the mind. The camera uses the fallback tables when the main matrix cannot do a good compression, so it is possible to have two matrices working together. Then I did tests to find which matrix to keep as main and which matrix to keep as fallback, and also with ideas from members I developed different configurations for each recording mode considering theyr datarate and needs.

After this moment I perceived the need of tweaking the Deblocking tables, it works to turn macroblock from compression into a texture, some kind of anti-aliazing, or anti-block. I adjusted it using same theory of multiples of 6 or 3 with common denominator, after doing study about deblocking in other patches and in the original firmware. More tests to see in 400% zoom to do the deblocking without introduce mud.

For my surprize the correct settings in deblocking tables cleaned the diagonal rain pulsing pattern. A gift.

The Denoise patches also was developed from members idea of to have a patch with clean image, so I developed matrices to reduce noise, increasing quantization in first digits and using same numbers to try to flatten the image. Good results in denoise, but without the dct frequency to get good texture.

A final tweak was to learn again from flowmotion, moon and denoise, to compare the matrix desing and to create a new matrix and fallback to do everything, good for all isos, with good denoise and good texture, a small increase in quantization in first digits, keeping dct frequence increase, a high quantization in chroma last digits and so on.

Maybe I forgot some things in this history, but this is a summarize.

"The End"

@Manicd to my eyes "The End Chroma Luma Denoise" is doing the denoise job without hurt the image. What do you think?

I would like to know other people opinion also.

Thanks.

I only recorded 160, 320(had iso bug, no good), 640, 1250, 2500, 6400, 12800. If there is no clear choice of patch from this testing, I will redo using different test subject and with wider range of iso's.

At first I can tell the differences between all patches but after awhile my eyes and brain could no longer see. I spend too much time editing and staring at each clip...

Edit: I look again with fresh eyes. Is still hard to tell, even watching in editor before any transcoding. The End CLD does look good though. I will start editing the higher iso's soon.

I agree about a personal view. (Unless their personal view is clearly wrong, then I will tell that person :)

The 320 iso bug appears to affect all patches equally. So if any iso bug shows at 2500, it will be equal problem but some patches maybe worse than others. We shall see. I have not started to edit clips yet. I eat all food in house instead, much better use of time.

Does vimeo have better compression that youtube? When I finish all iso's edits I want to upload easy to watch video. Maybe start a new company for best video quality on the internet. There is already Divx player which can play very high quality h264 and h265 in browser but not everyone has or will install divx or similar plugin, which is needed to play those videos. For youtube, vimeo, and other sites you can just play video (most people already have adobe flash installed or html5 ability).

@apefos: The only thing I miss in your brilliant patches is a higher sharpness. Much higher sharpness!

Hi,

Great to know that there's a new patch for the GH2 going on. Thanks for this!

I couldn't find any info about GOP (it's 1, 3 ,etc...). I usually use Moon (GOP 1) or Valkyrie 444 (GOP 3) for pro work. Sorry if this was also answered before, but what's the main difference between this patch and i.e. Moon, Valkyrie, Flowmotion...? Low-light, colours, etc...

I'll try this patch. I love my GH2, except going above iso 1600 with no light :)

@Manicd Uploading in 1080 to youtube and vimeo can be similar results, maybe vimeo has a higher datarate in their compression, but I am not sure about this. The upload you did to file sharing is much better to perceive quality, datarate will always be higher this way, we can download the rendered file, less compression for the tests. Vimeo is a community more to indie film/video makers, so uploading to vimeo and add the video to GH2 channels and groups is good idea also. You decide.

@Manicd thanks for the iso bug advice. I did a read in the topics about it and I learned how to set the isos correctly. Now iso 320 is looking wonderful, to my eyes the image from iso 320 is ok straight from camera, no need denoise and already have a beautiful grain and gradients.

Waiting to see your tests which are very helpful. Take the time you need, no hurry, so your conclusions can be ok.

I am using Smooth as the film mode, with contrast 0, sharpness -1, saturation -1, noise reduction -2. It raises shadows a little compared to Cinema film mode. Just to say my preferences and taste... Share yours if you want.

Contrast sometimes I lower it to -2, Sharpness is giving me a good balance between sharp and less aliasing in -1, saturation is just my taste, noise reduction -2 shows better the sensor texture, in my tests I found that increase noise reduction in camera muds some areas.

@apefos All my video is now considered invalid. I found good evidence that my manual focus with the 14-42 was not good enough. There is small different in focus between some of the patches I recorded. It's easy to see with full screen image of each clip but I pay too much attention to pixels instead of the entire image. So the clips I uploaded cannot be used. Sorry.

I have a 50mm canon FD that I will use now but will take awhile to test again. I will start by first comparing Moon T8 and The End to see if worth continuing the tests.

@apefos My testing was not correct. Each patch I loaded reset the 14-42 lens focus. I had to manually focus for each patch. I thought I could get good enough results but there is too much difference in the clips to be useful for true comparisons.

I have a 50mm canon FD that will keep the same focus between each patch loaded.

@apefos Well thank you for the patch work you did and enjoy your time away!

Thank you for your time and effort sorry about my english

Just a final word: I did more shoots to confirm if the image has mud or macroblocking, in high and low iso, and in good and low light, and I could not see significant problems.

So better thing to do is to trust in your own tests instead of other peoples tests. Do your tests yourself.