imgflo-server is an image-processing server with HTTP built using the imgflo dataflow runtime.

See ./CHANGES.md

MIT

Note: GEGL itself is under LGPLv3.

imgflo-server provides a HTTP API for processing images. The entire processing request is described using an URL, and the processing can be triggered by a HTTP GET. This means no special integration is needed in order to use an image processed by imgflo-server in an application.

Request

GET /graphs/mygraph?input=http://example.com/input-image.png&attr1=value1&....

Response

HTTP 301
Location: https://s3.aws.com/bucket/er132123sder12.png

If the image has been processed before, it will come straight from cache (fast).

Request

POST /graphs/mygraph?input=http://example.com/input-image.png&attr1=value1&....

Response

HTTP 301
Location: https://s3.aws.com/bucket/er132123sder12.png

Since the image is not processed by the time the response arrives, accessing the Location immediately will likely fail (with a 404 or 403). If the image processing failed, it may fail forever. Use a GET with the same imgflo URL to get the error.

The inports describe which parameters are available for each graph.

Request

GET /graphs

Response

HTTP 200 application/json

{
  "graphs": {
    "customgrey": {
      "inports": {
        "input": {
        },
        "height": {
          "metadata": {
            "description": "Requested output height",
            "type": "int",
            "maximum": 2000,
            "minimum": 0
          }
        },
        "width": {
          "metadata": {
            "description": "Requested output width",
            "type": "int",
            "maximum": 2000,
            "minimum": 0
          }
        }
      },
      "outports": {
        "output": {
        }
      }
    }
}

By specifying an extension on the graph, you can

/graph/gradientmap.png?width=300....

If the extension is omitted, a default image format is inferred. This is currently the same image format as the input.

To prevent people from using your deployment to process their images, there exists a version of the processing URL scheme which uses encryption to secure it. Note that this only prevents people from forming new image processing requests. It does not prevent them from requesting an already processed image.

Each client has its own KEY and SECRET.

Given a request with a set of parameters (like gradientmap.png&width=300&input=...), a token is constructed by taking the md5sum of the SECRET concatenated with the parameters:

token=md5(parameters+secret)
GET /graph/$KEY/$token/$params

Upon getting such a request, the server will use the KEY to find the matching SECRET, do the same construction of token, and validate that there is a match. If not, request will fail with a 403 Permission Denied.

Use the helper script

./bin/imgflo-server-application-add

It will generate client key and secret, insert it to the database, and output the details to stdout.

If processing_quota field is 0, the client cannot process new images, but can still request existing cached/processed images.

Currently processing quota is not otherwise enforced.

To disallow clients from also accessing cache/processed images, set enabled to false/0.

There is currently no tools for manipulating quota, have to use SQL on the applications table.

• 504: Unable to fetch the specified input URL
• ...

These libraries make it it easier to use imgflo-server, by providing a programmatic API which handles the details of constructing authenticated URLs.

1. Forming valid imgflo urls: imgflo-url
2. Creating responsive images using media-query: rig

imgflo-url-java

ImgFlo.swift

imgflo-server ships with a simple testing UI served at /. It can be used to see the available graphs, and make test requests and see the results.

TODO: add picture

Given a regular imgflo URL, you can add &debug=1 at the end to open it in the UI. It will extract the parameters, including removing the urlencoding on the input URL.

imgflo-server can easily be extended with new image processing pipelines, either using a text-based DSL or Flowhub node-based visual IDE.

See Adding Graphs

For an in-depth look at how the system is implemented, see system architecture

Currently our deployed instance is only for The Grid. If you are interested in access to hosted version, send us an email: [email protected]

Register/log-in with Heroku, and create a new app. First one is free.

After creating the app, login at Heroku:

heroku login

Clone imgflo-server:

git clone https://github.com/imgflo/imgflo-server.git
cd imgflo-server

Add YOURAPP as remote:

heroku git:remote -a YOURAPP

Specify the multi buildpack with build-env support, either at app creation time, in Heroku webui or using

heroku config:set BUILDPACK_URL=https://github.com/mojodna/heroku-buildpack-multi.git#build-env

Configure some environment variables (hostname, port and local image cache):

heroku config:set HOSTNAME=YOURAPP.herokuapp.com
heroku config:set PORT=80

Deploy, will take ~1 minute

git push heroku master

You should now see the imgflo server running at http://YOURAPP.herokuapp.com

If everything is OK you should be able to see a generative image at http://YOURAPP.herokuapp.com/graph/delaunay_triangles?seed=foobar&height=800&width=600

Note: imgflo-server is only tested on GNU/Linux systems. imgflo (the runtime) has experimental support for OSX. However, all underlying dependencies (node.js, RabbitMQ, GEGL etc) are commonly used also on other platforms, like Windows.

Root is not needed for any of the build.

imgflo requires git master of GEGL and BABL, as well as a custom version of libsoup. It is recommended to let make setup this for you, but you can use existing checkouts by customizing PREFIX. You only need to install the dependencies once, or when they have changed.

git submodule update --init --recursive
make dependencies

Install node.js dependencies

npm install

Now you can build & install imgflo-server itself

make install

To verify that things are working, run the test suite

make check

node index.js

You should see your server running at http://localhost:8080