Frequently Asked Questions
As a desktop tool? Absolutely not. With the correct compilation flags and command sequences, ImageMagick can produce very high-quality results. ImageMagick is a fantastic general-purpose imaging toolkit. It focuses on features and capabilities, which is exactly what you want in a desktop tool. We use it almost every day.
Should you use ImageMagick with potentially malicious data? No.
Read what Michal Zalewski, author of "The Tangled Web: A Guide to Securing Modern Web Applications" has to say about ImageMagick on the server: https://lcamtuf.blogspot.com/2016/05/clearing-up-some-misconceptions-around.html
Look at the cadence of vulnerabilities in the product itself: https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html How many times per month are you willing to recompile?
At one point, ImageMagick was protected by obscurity/lack of prevalence in server environments. This has changed in the last few years, and it is now a favorite attack vector.
Furthermore, ImageMagick does not report vulnerabilities in the codecs which support its 200+ formats. You're responsible for monitoring all of the codecs which ImageMagick depends on. Some of these codecs explicitly disclaim any security process. As ImageMagick integrates with most open-source codecs, a little over half of CVEs which mention the word 'image' are applicable: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=image
We're not aware of any attempts to audit the ~1.25 million lines of code that combine to create ImageMagick, nor of any documentation that recommends its use in a server environment. We'd like to see a guide on how to properly sandbox ImageMagick, but one has not yet appeared.
If you're working with trusted image data, ImageMagick is a solid choice. Imageflow's command-line tool will only have a fraction of ImageMagick's feature set, and is targeted specifically at producing images for use on the web.
If you're processing user-provided images on the server, you should use libimageflow or imageflow-server.Last updated:
In a sense, we are, because we're contributing to the codecs ImageMagick uses. But ImageMagick core is not something we could adapt to meet our server-side needs. We've also tried making LibGD and FreeImage work, which didn't for other reasons.
Imageflow and ImageMagick have different (mutually exclusive) goals. ImageMagick is a desktop toolkit for doing anything you can imagine with images, and supporting all the formats.
Imageflow is a server-side library (and tooling) focused on doing ~3 formats and ~10 operations very, very well.
Generic flexibility and speed are often at odds, as are feature breadth and security.
There's no way we could speed ImageMagick up without dropping functionality and reimplementing how pixels are handled across the program. We certainly don't have the resources to audit or secure it. https://lcamtuf.blogspot.com/2016/05/clearing-up-some-misconceptions-around.html
Trying to inject our operation graph approach would be near-impossible.
Besides, many companies have tried. ImageMagick supports OpenMP, and may soon attempt GPU offloading to help carry the performance burden. The ImageMagick developers are not bad at performance; they're making conscious tradeoffs that are in-line with their product scope, but not ours. We're not trying to do what they're doing, and they're not trying to do what we're doing.
In the end, we expect to have a codebase 1/10th or 1/100th the size of ImageMagick, depending upon whether you're counting dependencies or not. This smaller codebase means we can dedicate more time to correctness, speed, and security.Last updated:
Current open-source image servers are alike in that they all* use either ImageMagick, GraphicsMagick, LibGD, or libvips to perform the actual image processing, and inherit the limitations or risks of those libraries.
We hope to see these image servers adopt libimageflow.
*The internet is a large place, but this is remarkably accurate.Last updated:
We're switching away from tying the business model to breaking change-releases, since we're very good at avoiding breaking changes - and we follow semver.
So the licenses do expire (1-3 years, check your tier), and they require renewal. The licenses revert to perpetual use licenses if we go out of business or don't release a new version every 12 months.Last updated:
You can renew the OEM, SaaS, and org-wide licenses for $600/yr until you exceed the revenue limits. Then to goes to $849/yr or $2,900/yr depending on which license you need and how much support you want included.Last updated:
Note: You can avoid the SaaS requirement by complying with the AGPLv3. If you're combining closed-source and SaaS, then keep reading:
Some examples of SaaS usage: Hosted portfolio platforms (but not customer-hosted), real estate listing sites, social networks, auction sites, content delivery networks, for-profit image hosting services, and hosted content management systems. We do not restrict the term SaaS to B2B products; this includes subscription consumer services as well.
You do NOT need a SaaS license if: Access to to all images, and the management (uploading, editing, removal) thereof is provided equally to all non-administrative users, and your service does not offer any paid services or subscriptions, and does not display third-party advertising.
If only site administrators/employees manage image content, and there is no recurring revenue model, then you do not need a SaaS license. Most content websites do not need a SaaS license, and the enterprise-wide licenses are sufficient for an unlimited number of them.Last updated:
No. Version 1 of imageflow will not be 100% Rust. We mention Rust in the specs because people would be upset if we promised vanilla C11 and delivered them Rust. That's why we say C + Rust.
Imageflow-server should be 100% Rust unless we hit a major blocker; but it will call into libimageflow, which is *NOT* 100% Rust.
Obviously, we hope to reach a high percentage of Rust in the codebase for security reasons. No, we are not guaranteeing a certain percentage. We'll do our best, but we have a long list of things to work on, and porting to Rust will fall behind most of those in terms of priorities.Last updated:
NO. GPL doesn't make you go GPL - it just makes you go open-source. Any compatible license (like MIT/Apache 2, etc) is OK for *your* code.
As always, if a work combines multiple projects under multiple licenses, you have to adhere to all of them.Last updated:
We're delivering a fully-functioning HTTP server binary (imageflow-server), so there's only one copyleft license that is even relevant, and that is AGPLv3.
If you improve the imageflow-server code, and deploy those changes to the world, the AGPLv3 will require that you also share your improvements. This shouldn't be scary; MongoDB is also licensed under the AGPL.Last updated:
Actually, those stretch goals are available for the next year, if you feel like supporting us. There are dozens of companies for whom buying out the GPL or MIT/Apache 2 licensing option would be an extremely good deal. For Wordpress.com, the GPL goal would be saved in <1yr on servers costs alone. We wrote the algorithm they're using now, and it's several generations behind. Google could decide it's low-hanging fruit for making the web faster.
But none of these potential companies are likely to be interested until we hit our first goal and we have delivered stable versions. So it's up to you, for now, to help us make this happen.Last updated:
It's hard to nail down pricing this early, but it won't exceed $185 for a 3 year license.Last updated:
Yes! Imageflow will handle overlays, alpha blending, and composition much better than ImageResizer, and is not limited to a certain number of images. Imageflow can consume and produce multiple images in a single operation.Last updated:
We hired a videographer, not an editor. Do you know one? We gained access to the Final Cut files on June 11th, so there's not really enough time make it match our requested script at this point.Last updated:
We've had a few people bring this up - angry that we sell AGPLv3 exceptions to software that we also accept contributions to (via the Apache Contributor Agreements).
First: third-party contributions to imaging software are excessively rare, usually constituting 0.5%-5% of all commits. It's not that the OSS community doesn't want to help - it's that image processing is a very, very deep domain, and it might take 6 months of weekend work to craft a correct patch to some libraries. Discrete math and signal processing is hard.
Second: Can you guess who said this? "I consider selling exceptions an acceptable thing for a company to do, and I will suggest it where appropriate as a way to get programs freed."
Richard Stallman himself. Source: https://www.fsf.org/blogs/rms/selling-exceptionsLast updated:
They are alike in that they are both cross-platform and designed to support .NET core. They are different in both product scope and focus.
ImageProcessorCore is a general-purpose image processing toolkit written entirely in C#, which greatly lowers the bar for .NET developers to experiment with codecs and pixel manipulation in a language they may be comfortable in. It's designed with the eventual goal to replace many of the common functions available in System.Drawing with an emphasis on correctness of output and ease of use. We encourage you to contribute to ImageProcessorCore development and check it out at https://github.com/JimBobSquarePants/ImageProcessor/tree/Core
If you want to touch individual pixels using C#, you should definitely try ImageProcessorCore.
Imageflow is written in Rust and C11, and makes heavy use of assembler and SIMD intrinsics. We're laser focused on server-side image manipulation, where bounded runtime cost, high throughput, and low latency are important. We only target image formats that browsers support, and while our operation-graph approach is extremely capable, it's unlikely that we will support a large range of image operators or artistic effects in the core library.
We're focused on ensuring commonly used functions are correct, extremely fast, and visually stunning, and that these functions collaborate well with image decoders and encoders to avoid many common kinds of signal loss and wasted bandwidth.
Our product focus is on end-to-end correct image handling, by default, for all images, even when given vague constraints or goals. If, once Imageflow reaches beta, you can take 20 minutes and manually produce a significantly better result for a given image and operation set, we request a copy of the data so that we can add a failing integration test and improve the codebase.
Having a common JSON API shared between the command-line, server, and FFI interface makes it easy to reuse code and modify your scaling strategy with little work, but we expect, as with ImageResizer, that the querystring API (e.g. ..my.imageflow.server/container/image.jpg?width=300 ) will remain the most popular way to use the software, and that most users won't need any integration code whatsoever.
Our goal is to enable developers with no domain knowledge to handle images and art correctly. With your help, we can succeed.Last updated:
No, but we travel quite inexpensively, and are located near a hub (Denver, Colorado).
Travel hours are free for the first trip, but billed at half-rate for subsequent on-premise visits.Last updated:
Don't see the answer to your question? Ask the project creator directly.Ask a question