How I Build Image Processing Pipeline

This is a post that I have been putting off for a while, but I think the time has come to share this with the community. Two years ago I sat down to start a new project, an experiment involving image downscaling and Node.js, and since then it has become my primary open-source project.

I wanted to generate responsive images for my website to offer a better experience. It came to life as a set of Node.js scripts, and over the course of several iterations, evolved into an open-source package released on npm under the name Responsive Image Builder.

It was created out of necessity due to a lack of existing open-source solutions.

Let me be clear, there are a variety of image tools, loaders, and . However, none of them, in my opinion, fulfilled my needs. Furthermore, I was in love with and the by Michael Fogleman (which was difficult to integrate into existing solutions).

This led me to create my own solution to solve my rather unique requirements:

• 🔥 Fast (obviously...)
• 💎Best image algorithms (Lanczos3 😎)
• 🌁 Support beautiful SVG placeholders such as the primitiuve library
• 🙏 Simple
• OS-agnostic, free, parallization, no network round-trips, no upscaling, ...

My goal was to glue together existing image libraries into a unified toolset that could be customised to allow processing of images in different ways.

Psst! You can read more about the motivation behind the project .

Today it goes by a different name that better reflects its new functionality (and partly due to a reserved package scope ️🤦‍♂️): Image Processing Pipeline. The processing "workflow" is now completely customisable and it has also just had a major release that refactored the internals, making it easier to implement adapters, such as the new webpack loader!

The new IPP features a declarative pipeline format. Tell it *how* it should generate your images!

Much to my own surprise, the open-source repository on GitHub has been slowly gaining stars, an issue and even featured in an , despite never sharing or mentioning the project online. I wanted to wait for a truly stable release of IPP before announcing it officially, but it seems that the online community is restless and eager to try new things!

Perhaps this is the right time. Summer is coming to an end and my university studies have resumed. I am, however, still fully committed to maintaining the project for the foreseeable future. It is, however, an enormous undertaking for a single contributor, so don't expect nightly releases.

Maybe try using it on a smaller project and see if it suits your needs. If you feel like contributing, PRs are welcome! Bear in mind that the aim is to keep the core as simple as possible to promote maintainability and not feature float.

IPP is not limited to website development, but may also prove useful for batch image processing or backend image jobs, as it does not require any code to use.

I have been hard at work creating a new documentation website that is accessible for users of all technical backgrounds. Bear in mind that it is still an active work in progress. Until it is completed there is also the option of consulting the , which aims to be simple and human-readable.

Let's dive in

The following section is a quick-start guide for the command-line interface. A more complete example is available at the website above.

Prerequisites

IPP runs on Node.js and is distributed via npm. They are bundled together and can be obtained from the .

It's recommended to get an LTS release or a less recent version of Node.js to avoid installation problems.

Installation

Open up a terminal somewhere and execute the following (without the dollar sign), which will install the CLI globally on your system (other installation options are available):

$ npm install --global @ipp/cli

And that's it! ✨

Once again, if you get a node-gyp related installation error, try an older release of Node.js to avoid having to install Python and a C++ compiler. This is a design limitation, compiled languages are hard and IPP wants to be fast!

Usage

Grab some and chuck them into a new folder with a name of your choosing.

Next to that folder, create a configuration file called 

.ipprc.yml

input: images
output: formats

manifest:
  source:
    x: hash:12
  format:
    w: width
    p: path

pipeline:
  - pipe: resize
    options:
      resizeOptions:
        width: 1280
    save: "[source.name]-[hash:8][ext]"

Next, open up a terminal prompt, navigate to the folder containing the configuration file and run IPP:

$ ipp

If everything was set up correctly, IPP will display some helpful runtime information and report a successful operation. There should now be a second folder called formats with a bunch of new images!

So what did it do?

The above configuration file takes each source image and resizes it to have a maximum width of 1280 pixels. Images smaller than this threshold will not be resized but passed along. This is where IPP starts to shine! The image is then saved, using IPP's version of template literals to generate the filename.

Additionally, notice the manifest.json file in the formats directory. This contains a JSON summary of all output results. For example, you might find an entry that resembles the following:

{
  "f": [
    {
      "w": 1280,
      "p": "red-green-macaw-74cd8540.jpg"
    }
  ],
  "s": { "x": "7f5d4e26980c" }
}

The manifest file is generated based on the

manifest

Tip: the source hash is generated from the file contents and will never change, it could be useful as an image-lookup mechanism

IPP is not a blind resize tool but is context-aware. It also aims to make the consumer (such as the browser) aware by providing a list of available images, and letting them pick the best-suited image based on image dimensions, codec, etc…

The manifest file can be further processed or it can be downloaded and cached by the client. There are even better options, such as the that convert image imports into a single manifest entry, like the example above.

How does it work?

A single image transformation is represented by the concept of a pipe. In reality, it's an asynchronous pure function (you can even make your own!).

An image is represented by a binary buffer and a metadata object. They are related pieces of data and therefore stay together (internally referred to as a DataObject). Metadata provides contextual information about the buffer and is slowly "built up" by each pipe.

Pipes may be interconnected using the

then

- pipe: resize
  then:
    - pipe: compress
      save: "[source.name][ext]"
    - pipe: convert
      ...

Every pipe may additionally specify a

save

This is the basic architecture of the

@ipp/core

Ready for more?

Thank you for sticking to the end! There is a lot more that you can read in the .

There are more planned features, such as asynchronous iterator support to improve memory efficiency, optional disk-based caching, more adapters, front-end integrations, …

This is my first article on an open-source project and I'm excited to hear your comments and feedback! 😁 What workflows do you use for your images?

P.S. I'll be absolutely gutted if someone replies with "hey, this already exists, check out…". At least it was a great learning experience, right…?

Also published at