About this project
Pledge $1 or more for continued early access to binaries.
Imageflow includes an HTTP image server, an HTTP image proxy, a dynamic library for direct FFI use, and a set of command-line tools (one of which you can download today). Source code on Github. List of planned language bindings here.
Hours left to back Imageflow and have us revolutionize your image handling & #webperf! More speed = more sales.
Imageflow is open-source software which scales, edits, and optimizes images. It’s similar in purpose to our existing software, ImageResizer, but is faster, produces better results, and is not bound to the Windows API. Imageflow supports Linux, Mac, and Windows – and can be used from any programming language.
Imageflow is the first solution to offer uncompromising security and visual quality – but it also trounces competitors in benchmarks. It lets millions of websites and applications fix the weakest link in their server security and will enable new ventures that require instant, on-the-fly image processing.
Kickstarter automatically re-processes all images, so our visuals below are blurrier than we'd like. In fact, Kickstarter would be a perfect candidate for imageflow-server, which would make the following images much sharper!
There are two components to Imageflow: imageflow-server and libimageflow. libimageflow is built with C11 (and soon Rust), and imageflow-server (when created) will use Rust exclusively.
Imageflow-server can be deployed to the cloud in just a few clicks, and can be used by editing URLs in your browser (figure B) or by using the REST APIs. Imageflow-server sends the right number of pixels based on your device size (figure A), and can cut load time in half for responsive websites that haven't yet implemented responsive images. Reducing site load time is often the cheapest way to boost sales and SEO ranking.
With imageflow-server, you can map prefixes to different backend storage locations, like S3 or other HTTP servers. If you’ve been putting off moving to responsive images, imageflow-server will help make the transition painless.
For large deployments, you can fully offload all imaging operations to separate servers.
libimageflow is the image library you wish your stack shipped with. It’s correct, fast, safe, and has an evolvable API. It creates compact and sharp files. Its API was designed to work with even the most troublesome multi-tenant host languages.
What problems does Imageflow solve?
Image toolkits and codecs are a notorious exploitation vector. ImageMagick is intended to be used in a sandbox. In practice, it is most often run by privileged server accounts. A recent string of vulnerabilities in ImageMagick was given the ImageTragick moniker to raise awareness prior to the hacking of many sites. Even after the ImageTragick patches, ImageMagick still has unfixed remote code execution vulnerabilities which are equally easy to exploit.
Solution: Imageflow puts security first by retaining a small and testable codebase, being cautious with dependencies, and making Coverity scans and Valgrind testing an automated part of the development process.
ABYSMAL VISUAL QUALITY
Most visual artefacts you see in images today are entirely avoidable. Decades of hacky approximations, bad mathematical and color space reasoning, and legacy compression behaviors combine to establish a very low bar for image quality.
Solution: With correct math and highly optimized encoders, Imageflow sets a new bar for image quality. We're rebuilding everything from the ground up while performing exhaustive testing of inputs, lookup tables, and tuning parameters.
BLOATED FILE SIZE
Images make up the majority of bytes on most websites. Images usually average 2-3x larger than necessary for the same perceptual quality.
Solution: Imageflow focuses on a smaller set of highly tuned codecs, and should outperform ImageMagick by a significant margin across all file types. We’re seeking licensing agreements for libimagequant and other best-in-class algorithms as well.
Basic ImageMagick operations can take seconds per image. For on-demand imaging in e-commerce, there’s a hard latency ceiling before you start losing customers, and it’s far lower than 1500ms.
Solution: There’s no valid reason your web server can’t deliver image quality on par with Adobe Lightroom, and do so in 8 to 200 milliseconds. Imageflow enables that scenario. We don’t need to shy away from on-the-fly image processing; we just need to focus on it and invest in our tools.
How does Imageflow relate to ImageResizer?
Imageflow is ImageResizer’s future. Without it, ImageResizer can’t become cross-platform, run on .NET Core, or be deployed on Windows Server Core.
The Kickstarter 18-month transitional support contract (for both ImageResizer and Imageflow) is the only way to get paid ImageResizer support.
Your support in backing Imageflow will make ImageResizer 5 a reality. And if you just can’t wait, it’s possible to use libimageflow from C# today (if you’re willing to P/Invoke).
What are the benefits of using Imageflow?
Our promise with Imageflow is to deliver security, image quality, and speed – in that order. Read our pledge to you.
- libimageflow can be used directly over FFI by any mainstream language. The second component, imageflow-server, speaks HTTP – and any networked device can use it. A human can use it from their web browser by adding ?width=200 to the image URL (or any of 30 other commands).
- libimageflow has ~10x the throughput of ImageMagick, yet puts security first. It is correct, fast, and has an evolvable JSON API. Imageflow doesn’t try to be ImageMagick; it supports only the core image operations and web-safe image formats needed by most applications and websites.
- imageflow-server offers a JSON API – You can POST a JSON operation list or graph along with multiple inputs and outputs, and the results are returned to you. libimageflow can accurately predict the cost for any operation, which permits ideal work redistribution and load balancing.
- Imageflow supports Linux, Mac, and Windows.
What about existing projects?
We've been very thorough, and we would not be running a Kickstarter if an existing library was suitable to this task.
Here we explain why the most popular libraries don't work for us due to poor image quality and security. If you'd like us to cover a specific library, just contact us or open a Github issue.
Why back our Kickstarter?
- Licenses are 41%, 61%, and 85% off. You’ll pay up to 7 times more if you buy later.
- For just $600 (instead of $2,900) you can sell a hosted version of imageflow-server. This ultimate redistribution and SaaS license is restricted to B Corps or small businesses that meet the revenue limits.
- If you’re an ImageResizer user, the Transitional Support Contract is the only way to purchase paid support.
- It’s the best (and cheapest) way to get 1-on-1 consultation and support.
- It’s the fastest way to remove the liability of ImageMagick from your infrastructure.
- Support and transition assistance is heavily discounted via the Kickstarter.
- This is a very low-risk project.
Imageflow can’t happen without your support. We’ve invested 4 years and over $100,000 in solving the hardest problems specifically for Imageflow. We now face a long list of clearly defined tasks with known solutions, but need your help to complete Imageflow and bring it to to your platform and tools.
It’s crucial that we ensure a sustainable model for security maintenance, so much of Imageflow will remain copylefted until we reach a funding level that can guarantee long-term support for you, our customers. Your help in promoting this Kickstarter is essential to its success.
- $50,000 (expenses only) – Proceeds will cover our hardware, software, project, and hosting expenses for the next year of development, and fund collaboration with some of the world’s best compression and optimization experts. At this funding level, Imazen covers all in-house labor costs and Imageflow will be licensed as AGPLv3 with commercial options.
- $125,000 – Support contracts for Imageflow will be made available on an ongoing basis, even after the Kickstarter ends. Official C# bindings & Core CLR support will also be guaranteed at this level. (We now have a volunteer for unofficial bindings, so you may see C# support sooner!)
- $200,000 – We create official PHP bindings and integrate libimageflow with Wordpress. Imageflow becomes GPLv2 + GPLv3 dual licensed so it can be distributed with Wordpress. GPL licensing would make commercial SaaS licenses redundant.
- $500,000 – We immediately relicense Imageflow as MIT/Apache 2 so it can be redistributed with every platform, language, tool and CMS. This level funds extended codec research and optimization, with potential 2x performance increases. Apache 2 licensing would make all commercial licenses redundant.
Much of our work on Imageflow will involve improvements to existing projects (like libjpeg-turbo/mozjpeg and libpng). This work will not be copylefted, but licensed as the original project.
We have also granted LibGD (the most widely used image manipulation library on servers today) license to back-port any code from Imageflow that they can use. In 2013/2014 we focused on improving LibGD and adapting it for potential use from .NET (libgd.net). In 2015 we had to pivot to our own library due to scope and API differences we couldn't work around without sacrificing core design priorities, and we started laying the groundwork for Imageflow.
All backers get early access to binary releases and regular updates about the project. We’re developing with transparency, in the open, at github.com/imazen/imageflow.
- July 15th, 2016 (alpha release of imageflow-tool) You’ll be able to experiment with a command-line version of Imageflow before the end of July. This will let you verify imageflow meets your needs - and give us immediate feedback if it doesn’t.
- July 1st, 2016 ImageResizer to Imageflow Transitional Support Contracts begin (18mo, Platinum tier).
- September 1st, 2016 Clock starts on timed licenses (if we have a usable beta – otherwise the clock starts when a usable beta is released).
- October 1st, 2016 Imageflow Platinum Plus Integration Contracts begin (12mo, Platinum Plus).
- August 1st, 2017 (stable release of imageflow-server and libimageflow) Official Ruby and Node bindings for libimageflow will be available at the this time.
- October 1st, 2017 Everyone has their license keys, and license key enforcement is enabled.
- December 1st, 2017 We deliver official C# bindings (if we hit the $125k stretch goal).
- January 1st, 2017 We deliver official PHP bindings (if we hit the $200k stretch goal).
***Anyone who pledges $1 or more during the Kickstarter will receive free early access to binaries.
Risks and challenges
Ten years of image processing research has given us a solid foundation, some well-proven scaling algorithms and has enabled us to create a working prototype of the operation graph execution engine. We do not anticipate risks related to speed or image quality.
However, our comprehensive strategy for blending document type detection, automatic codec selection, and tuning has not yet been proven. But the independent techniques have been explored and we are optimistic that we can bring them together.Learn about accountability on Kickstarter
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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
It's hard to nail down pricing this early, but it won't exceed $185 for a 3 year license.
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.
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.
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-exceptions
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.
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.
Support this project
- (26 days)