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.

I just added fltrr to https://github.com/bebraw/jswiki/wiki/Image-manipulation which tracks libraries that do this.

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.

Yeah, I am aware of that. This was literally a weekend thing, so I'll try and improve it when I have some time. Thanks for the feedback!

Cool! It really is an awesome project otherwise. I'll definitely play around with this as some point.

Why not use WebWorkers?

Web workers are not well-supported yet: http://caniuse.com/#feat=webworkers

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.

Another recent Lomo-esque JS library: http://vintagejs.com/

It's definitely a good start, but IMO the quality of the filters are not on par with those of Instagram.

A better JS filter library I found is CarmanJS. Check out their demos at http://camanjs.com/examples/presets

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.

really great work there.

not a big fan of the license choice, though.

Not to derail the thread, but whys that?

I don't really like the GPL also. Make's it basically useless in a closed application but this isn't the place to rant.

I don't really have a reason for picking GPL. Would you prefer MIT instead?

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.

MIT is more widely known and understood, though.

yeah, strongly preferred.

here are two very handy articles about the differences between open source (and other) licenses

http://www.smashingmagazine.com/2010/03/24/a-short-guide-to-...

http://en.wikipedia.org/wiki/Comparison_of_free_and_open_sou...

Thanks for this - will change the licence to MIT.

Awesome work! Is there a way that these filtered images could then be saved server side to be used later without the js?

You could get the image data from the canvas element using getImageData() and upload it to your server.

Oops, the correct method is toDataURL(). See comment above.

this is very good! is it possible to save the filtered images locally?

Try this one: https://gist.github.com/1747707

It basically uses the toDataURL() method to get the image data of the canvas.

well, this method downloads a file without a .png at the end (and most users are overwhelmed with the task of renaming a file)

think there is something coming with BlobBuilder and FileSaver, but i haven't hat time yet to give it a spin http://dev.w3.org/2009/dap/file-system/file-writer.html#idl-... and an example here http://updates.html5rocks.com/2011/08/Saving-generated-files...

This is awesome. Thanks!

would be cool to see a demo.