Wow, that’s quite a bit more than some simple pseudo-code. 
Thanks.
It looks great to me! A few minor comments.
Instead of getNeededTextures, I would suggest that there is instead a setup() method in which the Filter classes can call registerInputTexture() or something of the sort. The advantage of this is that we can later extend which things are stored about a texture input by adding keyword arguments to that method, without having to change the behaviour in all existing Filter implementations. It seems a bit cleaner as well. The same goes for getCustomParameters.
getNeedGlow seems a bit specific. Can we instead store a bitmask of AuxBitplaneAttrib flags?
I’m not quite sure I understand this stage idea. Is the “stage” string one of a number of fixed built-in stages? Are the different stages hard-coded? Can you explain to me in simple terms what exact purpose the stage concept serves?
I’m not sure if all of those methods need getters - it seems that some of them can simply remain a public member, like sort and needs_compile. I think sort can be a member with a filter-specific default value, but that can be changed by the user.
I think the strange inspection logic in setFilter has to go. We should keep it simply by either allowing someone to add a filter of a certain type more than once (even if that doesn’t make sense), or raising an error, or removing the old one entirely.
Just FYI, cmp= in sort() is deprecated and no longer supported in Python 3. Instead, you should do this:
self.filters.sort(key=lambda f: f.sort)where Filter stores a self.sort value.
I think there is no reason to keep CommonFilters an old-style class. Perhaps CommonFilters should inherit from FilterPipeline?