Personal View site logo
"THE PATCH" - for GH2 Hack - Developed by APEFOS
  • 128 Replies sorted by
  • 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 excellent test, you know how to do it. curious to see iso 2000 and 6400. 2000 is the maximum before sensor flicker, 6400 is the maximum usable.

  • @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.

  • @apefos Thank you for providing a detailed description of your patch development. It was above & beyond what I was expecting. Now it's time for me to do some testing.

  • 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.

  • Maybe it will be better we show the tests and allow people to do their own conclusions instead of say what we like most, this way all people will feel free to do their choices, because all patches can be good for different purposes and for each people taste. Instead of find better, it is more useful we consider different options, better will always be a "personal-view".

    about high iso, from iso 160 to 2000 I see no flickering, flickering starts in iso 2500.

    strange thing: iso 2500 is showing more flickering than 3200 in my tests, I do not know if this is a iso bug. I perceived in my tests iso 3200 shows less flickering than 2500, strange thing. If 3200 is ok I think the patch is ok, but I can be wrong. I even like 6400 more than 2500. 6400 after denoise is better in terms of flickering compared to 2500 in my tests.

  • 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).

  • Hey what's up @apefos I see you still @ work on the patches. I recently sold one of my GH2's and my other one was sent-out for some repairs. Soon as I get it back gonna be testing away that's for sure keep up the great work.

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

  • @producer I can't find nothing else to do... Now it is time to see the tests.

  • 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 :)

  • To make things more easy for people to find the final version and avoid mistakes and confusions, I created a new topic for the "The End" patch which is the final version, with full description.

    http://personal-view.com/talks/discussion/12645/the-end-patch-for-gh2-hack

    if you test previous versions post here, if you test "the end" final version, please post there.

  • @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.

  • @apefos yes I will probably post to vimeo once I have an good comparison clip. If I find a good method for youtube I will do that as well.

    Also the iso noise bug has a topic made about it in this forum somewhere. 320 iso is still okay in your patch, or any patch. The problem is when you switch from 160 to 320, the 320 will now have worse noise than even 640. Simple fix is always go from higher iso to lower before recording. Switching from 640 to 320 will make 320 look good again. My problem was I forgot about all this when testing all the patches. I had already finished half of them when I remembered and decided to keep testing anyways, with the iso bug being recorded. So what I am saying is your patch should have no problem at 320 iso, unless other people forget about iso bug switch but that affects all GH2 and patches.

    And I have good news! I am still testing but right now I see more detail in The End than any other patch... Moon T8 is close but not 100% match and even takes more post editing to show extra detail. The End shows more detail straight from camera. Still testing to comfirm these results. I will update The End topic when I confirm this.

  • @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.

  • @Manicd I saw your first video test again, in another monitor, Samsung. This monitor shows better the dark areas. To my eyes Sanity X is the best image, then comes Canis, Moon T8, Intravenus v2. Strange thing, but The End is the worst for me. In my real world shots I like it so much, but in this test it is the worst.

  • @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.

  • @Manicd no problem, maybe my development is bad, sometimes we need to recognize a fail... the goal of your tests is to show the truth, this is important for the PV members to chose a patch. I did my best, I see no more things to do, but it is no good, unless the test is not well done, but it seems you did it correctly.

  • @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.

  • @Manicd it seems to be another problem, not focus. the image from the end seems to be recompressed a lot, some shadow raised also. in my tests i cannot see the same level of compression and macroblocking in dark areas. but maybe I am wrong, who knows. Maybe my settings are no good for iso low iso...

    the important thing is: there is nothing else for me to do. i did my best, now is time for people to test and choose.

    it is time for me to be away again...

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

  • I tried quite a few of these settings but didn't like the overall image. Although some scenes had less noise it was at the expense of detail and image quality. When shooting high ISO the image was unuseable like most gh2 footage above 800 ISO. I personally use my gh2 as a backup camera but perfer it sometimes under perfect conditions. it is far from use able under poor conditions. I tested your hack along side another gh2 on my cameras previous hack only in 60p 720p through all picture styles and found that although the picture has less noise the image is still so bad above 800 iso and not really improved in the gh2 sweet spot at 320iso. If you want better dynamic range and lowlightperformance I think the dual ISO hack is the only option but, nothing is better than proper lighting tho

  • Thank you for your time and effort sorry about my english

  • What do we want from our gh2?

    1. This is a photocamera, not a telescope. The Gh2 is sharp, but not that sharp.

    2. If a client ask me for a video, I don't want a noisy, flickering, artifacted product to show.

    3. If I shot an interview, I don't want a stop in camera while working. I don't want to use unstable patches.

    4. I need both, good quality Hbr and 24P modes.

    5. I need a trusted color palette. This is a difficult issue, where the gh2 seems not to be so good as a full frame photocamera.

  • 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.