@icp Thanks.

Your Valkyrie screenshots are interesting. I was under the impression nothing could compare to the moon series. Although is hard to tell if the front "wood" of the record player is noise or detail in the moon and if valkyrie is better or worse in that regard. Was this room isolated from outside light sources that could change?

Also I have to agree, when I redid my testing of moont8 vs End with a manual lenses, the mud and marcoblocks became visible, even without much zooming. Which is sad because I really like The End's low noise, the image looks great straight out of the camera but when comparing you can see the lose of detail in shadows or flat areas. I wonder if the patches before the denoise matrix was added are any good. I will have to compare some footage I have of apefos's other patches. Will post any notes I find in a day or so.

What film mode would you recommend using with this patch? My personal gh2 looks nothing like the arri Alexa I use. I can't even grade the footage to look anything like it. Possibly a superior colorist could grade a screen grab but the dynamic range and dof seems very different along with how the cameras handle motion at the same fps and shutter speed. Any help would be appreciated I've tried almost every patch on this site and a few custom patches from friends

Recently I saw two movies on theather: American Sniper and 50 Shades of Grey. In IMDb website it says both was shot with Arri Alexa.

The End patch looks very similar to the image noise and texture from these movies using iso from 320 to 2000 when using these tip:

Keep white balance in 3100K, it shows less chroma noise. Above will introduce red/magenta noise, below will introduce blue noise.

Use these filters based on light conditions: 85B, FL-DAY, 1A, FL-DAY + 1A

use the iso bug correction: 320 down from 400, 640 down from 800, 1250 down from 1600, 2000 up from 1600 works ok also. 800 and 1600 also good. 320 down from 400 is the most beautiful.

All development of the end patch was done using 3100k white balance, this is one secret which makes difference.

This WB tip + filters + the end + GH2 + iso tip = Arri Alexa

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.

My last post for a while, I did my best and I will keep away again for other tasks: pay attention to the results from this patch, I like the images from it, but in the tests in the the patch topic it is showing the worst results among other patches tested, lots of recompression mud and macroblocking in dark areas, so do your tests before using in a professional work. test from @Manicd http://d-h.st/SLyb

Did a test now, with the RJ focal reducer, and the Nikon 35mm 1.4 stoped down to 2.5, in iso 320 down from 400 do avoid iso bug.

The image is looking wonderful in 24p, 30p and 60p!!!

I am very happy with the results.

I am using the stable version, not the high. Only HBR 30p makes me to want to use the high datarate version, 24p and 720p are just excellent in the stable default version. There is no way to make only HBR to be higher datarate because the settings changes 720p also, and increasing datarate for 720p will hurt the stability of the default version. Maybe in PAL the HBR in the stable version will be excellent also due to be less frames and a little more datarate compared to NTSC. But this is subtle, in flat surfaces.

Comparing the datarates in the recorded videos in the computer, the camera generates less datarate for HBR compared to 720p, 1,15x less datarate for HBR in same scene. Also HBR pixels and frame rate is more information, 1,125x more than 720p60. This results in something around 1,3x less datarate per pixel and can explain the small difference in HBR quality. So yes, the high datarate version can be useful for NTSC HBR 30p shooters. PAL HBR maybe can be ok in the stable version, due to less frames (25p) and the camera generates more data to it, I believe PAL HBR compensates this 30% difference.

I used sharpness -1, I like it most.

It seems for iDynamic enabled, with the 14-42mm lens, iso 160 is better for less noise, needs more tests.

I have a question about the audio. Does your hack include "thepalalias" audio settings ???

Developing History (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 popular 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.

The 24p and HBR modes was also tweaked, not only the 720p, using gop 3, good share of data among frames, and datarate at maximum limit for stability.

These adjusts helped the recording modes to have a similar frame rate perceiving in all areas of the image, similar to intraframe gop1 patches. SlowMotion becomes much better due to this.

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"