Beta Labs:

Beta labs is where we will present new functionality and let people try it out. It will be fully supported going forward, it just may have kinks that we need to work out.

Beta labs assumes a working knowledge of how Blitline works, because these functions fall outside the scope of regular Blitline functions.


Some jobs and workflows do not fit in to the linear, asynchronous flow of a Blitline job. To help accomodate these we have added a "pre_process" tag which allows you to define functionality that can happen "before" the Blitline job is executed. This "pre_process" tag can contain any of the following "functions" formatted in the standard Blitline syntax.

  • "move_original"
    This will move the original source to an S3 destination before executing the Blitline job.
  • "resize_gif"
    Because GIFs are a very different beast than regular images, we cannot pass them through the regular Blitline job path. Resizing of GIFs require an external application to be used this we need this to happen outside the context of a Blitline job.
  • "resize_gif_to_fit"
    Same as resize_gif but behaves like the Blitline "resize_to_fit" function.
  • "gif_overlay"
    Overlays an image onto a gif. Perfect for watermarking your gifs
  • "jobs"
    We have had a bunch of feedback regarding the ability to process 1 image and then use that 1 image IN a different Blitline job. Usually this occurs when compositing images, and you want to resize image "A" and the composite it on to a resized image "B". With the current implementation, this takes 2 separate Blitline jobs. By having jobs in a "pre_process" tag, you can assure that 1 job is done before executing another job, thus providing a "synchronous" queue of image processing.

    In other words... pre_processed "jobs" will be executed BEFORE the main Blitline job. You can also reference those pre_processed images in your main Blitline job.