X-Y Correlation of noise?

Nov 3, 2012 at 11:16pm

X-Y Correlation of noise?

I’ve written a little [jit.gl.pix] to add some fuzz, but the result seems to be correlated along the line X=-Y. Why is this? In the patcher below, keep increasing fuzz, you will see a distinct diagonal component to the output. I expect it to be uncorrelated fuzziness, expanding outward. Any ideas?

Thanks,
James

– Pasted Max Patch, click to expand. –
#65053
Nov 4, 2012 at 3:58pm

try increasing the planes of the jit.noise object to 3. I’ve not played with jit.gl.pix yet so i’m not sure exactly why this helps.

#234585
Nov 4, 2012 at 10:29pm

Well I’ll be darned. That did the trick. I don’t really understand why it works either. Perhaps there is some difference in the way jit.noise generates its data for 3+ planes (RGB)? Anyway, thanks for the tip!

#234586
Nov 5, 2012 at 1:45pm

No, [jit.noise] uses the same core Random Number Generator regardless of plane count (or anything else). At least in the code published with the Jitter SDK, it’s all done using the Linear Congruence RNG published in Numerical Recipes. This is a quick-and-dirty RNG which is known to have correlation issues across multiple dimensions. These normally don’t show up in Jitter (or with the other Max/MSP objects that use the same algorithm), but you may have stumbled across a context where the issue does show up. If this is the case, switching a different plane count may be enough to prevent the correlation from being visible to the naked eye.

When I have some time I’ll try replacing the [jit.noise] object in your patch with [lbj.shhh] from the Litter Bundle for Jitter. The LBJ noise objects use a high quality RNG that is designed to be immune from any kind of multiple-dimension correlation issue.

#234587
Nov 5, 2012 at 5:44pm

@Jadie
The problem with your patch is a pretty subtle one. Took me a second to figure it out. With jit.gl.pix, the inputs are always converted to RGBA format (this is also true of jit.pix). When you send a 2-plane matrix to jit.gl.pix, the conversion to RGBA assumes the input is in Luminance-Alpha format. This means your first plane is Luminance and your second Alpha. As a result the conversion will look like this:

LA (Luminance-Alpha) or 01 (in plane indices) converts to ALLL (Alpha Luminance Luminance Luminance) or 0111

This is equivalent to having a matrix that looks like [jit.matrix 4 float32 320 240 @planemap 0 1 1 1] in between your noise object and the 2nd jit.gl.pix input. If you make the noise object 4-plane (also it can be char to save cycles), it looks good:

– Pasted Max Patch, click to expand. –
#234588
Nov 5, 2012 at 11:04pm

Thanks for the explanation. Is the LA format documented anywhere? This is the first I’ve heard of it.

Instead of doubling my memory usage I solved this by swizzling channels to get back to the original planes I passed in – insert a [swiz r a] between the [sample] and the [expr]

James

– Pasted Max Patch, click to expand. –
#234589
Nov 5, 2012 at 11:11pm

It is documented under the jit.pix section of the Gen Overview document. Maybe not the easiest to find, but it is there :) The same applies to jit.gl.pix (and jit.gl.slab for that matter). Textures on the GPU always have RGBA components. If you send them less data, certain assumptions are made about what the different planes mean. A 2-plane texture is assumed to be in Luminance-Alpha format. If you send a 2-plane matrix to jit.gl.texture, you’ll see the same conversion. jit.gl.pix has textures for all of its inputs. If you send it a matrix, it will internally be converted into a texture for GPU processing.

#234590

You must be logged in to reply to this topic.