Do pixel arrays "roll over" internally?

So, with this snippet of code:

  
  
for (int i = w-numRowsRight; i < w; i++){  
		for (int k = 0; k < h; k++){//get last column of pixels of movie in the far right column of rightPixel.  
			rightPixels[(k*w+i)*3 + 0 - (w*3-3*numRowsRight)] = moviePixels[(k*w+i)*3 + 0];  
			rightPixels[(k*w+i)*3 + 1 - (w*3-3*numRowsRight)] = moviePixels[(k*w+i)*3 + 1];  
			rightPixels[(k*w+i)*3 + 2 - (w*3-3*numRowsRight)] = moviePixels[(k*w+i)*3 + 2];  
		}  
	}  
  
  
for (int i = numRowsRight; i < w ; i++){  
			for (int k = 0; k < h; k++){//move them along from Right to left  
				rightPixels[(k*w+i)*3 + 0] = rightPixels[((k*w+i)+velRight)*3 + 0];  
				rightPixels[(k*w+i)*3 + 1] = rightPixels[((k*w+i)+velRight)*3 + 1];  
				rightPixels[(k*w+i)*3 + 2] = rightPixels[((k*w+i)+velRight)*3 + 2];  
				}  
			  

at every cycle of update the values of the pixels from a number of columns (numRowsRight) are copied/moved from a certain amount from the right (velRight). This velocity is derived from a optical flow calculation. This works fine as long as I want the movement from screen right to left. But for some reason, I can’t get it to reverse directions. If I try to use

  
for (int i = numRowsRight; i < w ; i++){  
			for (int k = 0; k < h; k++){//move them along  
				rightPixels[(k*w+i)*3 + 0] = rightPixels[((k*w+i)-velRight)*3 + 0];  
				rightPixels[(k*w+i)*3 + 1] = rightPixels[((k*w+i)-velRight)*3 + 1];  
				rightPixels[(k*w+i)*3 + 2] = rightPixels[((k*w+i)-velRight)*3 + 2];  
				}  
			  

and put the the input column on the left, so the pixels would be moved left to right, I get a COPIES of what’s in numRowsRight.

Am I fundamentally misunderstanding how the pixel array works? Or am I exploiting a bug when it’s working “correctly?”

I think you’re getting copies because of the way you are iterating through the x axis. when shifting right to left it works because you are saving info into pixels that you’ve already encountered, but from left to right you’re saving info into pixels that will be encountered again, this it will make a streak-like effect if I am correct.

You can solve this by using two pixel buffers, one for the source data and one for the destination, this way you’re never reading and writing the same buffer. In the second loop you would have a new destination buffer, lets say finalPixels[whatever] = rightPixels[whatever];

Also, in the index calculation, ((k*w+i)+velRight)*3 + 2, i would think if you are trying to slide pixels horizontally, you’d only want to add the velocity to the x coordinate, not to the final index after the 2d->1d transformation. Like this: ((k*w+(i+velRight))*3 + 2.

You should also check to make sure your modified index is still within range of the buffer size, claculate it first and store it in a temp variable then check if it is in range. This will also speed things up by not doing the same calculation 3 times per pixel.

  
  
for (int i = w-numRowsRight; i < w; i++){    
        for (int k = 0; k < h; k++){//get last column of pixels of movie in the far right column of rightPixel.    
            int destIndex = (k*w+i)*3 - (w*3-3*numRowsRight);  
            if(destIndex > 0 && destIndex < w*h*3) {  
                int sourceIndex = (k*w+i)*3; //this should never be out of range  
                rightPixels[destIndex] = moviePixels[sourceIndex];    
                rightPixels[destIndex+1] = moviePixels[sourceIndex + 1];    
                rightPixels[destIndex+2] = moviePixels[sourceIndex + 2];    
            }  
        }    
    }      
  

Thanks so much. That really helped clear it up.

I realized when I want to do the other way I can:

  
for (int i = w; i > numRows; i--)  

filling in with values for -velLeft, since as you say, I’m “saving info into pixels that you’ve already encountered” just the opposite way.

And yes, I’ll need two buffers, one left to right, one right to left, and then determine which, according to camera motion, to swap into the image that becomes the ofTexture that gets drawn to the screen.