X-Y Correlation of noise?

    Nov 03 2012 | 11:16 pm
    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

    • Nov 04 2012 | 3:58 pm
      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.
    • Nov 04 2012 | 10:29 pm
      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!
    • Nov 05 2012 | 1:45 pm
      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.
    • Nov 05 2012 | 5:44 pm
      @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:
    • Nov 05 2012 | 11:04 pm
      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]
    • Nov 05 2012 | 11:11 pm
      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.