This patch demonstrates what looks like a bit of an inconsistency:
[pix_colorreduce] appears to produce a new copy of the incoming pix data -- the result is rendered but the original data are still available to be used for later pix-texture-ings.
Many other pix_ operations behave similarly, so I assumed (hah!) that this is a general rule.
Then I find that [pix_invert] seems to overwrite the original pix, so that, in an entire rendering chain involving [pix_invert], every pix_texture will use the inverted data (except, here, the colorreduce because it's already split its results off into a separate buffer).
Wait... it gets better... if I switch the order of the left two outlets of [t a a a], so that the order goes 1/ colorreduce, 2/ no modification, 3/ pix_invert, then the pix_invert may apply to the second pix_texture as well as the third (even though pix_invert applies third).
And also, I had thought of using pix_buffer as a set of "registers" to be able to go back to the original data at any point in the rendering chain, but... pix_invert corrupts the pix_buffer data too. I wasn't able to find a solution for this.
I mean, OK, in my demo for class, I'll just have to remove pix_invert and use maybe a hue shift instead. But... this can't be intentional, can it...? What is the rationale?
EDIT: pix_offset poses the same problem as pix_invert.
EDIT: pix_buf doesn't help.