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.
What a fantastic contribution & thanks for considering MIT/MPL. This will definitely come in handy as a small side side feature for user profiles on my upcoming projects.
Awesome. I would suggest wrapping this into a small service and sell it as an API. No need for complicated documentation either, one URL with parameters.
You could also consider the MPL 2.0. It features file-based copyleft, meaning anyone who changes the files you're distributing has to redistribute their changes, but they can be used in a proprietary work without forcing the distribution of the source of any other file.
