After seeding the generator the next number requires on
feeding back in the previously generated number. As it isn't
possible to set a variable when evaluating one pixel that will then
be available when evaluating the next pixel I've had to
precalculate the random number sequence and store it in an array in
the evaluateDependents() method.

Unfortunately dependent arrays are limited to a maximum of
4096 elements so when used across all the pixels of an image you
instantly see repeating patterns (see attached example code).

Does anyone have any suggestions to improve this or
alternative methods to generate random numbers in the Pixel Bender
kernel?

In a lot of our filters that require random numbers we use
standard methods to generate a buffer of values and pass them into
the kernel as a "noise" texture. This would work if you are
targeting Flash. It looks like you aren't though. Someone else may
have come up with a better solution...

I use Pixel Bender mainly for Photoshop and the best way I would imagine to pass random numbers into Pixel Bender is to create a layer where every pixel has a random color, similar Add Noise. Question is: How would one go about doing that in Photoshop? Scripting? Filters? I would love the possibility to create such a noise texture, with full control about the number of colors (b/w, grey, RGB, RGBA) and a random number generator of my choice (so I can use normal distribution, when I feel like it). Any idea how that could be accomplished?

You can script the Pixel Bender plugin via ExtendScript and I believe you can pass in values for parameters via that interface. You may be able to code up a simple pseudo-random number generator in ExtendScript and feed a Pixel Bender filter by passing the random numbers through parameters or as image data. I haven't tried this but I would expect it to work. In any case, let us know what you find out if you attempt it.

Yes, you can create random pixels with scripting. The only method I know is to select a 1x1 pixel area at a time and define a random color. That would take ages, even with a 800x600 image. Is there an easier way?

As for feeding Pixel Bender parameters, wouldn't I need to define one parameters per random number? 800x600 random pixels = 480000 parameters? Or am I missing something? And as a third alternative, I've read somewhere that defining pseudo-random dependables inside Pixel Bender only let's you define something like 4096 values, which would cause undesired patterns, when used on a bigger image.

In my opinion this feels like a bizarre ommission from the PB language. A Random() function should have been there since the start, and It's one of the items in the Wishlist thread I started a few weeks ago. But I'm sure the PB dev guys have good reason for not including it.

As an After Effects PB developer I want to be able to generate noise via pseudo-random numbers within the kernel without having to resort to adding a noise layer and piping that into the plugin.

None of this takes away how awesome PB is by the way - just hoping to get some extra bits of functionality in there!

The reason is that random functions and the operations required to easily support them, are not available on all of the hardware we support. We'd love to have random functions in there, but doing them well with our current hardware specs is extremely difficult.

The reason is that random functions and the operations required to easily support them, are not available on all of the hardware we support. We'd love to have random functions in there, but doing them well with our current hardware specs is extremely difficult.

Yes. We are always considering what our hardware specs are and what our base level of support is. It isn't purely our decision though, we also have to work with Photoshop and After Effects to make sure that GPUs they want to run on are still supported. I can't find the recording of Kevin Goldsmith's talk at nVidia's GTC last year but Kevin did post the slides here: