3 ms·

Two others in this space: http://thumbor.org http://thumbor.org http://magickly.afeld.me http://magickly.afeld.me But neither seems to get as much love as they

Two others in this space: http://thumbor.org http://thumbor.org http://magickly.afeld.me http://magickly.afeld.me But neither seems to get as much love as they need, so always good to have more players.

thedz 11y ago
thumbor is an on demand service that hosts and responds to image requests. this is a JS based smart cropper. they're not quite the same thing.
- slig 11y ago
  thumbor has a similar feature built in.
berkes 11y ago
I made another one, in Ruby http://smartcropper.berk.es/ http://smartcropper.berk.es/. And just like those other two, in need of love. But the difference is that these are all running on a backend, while the JS version will probably run in the frontend. I'm not sure what the right place for this would be, but frontend has some advantages and quite some disadvantages: * It's as slow as the devise running the JS. In mobile era that probably means a magnitute slower than even the cheapest DO server. * You can't reply on it, so if you want to ensure you receive, say, square images, you'll need to validate and re-crop on backend again. * It's very error-prone. On a backend you can ensure versions of imagemagic or some other processing is there, on frontends: you'll rely on the parsing in JS (very slow) or on the rendering of the client (unstable in the sense of: you don't know where it works in what way, and if that will stay so) * It is distributed. My smartcropper for Ruby is heavy, memory-gobbling, and slow (partly the fault of the bad code, It is long due some refactoring). It is near impossible to run without some async-job system. Whereas, a cropper in the frontend scales nicely across users, because each user brings their own processing-power Edit: bullet-point markup and realised a pro for doing this frontend.

3 ms·

Two others in this space: http://thumbor.org http://thumbor.org http://magickly.afeld.me http://magickly.afeld.me But neither seems to get as much love as they

by sam_goody 11y ago

thedz 11y ago
thumbor is an on demand service that hosts and responds to image requests. this is a JS based smart cropper. they're not quite the same thing.
- slig 11y ago
  thumbor has a similar feature built in.
berkes 11y ago
I made another one, in Ruby http://smartcropper.berk.es/ http://smartcropper.berk.es/. And just like those other two, in need of love. But the difference is that these are all running on a backend, while the JS version will probably run in the frontend. I'm not sure what the right place for this would be, but frontend has some advantages and quite some disadvantages: * It's as slow as the devise running the JS. In mobile era that probably means a magnitute slower than even the cheapest DO server. * You can't reply on it, so if you want to ensure you receive, say, square images, you'll need to validate and re-crop on backend again. * It's very error-prone. On a backend you can ensure versions of imagemagic or some other processing is there, on frontends: you'll rely on the parsing in JS (very slow) or on the rendering of the client (unstable in the sense of: you don't know where it works in what way, and if that will stay so) * It is distributed. My smartcropper for Ruby is heavy, memory-gobbling, and slow (partly the fault of the bad code, It is long due some refactoring). It is near impossible to run without some async-job system. Whereas, a cropper in the frontend scales nicely across users, because each user brings their own processing-power Edit: bullet-point markup and realised a pro for doing this frontend.