@DouglasHorn ... actually, you may still be missing the reality a wee bit. CS6 is dead according to Adobe for feature additions or any major modifications. The new link from PrPro direct is an example ... it's a very different beast from the one we had in CS6 versions, and that new one is not ever gonna be out in a CS6 update ... as are a number of other things they've added since.

CS6 is locked in time as far as feature sets and functionality go. CC is the only place new features and functionality will be added.

@madrenderman Could you please explain further or provide a link to that solution? I've been following this conversation for a long time and it's the first time someone hints to a real solution.

@DouglasHorn

Nothing to be condescending about, or even actually to 'agree' about. I'm a regular "attendee" over on the Adobe forums as I work using a bunch of Adobe, from Lr on through Prelude, PrPro, Sg, & Ae ... not particularly skilled in them past the Lr/stills side of things, so I to damn well need the help. Been through tons of threads including a lot of posts by Adobe staffers on the entire massive argument over what is Adobe's 'aim' ... what they've actually done, what they intend, and what everybody on the planet supposedly thinks they're doing.

The staffers are all rather direct over CS6 ... period. It's dead as far as ANY new features, it's only being kept going for those who still cannot or will not choose to go to the CC programs. Completely consistent with all the company's public statements also. The ONLY things going out to anyone running CS6 are bug-fixes and still a few codec updates, that sort of thing. Just as they did with CS4 after CS5 came out, but stopped doing when CS6 came out. All new features and GUI things are being developed for the CC programs. Period. One "issue" back you still get some support. Two "issues" back, nope. It will simply stay as is.

I don't have any idea what there is even to disagree about. They've been very clear on this. And the CC PrPro and Speedgrade especially have some major differences with the prior versions in workflow. Which will never go into CS6 anything. And absolutely none of this is my opinion or speculation. It's simply what the Adobe staffers and public statements say ... bluntly, directly, consistently.

It seems I found a way to solve the diagonal rain pattern problem.

I am not sure yet.

I am doing tests.

If I find it I will upload the patch here:

http://www.personal-view.com/talks/discussion/11805/the-apefos-settings#Item_45

Problem is solved.

you need to read all my topics in the top settings section of pv to understand everything

How I solved/fixed it:

I perceived that a grey surface is where the rain shows itself more, so I started correct exposure in a flat grey wall and start to underexpose a third fstop each time from f3.5 to f22 to get a dark image.

the main matrices, (scaling tables) was in a design to be a multiple of 6 or half six in all positions, or it was in a design to be 6 in the dct number and multile of 2 in the other positions. So I did a try to do the same in the deblocking tables, and then the diagonal rain pulsing pattern disappears.

First I set the deblocking intra and inter with 1 (one) in all positions. This means no quantization at all. Problem was solved but some macroblocks shows up.

Then I did a try in 6 in all positions, 6 was the dct number in all the scaling tables with other positions multiple of 6 or 3. It worked until the image got 3 fstops underexposed, then the rain appears, so I perceived that I should increase the deblocking values.

So I increased the deblocking intra all to 36 and keep the deblocking inter all 6, rain disappears. but some mud happens, it was so much deblocking.

Then I lowered it to 18 in all intraframe positions and to 3 in all the interframe positions. It worked ok, enough debloking and rain keep away. I did a try in 12 in all intra positions but not worked, 18 was ok.

so the deblocking intraframe is

018 018 018 018

018 018 018 018

018 018 018 018

018 018 018 018

(018 in the intra deblocking was ok to deblock the image, no need more, I saw the image frame by frame in 400% zoom, light, shadow and gradients)

and the deblocking interframe is

003 003 003 003

003 003 003 003

003 003 003 003

003 003 003 003

(006 in all positions also works for interframe, but I prefer lower quantization in the interframe, less mud)

I think the numbers in deblocking tables must be related to the dct number of the main scaling matrices. My scaling matrices has 6 in the dct number so using multiples of 6 or half 6 in the deblocking worked ok. I think if you use 4 in the dct number of the scaling matrices, then the debloking must be multiple of 4 or 2, just a supposition.

Also I perceived that the main scaling matrices works better when all the numbers have a relationship to be a multiple of some number, example: all multiple of 6, or all multiple of 3, or all multiple of 2. the camera processor does not stress with this design, see the matrices in the "the patch" topic.

@charlie_orozco this achievement is in the patches you can find in "the end" topic