Friday, September 19, 2014

Olsen Noise Source Code in Java.

I have it autonormalizing. Because Olsen Noise doesn't artifact it's plenty doable to have the noise routine, fall into a specific range across all pixels by design. In this case it will always be between 0 and 255. Due to the random additions being at the exact bit level of the maxiterations and the max iterations at 7. Due to the blur and random speckling again it will likely fall into a gaussian distribution at around 128.

The math at the beginning is kind of confusing what it's doing. I changed it from recursive to iterative. So to figure out the base case it needs to iterate down to the base case. There may however be a way to solve the recursive problem directly and figure out what the window size is any given iteration. But, for now it does (v/2)-1 for all the lows (applying floor due to integer division) and 1 -(-v/2)) for all the highs (that double negative is there to make it a ceiling op).

It creates too many int[][] objects. One for upsample, One for Blur, and One for trim, each of the 7 iterations. So 21 such objects. I think it can be done with 3.

Update: Blur object can be removed by subdividing the blur into length then width (and division). The two pass solution allows for the same int[][] object that stores the value for blurring to be the same object the blur is passed into.
2/15 Update: The trim isn't really even needed as if you properly use a 1d array to store it and skip around with a stride, you can avoid trimming as most images will accept that you can give them more pixels and tell them where they properly are in the image (thus doing the trim) 

One of the more important things about this is at some particular iteration it can't know from its current position where it is actually located in the iteration above it. It actually needs to calculate the x0,y0 and x1,y1 positions and compare that to the current location Scaled and Translated into where it would normally be and use that to calculate the offset it's what  this: xoff = -2*((nx/2)) + nx + 1; actually does. It figures out from the next x, whether when the data is moved into the trimmed matrix should it be shifted somewhere. Without these calculations, you'll still get noise, it just won't be stable.

I should update or make a new javascript demo in both 2 and 3d. It would be hard to have it melt through time to show the 3D version off. 

Wrapping should be possible. It could be done at Q*(2^I) in any With iterations of 7 that's 128 and any multiples of 128.  Upsample would be unaffected by the random additions would need to know to wrap and the the blur would need to know that it wraps around the edge rather than truncates the edges.

Update: -- Originally had source code pasted here. It exists in the slashed out paste bin if you need it. But, It's old see --

No comments: