21–29 of 29 posts
Earlier quoted context omitted.
I don't really have a reason for picking GPL. Would you prefer MIT instead?
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...
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.
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 a…
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.
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...
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 a…
Why not use 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.
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 a…
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!
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 a…
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.
A better JS filter library I found is CarmanJS. Check out their demos at http://camanjs.com/examples/presets