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

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"

Last setg with denoise improvements, my tests with neatvideo conclusions:

avoid iso 2500 it shows flickering in hbr and 24p.

720p does not show flickering, good up to iso 6400.

the image up to iso 2000 is pretty good in all recording modes, including face in low light.

neatvideo performance shows less trembling using temporal denoise "1" and luma spatial denoise 30, chroma spatial 100, and chroma +50 in first sliders, selecting the area in a fine grain instead of a gross dark area works better:

neatvideo works ok in iso 3200, can be useful for low light.

iso 2000 and below is just great after denoise.

isos 4000, 5000 and 6400 denoise ok if you need to get the shoot, also works, some film grain in post can save them, excellent results considering it is the old GH2.

avoid iso 2500 in 24p and hbr, shows flickering.

@haribabis nice test, you are the cave man! It seems all of us are... just some sense of humor. did you use the last setg with denoise improvements?

@Manicd Of course. And I appreciate!

@apefos You have been doing these patches since last year with many changes and information about superb image quality etc. I would like to know how you evaluate the image quality and if you have any comparative tests to show the differences between versions.

I did it, best noise reduction in luma and chroma.

The stable version is pretty good, I think there is no need to use the high datarate version, but it is here also.

Matrices improved with ideas from denoise patches and moon, also flowmotion, not a copy from them, a new custom design. I also tested a little more quantization than this, but it started to hurt textures, so it is in the sweet spot. I did try in all positions of the matrix, first digits, last digits, respecting the dct frequency in luma all matrix and in chroma first digits, last digits of chroma are high quantization to improve the noise reduction and do not hurt.

It is good to have neatvideo inside the camera!!! (not so powerful as the software is, but very good.)

To my eyes iso 2000 is the new 800.

works for all isos 6400 and below in same patch.

Maximum safe iso is now 6400, iso 8000 starts to show flickering from the sensor impossible to remove.

please users, say your opinion after tests.

@Manicd try water falling from a tap, see

I am doing progress in fallback chroma matrix, iso 2000 is looking like 800

@Manicd you said you have interest in developing patches, please read this topic, if you think you can survive the things in the topic you can do patches:

http://personal-view.com/talks/discussion/11273/firmware-upgrade-things-to-do-while-you-wait

@apefos You are right I forgot to turn on a second light source for moon t8. I can redo it easily. Although I might redo everything for a few reasons, including the mistake of using the kit lens 14-42 which required new focus for each patch loaded. So it is possible for human error to be involved. The other lens I have is canon fd 50mm.

Also I forgot about iso bug 160-320-640-1250. Although only 320 appears affected in my camera.

I have some thinking to do about my testing setup and if I can find a better quality and faster method so that I can include many more patches.

I am unfamiliar with premiere pro, so I don't know everything it's capable of rending out. But I will find something good.

I think I will redo at 300% or 400% crop. This was only 200%.

Here is first video at 640 iso

@frullaccia this is what I was pursuing since the begining, good to know.

About chroma, I did a test now. I increased the quantization in a similar design inpired on Denoise and Moon, but not so big increase, to perceive small differences. The chroma noise becomes small, not so much, but I can see the difference, but the problem is: textures got mud, it flattens the surfaces. It seems there is no free lunch in color, it seems to be a choice between good texture with some noise or flat surfaces less noise. I am trying to find a sweet spot now, in quantization and design, I will priorize texture, less possible noise with good texture.

@apefos I tried a long list of patches before. Now, a screenshot is not a video, and a video, shot in some specific situation, is not exactly what you find when you're working in real world.

While shooting in real world (indoor, outdoor, sun, rain, morning, evening) your last patches are unmatched (considering artifacts, banding, moiré, lines, noise, flickering, whatelse... And texture); talking about chroma, well, maybe some improvement is possible. I'm just supposing it is possible.