I have an interesting issue. Technically this is a graphics problem, but the algorithm I'm looking for is not unique to this situation and applies to any array with these constraints. Ultimately I just want to swap 2 pixels in a fragment shader in a reproducable, psuedorandom fashion to simulate GIMP's "spread" noise filter.

As a more general problem, I have a 2 dimensional array of values. I need to be able to iterate every member of the array and swap it with a psuedo-random neighbor (within an nxn neighborhood). This would ordinarily be trivial, but unfortunately at each step of the iteration, a value can only modify itself and is only aware of the values that exist before iterations and the seed to the whole operation. I cannot cache swaps because each iteration is unaware of them, nor can the iteration be stopped or reversed. Therefore, and more formally, I need a function that takes an x,y pair and produces some psuedorandom x',y' such that f(x,y) = x',y' and f(x',y') = x,y where 0<|x-x'| <= n and 0<|y-y'|<= n. I may be overthinking this (or not thinking at all!) but I'm not sure how to approach this, to be honest.

I suspect that any periocidy would be relatively unnoticeable as the input array is already fairly random. Also, the array is only 4196 x 4196 units large, so a relatively short period would not have a chance of recurring. With these two things in mind, a very bad randomizer is perfectly fine. I also dont care if the algorithm can generate collisions - it's just a noise function, the collisions will be more noise as long as they are not very regular.

Why not just select a random point in an appropriately size circle (or square) around each pixel and sample the original image at that point? Does it really need to be swapped with that point? Probably not. (I think this is how GIMP's spread noise works as well)

One simple way would be to create a texture that encodes which values to swap, e.g. use r and g as indices for the position.Then use the screen position as an index into that texture, and use the r and g as relative indices into the original screen image.You could get as fancy as you want creating your index texture because it wouldn't need to be calculated at runtime.

@l0calh05t I actually did that while searching for a "good enough" solution, and it worked within reason. The reason I wanted to avoid it was because the effect influences the total concentration of values at each level. For now, this is "good enough" and I'll go with it, but I was wondering if there was a solution.

@Jefferytitan that's a sensible solution that I hadn't considered. I wonder, though, if I would need to use a texture of equal size (4196x4196) or if a smaller, repeating texture would be "random enough?"

Still, two very nice answers. Thank you both.

I think you could get away with a smaller texture. Remember that you could mix it up somewhat, e.g. it could be rotated and/or reflected, and you could also pack another random texture into the b and a. Combine those together... rotate x 4, horizontal reflect x 2, vertical reflect x 2, other channels x 2, which gives you 32 variations.