After a little experimentation, it seems this code will accomodate for the color shift present in the new intel macs specifically related to webcam input.

Code:

for (int i=0; i<capture.pixels.length; i++){
        rr = green(capture.pixels[i]);
        gg = red(capture.pixels[i]);
        bb = alpha(capture.pixels[i]);
        aa = blue(capture.pixels[i]);
        capture.pixels[i] = color(rr, gg, bb, aa);
}
 

So, two questions.
1) is there some bitshifting trickery that will make this happen faster?
2) why the hell is it GRAB -> RGBA?  I thought it was a simple switch of the Alpha from the end to the beginning, but apparently not!

UPDATE-------------------------------------------------
I think i jumped the gun.  The 'B' on the end of GRAB wasnt necessary.  All I needed to do was GRA -> RGB.  I forgot there isn't actually any alpha data coming in from the webcam.  So it probably should have been this instead.

Code:

for (int i=0; i<capture.pixels.length; i++){
        //aa = blue(capture.pixels[i]);
        rr = green(capture.pixels[i]);
        gg = red(capture.pixels[i]);
        bb = alpha(capture.pixels[i]);
        capture.pixels[i] = color(rr, gg, bb);
}
 

fwiw, this has just been confirmed as a bug on the qtjava mailing list, so hopefully we'll see a fix in the next rev of quicktime. i'm hesitant to do a hack to work around it in the p5 code since it should get fixed sometime, though maybe we could add a hint() that would temporarily fix things in case it takes apple forever to get it straightened out.