Continued scalability improvements. Since June 2015, main deployment is using guv for automatic scaling of Heroku workers.
POST /graph/allows to cause processing to happen without waiting for response. Otherwise identical to the syncronous
- Supports a
noopgraph, which cannot process images, just cache them. Useful for proxying, like for getting rid of HTTP/S mixed content warnings.
- Output image size now has a (configurable) limit, will return HTTP 422 if exceeded.
- Failure to download input images now gives an informative HTTP 504 instead of 500 internal error
New processing graphs
- Redis cache frontend for Amazon S3, makes cache checks much faster (since 0.4.10)
- Decicated worker(s) for urgent (GET) jobs, avoids non-syncronous jobs (POST) blocking.
- Pub-sub connection from workers back to web, allows multiple web frontends (since .
- Processing is separated by runtime type (imgflo, noflo), as they have different perf/scaling characteristics
- S3: Content-Type header is now correctly set for processed images.
- Fixed a image corruption issue with high concurrency rates, due to different requests overwriting same files.
- Fixed wrong parsing on inputs without Content-Type and query parameters
- New Relic can optionally be used for metrics reporting
- Since 0.4.16 using cedar-14 stack on Heroku instead of old 'cedar'.
- Since 0.4.40 using nodejs 0.12
Released: March 4, 2015
Processing is now separated from the HTTP sever frontend. On Heroku, it is ran as a separate dyno role on Heroku. This allows to scale these independently, which is very desirable for a good cost/performance ratio. For smaller setups, the workers can still be ran 'internally' in the web process.
The web frontend and worker(s) communicate using AMQP, with RabbitMQ as the broker. MsgFlo APIs and tools is used to make this easy.
- demoapp: Added visual previews available graphs
- demoapp: Make responsive for different screensizes, using GSS
- API: Attempting to use unsupported output types now return HTTP 449
Released: January 23nd, 2015
See-also imgflo-runtime release notes
Fix Heroku button deploy not working due to git submodule.
Add support for custom GEGL/imgflo operations. Ops dropped into components/* will be built & installed.
Local cache is now default, use
IMGFLO_CACHE=s3 to use Amazon S3.
Fixed very large output files sizes for PNGs. Was using 16 bits-per-channel and very low compression. Output now 5-10 times smaller.
Added support for noflo-canvas graphs to act as filters on input images,
not just purely generative. The
canvas input port will now contain the
input, if any.
Add support for scaling by passing only one dimension (height/width). The image will then be scaled by preserving input aspect-ratio. Explicitly passing a value of -1 can also be used to mean "not specified".
Added a set of image filters inspired by those used by Instagram: Lord Kelvin, Brannan, Nashville, Hefe, XProII and 1977.
The demo webapp will now remember API key/secret using LocalStorage, if entered.
Released: October 28th, 2014
imgflo-server has now been stress-tested and improved to be good enough for a typical website, meaning one which does not change/add images more than a couple times a day. It is now used in production at thegrid.io, serving 10k++ visits/day.
Moved to separate git repository jonnor/imgflo
Added support for more IIP types in HTTP API,
including enums, booleans and CSS-compliant colors on format
#RGB[A] and #RRGGBB[AA]
Added support for optionally specifying desired output image format,
/graph/mine.png|jpg instead of
Default image format has changed from PNG to JPEG.
GET /graph requests now support
width query parameters,
which will rescale the image to requested size.
NB: Specifying only height/width not supported.
Added support for authenticated requests using API key + secret.
IMGFLO_API_SECRET=some-secret to enable.
The full syntax of API requests is now:
Where $APIKEY is the configured IMGFLO_API_KEY for the server, and
$TOKEN is the md5sum of
GET /graph requests will now return a
301 REDIRECT to the processed result,
which may be already computed and cached.
An Amazon S3 bucket can be used as as cache instead of caching on same host.
IMGFLO_CACHE=s3 to enable, and
AMAZON_API_REGION to configure.
HTTPS is now supported and, used by default with Heroku and Amazon S3 cache.
Graphs are now stored in /graphs directory instead of /examples, which means that the project can be imported directly into Flowhub and one can push new graphs from there.
Default GEGL build now includes the 'workshop' operations.
New graphs included:
gradientmap now supports 5 stops instead of 1.
Released: April 30th, 2014
imgflo now consists of two complimentary parts: a Flowhub-compatible runtime for interactively building image processing graphs, and an image processing server for image processing on the web.
The runtime combined with the Flowhub IDE allows to visually create image processing pipelines in a node-based manner, similar to tools like the Blender node compositor. Live image output is displayed in the preview area in Flowhub, and will update automatically when changing the graph.
The server provides a HTTP API for processing an input image with an imgflo graph. GET /graph/mygraph?input=urlencode(http://example.com/input-image.jpeg)¶m1=foo¶m2=bar
The input and processed image result will be cached on disk. On later requests to the same URL, the image will be served from cache.
The server can be deployed to Heroku with zero setup, just push the git repository to an Heroku app.
The operations used in imgflo are provided by GEGL, and new operations can be added using the C API. A (somewhat outdated) list of operations can be seen here: http://gegl.org/operations.html
Released: April 8th, 2014
Can execute a simple graphics pipeline with GEGL operations defined as FBP .json.