It's clear we can improve our messaging about ways to integrate Imageflow. The command-line tool aspect is under-emphasized, and the libimageflow aspect seems to be confusing as well. What other things are unclear initially (or are still confusing)?
> 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).
Imageflow has two parts - libimageflow, and imageflow-server.
Both the library and server offer a JSON API, so it can evolve without breaking changes.
Most users leverage the Dynamic Imaging aspect - you store a single source file in blob storage, then dynamically generate variants as needed. This is like Scene7 or Cloudinary, but open-source, and at 1/1,000th of the cost.
Actually, the image rendering parts are far less difficult than the codec parts. You need the whole system in an operation graph in order to do the right thing to every image. Also, GIMP's scaling is still completely wrong - something I'm ashamed I haven't fixed yet.
We started Imageflow (https://www.imageflow.io ) in C to design the C ABI for interop with all the host languages, but we're swapping out components for Rust every time it's possible/practical.
There's a crucial difference; OpenSSL was designed to be secure. ImageMagick was designed to support hundreds of codecs and thousands of operations.
You can't pivot design on 1.25 million lines of code (est.) very quickly after 25 years of feature-first development process.
I'm a bit skeptical it will happen at all; it would be a multi-million dollar undertaking. Better to describe its design scope and tradeoffs, and get people to use it properly - sandbox it if it's on the server.
I started Imageflow to solve that problem - a server-focused design with strict design rules: security is first, followed by visual quality, followed by performance. We've kept the codebase to just 10kloc and we are 50% feature complete, but need to get a lot more momentum on Kickstarter to make completion possible. See https://www.imageflow.io
I'm at CU Boulder and their curriculum is outdated (90s) and backwards. What resources could I point the professors towards?