I'm currently making an application using processing intended to take an image and apply 8bit style processing to it: that is to make it look pixelated. To do this it has a method that take a style and window size as parameters (style is the shape in which the window is to be displayed - rect, ellipse, cross etc, and window size is a number between 1-10 squared) - to produce results similar to the iphone app pxl (http://itunes.apple.com/us/app/pxl./id499620829?mt=8 ). This method then counts through the image's pixels, window by window averages the colour of the window and displays a rect(or which every shape/style chosen) at the equivalent space on the other side of the sketch window (the sketch when run is supposed to display the original image on the left mirror it with the processed version on the right).
The problem Im having is when drawing the averaged colour rects, the order in which they display becomes skewed..
Although the results are rather amusing, they are not what I want. This has been bugging me for a while now as I can't see where in my code im offsetting the coordinates so they display like this. I know its probably something very trivial but I can seem to work it out. If anyone can spot why this skewed reordering is happening i would be much obliged as i have quite a lot of other ideas i want to implement and this is holding me back (I have also asked this on stackoverflow but this is the processing forum so I realised i was more likely to get an answer here :)). The sRGB class is essentially color() so you can replace with that to get it working (although if youd like that and the other colour space classes XYZ and LAB i can post but they aren't really used within the code). Anyway PLEASE Help me its a rather annoying bug...
It's a little hard to test your code since it doesn't run in Processing as-is.
That said, there are some things you're doing here that I'd question right from the start. For example: why are you calling sqrt() so many times to calculate the size of your windows? Wouldn't it be simpler to just set the width of the window and square that?
Second: you've got a lot of arbitrary numbers hard-coded in to various loops, like 15, 10, 5, 2.5, and 3. One of these numbers might be responsible for the image shearing you're seeing.
But looking at it more closely, I'd guess the offending line is most likely line 100:
int loc = (wx+x) + (y+wy)*(img.width-windowSize);
Up to there, you've been using "windowSize" to mean the area of the window. But in that line you're suddenly using it as if it were the width of the window. That's a different value. But in fact, there's no need for that term at all. If what you want is the pixel located at (wx+x, wy+y), then the code should just say: