Why would you need a web exposed UI?

I guess you could have a local only port to use on a server backend like a reverse proxy but you definitely don't want this public web facing.

imagemagick is used because it is binary library used on the backend

now if this was a dropin library and command line compatible, adoption would be 100%

> 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).

> adoption would be 100%

That's the goal ;)

> Why would you need a web exposed UI?

s/UI/API/

That bothers me too, but I can imagine it serves as a nice & complete example of how to use the library.

> now if this was a dropin library and command line compatible, adoption would be 100%

Sometimes fixing a library means you have to break the API... In case the API sucks and encourages insecure usage patterns. (See LibreSSL.)

Yes it's useful for older projects, but useless and counterproductive for any new code. Perhaps you could write a compatibility layer on top of the new API?

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.

Yeah, this is a non-starter for me if it's not a command line tool.

It's a real pity that so many otherwise promising apps are web based or cloud based. What a waste.

This is not a hosted service, but rather a reusable library, server, and command-line tool.

Backers can already download a prototype of the command-line tool. We don't advertise it, because it's a less common usage scenario.

libimageflow is a C-compatible library you can use from any language, so there's no limitation on usage scenarios.

Because microservices.

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)?