Re:Imageflow, a 17x faster ImageMagic alternative and more s...
by ndj7 on Friday June 17, 2016 @02:53PM
(#11924758)
> but you definitely don't want this public web facing.
That's what dynamic imaging is. Your server generates images as needed, at the right size, in the right format. Even Kickstarter does this, although they use an extremely expensive and proprietary SaaS to do it. Nearly all e-commerce and CMS providers offer this, as do many CDNs.
We're making it free.
> imagemagick is used because it is binary library used on the backend
We don't use imagemagick; we own the entire rendering stack, thus the performance.
> now if this was a dropin library
libimageflow is a drop-in library. It's the focus. Any FFI-capable language can use it. Basic bindings take 5-8 hours to develop.
> and command line compatible
imageflow-tool will expose libimageflow's full power via the JSON interface. (There is also a simpler thumbnailing/converting tool following unix design practices, a prototype of which you can access immediately).
That's what dynamic imaging is. Your server generates images as needed, at the right size, in the right format. Even Kickstarter does this, although they use an extremely expensive and proprietary SaaS to do it. Nearly all e-commerce and CMS providers offer this, as do many CDNs.
We're making it free.
> imagemagick is used because it is binary library used on the backend
We don't use imagemagick; we own the entire rendering stack, thus the performance.
> now if this was a dropin library
libimageflow is a drop-in library. It's the focus. Any FFI-capable language can use it. Basic bindings take 5-8 hours to develop.
> and command line compatible
imageflow-tool will expose libimageflow's full power via the JSON interface. (There is also a simpler thumbnailing/converting tool following unix design practices, a prototype of which you can access immediately).
> adoption would be 100%
That's the goal ;)