Are the areas you want to use as trigger zones fixed? Maybe it's enough to check one row and column in a certain area and use a threshold value for the color value and hit count.

If with a different blob detection lib my off-the-top-of-my-head calculations make me think screen-section detection would be faster.

The trigger zones would be defined at the start of the sketch and not change.  Imagine breaking the screen up into a grid, and only sub-sets of that grid near each corner would be of interest.

Playing around I came up with this:

2. int getRectColorSum(int x1, int y1, int x2, int y2, int shiftColorInt){
3. 
   
4.   int sum = 0;
5.   for(int x = x1;  x < x2; x++){
6.     for(int y = y1; y < y2; y++) {
7.       sum += (pixels[y*width+x] >> shiftColorInt)  & 0xFF;
8.     }
9.   }
10.   return sum;
11. }

which you would call like this:

1. int shiftColorGreen = 8;
   
   
   int rect1ColorSum = getRectColorSum(1,1, 10, 70, shiftColorGreen);

Basically, if the result is more than 0 then some number of pixels have some green in them (i.e are not all black) and it's a matter of how big the value needs to be to trigger something.

Simple usage gives me a respectable FPS speed.   I need to now run it with multiple sections being checked.

Another I'm curious about is if  using   get( x ,  y ,  w ,  h ) to create an Image from a section of the screen would allow some other kind of bulk operation to detect changes.

It's a matter of having a fast way to detect if a section of the screen is different enough from some established baseline.

2. /*
3. 
   
4. See if some target rectangle area is not all black.  
5. 
   
6.  */
7. 
   
8. int rect1ColorSum;
9. int rect1Baseline = 0; 
10. int shiftColorGreen = 8;
11. 
    
12. int rect2ColorSum;
13. int rect2Baseline = 0; 
14. 
    
15. int rect3ColorSum;
16. int rect3Baseline = 0; 
17. 
    
18. int rect4ColorSum;
19. int rect4Baseline = 0; 
20. 
    
21. 
    
22. color col = color(255, 0, 255);
23. 
    
24. int wi = 800;
25. int he = 800;
26. 
    
27. int wd = wi/6;
28. int hd = he/6;
29. 
    
30. int[] t1= { 0, 0, wd*2, hd*2};
31. int[] t2 = {0, hd*4,   wd*2, he-1};
32. int[] t3 = {wd*4, 0, wi-1, hd*2};
33. int[] t4 = {wd*4, hd*4, wi-1, he-1};
34. 
    
35. void drawTarget(int x1, int y1, int x2, int y2, color c) {
36.   fill(c);
37.   rect(x1, y1, x2, y2);
38. }
39. 
    
40. 
    
41. void drawTarget2(int[] coords, color c) {
42.   drawTarget(coords[0],coords[1], coords[2], coords[3], c);
43. }
44. 
    
45. void setScreen(){
46.   background(0);
47. 
    
48.   drawTarget2(t1, col);
49.   drawTarget2(t2, col);
50.   drawTarget2( t3, col);
51.   drawTarget2( t4, col);
52. }
53. 
    
54. void setup() {
55.   size(wi, he);
56.   setScreen();
57.   loadPixels();
58. }
59. 
    
60. int getRectColorSum(int x1, int y1, int x2, int y2, int shiftColorInt){
61.   loadPixels();
62.   int sum = 0;
63.   
64.   for(int x = x1;  x < x2; x++){
65.     for(int y = y1; y < y2; y++) {
66.       sum += (pixels[y*width+x] >> shiftColorInt)  & 0xFF;
67.     }
68.   }
69.   return sum;
70. }
71. 
    
72. int getRectColorSum2( int[] coords, int shiftColorInt ){
73.   return getRectColorSum( coords[0],coords[1], coords[2], coords[3], shiftColorInt);
74. }
75. 
    
76. void randomBlob(){
77.   fill(#00ff33);
78.   int rx = int(random(0, wd*3));
79.   int ry = int(random(0, hd*3));
80.   rect(rx, ry, rx+100, ry+100);
81. }
82. 
    
83. void draw() {
84.   setScreen();
85.   randomBlob();
86.   rect1ColorSum = getRectColorSum2(t1, shiftColorGreen);
87.   rect2ColorSum = getRectColorSum2(t2, shiftColorGreen);
88.   rect3ColorSum = getRectColorSum2(t3, shiftColorGreen);
89.   rect4ColorSum = getRectColorSum2(t4, shiftColorGreen);
90.  
91.  // These do not seem to effect the fps 
92.   println("\nrect1ColorSum = " + rect1ColorSum);
93.   println("rect2ColorSum = " + rect2ColorSum);
94.   println("rect3ColorSum = " + rect3ColorSum);
95.   println("rect4ColorSum = " + rect4ColorSum);
96. 
    
97.   frame.setTitle(" " + int(frameRate ) + " ");
98. }
99. 
    

The example below (without drawing the rects+texts!) on my computer has 78 fps for 4 (2x2), 400 (20x20) and 1600 (40x40) areas. So it's optimized in the sense that the level of finer detail doesn't negatively impact the fps because of course the total number of pixels always stays the same. I haven't tested 1600 areas with your code since you set the areas manually, but I could imagine that using loadPixels and for loops for each separate area has some cost.

Code Example

1. int dim = 20;
2. int[][] sums;
3. int[] dxlookup, dylookup;
4. int sx, sy;
5.  
6. void setup() {
7.   size(800, 800);
8.   textSize(10);
9.   textAlign(CENTER, CENTER);
10.   rectMode(CENTER);
11.   sx = width/dim;
12.   sy = height/dim;
13.   dxlookup = new int[width];
14.   dylookup = new int[height];
15.   for (int y=0; y<height; y++) { dylookup[y] = y/sy; }
16.   for (int x=0; x<width; x++)  { dxlookup[x] = x/sx; }
17. }
18.  
19. void draw() {
20.   background(0);
21.  
22.   noStroke();
23.   fill(#00ff33);
24.   float rx = random(width-100);
25.   float ry = random(height-100);
26.   rect(rx, ry, rx+100, ry+100);
27.  
28.   sums = new int[dim][dim];
29.   loadPixels();
30.   for (int y=0; y<height; y++) {
31.     for (int x=0; x<width; x++) {
32.       sums[dxlookup[x]][dylookup[y]] += (pixels[x+y*width] >> 8) & 0xFF;
33.     }
34.   }
35.  
36.   // drawing these rects+texts costs fps, comment out to see the actual fps of the above code
37.   translate(sx/2, sy/2); 
38.   stroke(#ffffff);
39.   for (int y=0; y<height; y+=sy) {
40.     for (int x=0; x<width; x+=sx) {
41.       noFill();
42.       rect(x, y, sx, sy);
43.       fill(#ffffff);
44.       text(sums[dxlookup[x]][dylookup[y]], x, y);
45.     }
46.   }
47.  
48.   frame.setTitle(" " + int(frameRate));
49. }

However perhaps in a real application you may need full coverage of the frame and/or finer details aka more than four areas. 

 

Not so much.  I'm more concerned with sectioning off certain areas and knowing if detecting if there has been a change to the screen due to some other drawing activity.  For example, I might want square-ish rectangles up near each top corner, and tall-but-narrow rectangles on each side, midway to the bottom of the screen.  An XBox kinect would be track depth data to grab the silhouette of a person; as that person moves their arms in or over any of the special areas I want to trigger OSC events.  

For me it doesn't matter where exactly they enter a special area, just that it is by more than few pixel.  I want to have the screen show where there areas are, and the sketch will overlay the user shape in real-time.  I believe that means I'll need to redraw the screen each time to clear the old silhouette shape and overlay the new silhouette over the rectangles.

You're right that I'm calling loadPixels(); too often; thanks for pointing that out. It seems to make it faster, though I'm currently running a different OS right now (Ubuntu instead of Win7) and I don't know if that's influencing it.  As a comparison, though, your code runs at about 60 fps versus the 110 or so I'm now getting with my demo.

The idea of chunking up the screen is intriguing, though.  With my original blob-detection approach the blob (X,Y) center was used to drive assorted values (as opposed to the mostly on/off approach I'm taking now).  Running through a set of array values to detect screen changes may be faster than the blob approach, fast enough to allow responses to continuous values.  

Thanks again.  I now need to put this into a more realistic version of what I'm trying to do, taking into account reading the Kinect data, drawing target areas and user outlines,  detecting color changes, and firing off OSC messages.