You should rewrite a "pseudo-non-blocking" implementation of these filters. Right now they block the UI thread for too long, which limits how useful these can be. Web workers in one option, although it's not widely supported. The better option is to use setTimout or setInterval to break of the processing work into chunks, which is supported in all browsers. For example, run the loop n iterations then run the next n after a 15 ms delay. The way you've implemented the processing right now makes this lib unsuitable for use on the clientside.
Additionally, if you were doing this a couple years from now you could do it all in a shader in WebGL - which mimics what I believe to be Instagram's technology progression from pure CPU filters to pure GPU filters.
glfx.js does exactly what you suggest, leveraging WebGL shaders to do high performance image manip. It's likely fltrr could use glfx.js under the hood for very low-latency manip.
The most important omissions from that list are IE < 10. Using web workers if present and falling back on a different strategy are probably the right way to go because web workers will finish more quickly.
