zalando-stups / skrop

Image transformation service using libvips, based on Skipper.

Skrop  

Skrop is a media service based on Skipper and the vips library. It provides different image transformations like resizing, cropping, adding overlays, blurring and sharpening etc.

Topics

• Installing
  • Building from sources
    • Installing dependencies
  • Using Docker
  • Using Heroku
• Getting started
• Versioning
• Continuous Integration
• Upgrading dependencies
• Security

License

MIT

skrop's Issues

[Sandbox]: Add Skrop API call

Feature

We need an API call to Skrop to get new filtered image

Acceptance criteria

• API call added
• New image URL is used in Artboard

SHOULD have your own fork , to keep the commit history of the main project clean. An acceptable option is to collaborate on branches directly, and rebase instead of merge.

Add support for focal point cropping

Add a cropping filter which will allow to define a focal point for both the resulting image (as part of the eskip route) as well as a focal point for the source image (via incoming path parameters) and crop the images to align the two focal points as well as produce the desired resulting aspect ratio.

MUST use GitHub pull requests to make all repository changes, including those made by maintainers, so that we can streamline review and change tracking .

Deploy on Heroku

• Deploy a demo on Heroku
• Give a way to other users to deploy on their own Heroku accounts

Follow the README.md template

https://github.com/zalando/zalando-howto-open-source/blob/master/READMEtemplate.md

Extend Focal Point cropping filter to allow for minimum width of resulting image

The current implementation of the focal point cropping filter does not care at all about the dimensions of the resulting image. This may lead to the case where the cropped image is just a couple of pixels in width or height which is not a desired outcome.

The filter should be extended to allow for an optional fourth parameter which would set a minimum width of the resulting image. The cropping should than be done in a best effort manner, i.e. the focal point to use for cropping is either the focal point specified via path parameters or the the one which would will allow for the minimum desired dimensions of the resulting image.

The X (and similarly Y) coordinate of the source focal point is min(max(focalPointX,minFocalPointX),maxFocalPointX) where minFocalPointX is the minimum value of X for which the resulting image will still have a width of minWidth; `maxFocalPointX is defined accordingly.

MUST request review and approval from the Open Source Review Group , meeting all checklist criteria.

Project Checklist

Before presenting to the Open Source Review Group, teams/individual creators MUST meet all required criteria in this checklist:

• Complete this product analysis , which covers crafting a maintenance plan for the next six months and determines your project’s purpose. #75
  • Provide some evidence, such as online research results you conducted prior to developing the project, or results of an feedback survey your conducted within relevant Zalando guilds (Open Source Guild, front-end, cloud, Scala developers, etc.), that your work is unique and does not imitate an existing, actively maintained project.
  • Remaking someone else’s deprecated project is acceptable, as you are demonstrating that your project fulfills a once-served need.
  • Usually a one-paragraph summary/list of 3-4 bullet points defining your project’s innovative features and distinct advantages is sufficient.
• Answer this security questionnaire.
• Use the MIT license only. Include an edited license file in every repository.
• Create a README covering the points provided in our standard README template . The README MUST include a note about the MIT license at the bottom. #73
• Include a MAINTAINERS file. Every project MUST have at least two named maintainers.
• Include an SECURITY. md file in the main root folder of your repository. E.g.: “If you have discovered a security vulnerability, please email [email protected] .”
• Include a CONTRIBUTING guidelines file, plus a note in your README that you welcome community contributions. #74
• Estimate and provide the project’s current level of automated test coverage, and how you plan on maintaining or increasing that level over time.
  • Quality and testing levels are up to project owners/teams/maintainers to establish on a per-project basis, but the Review Group reserves the right to question those levels, and to reject for publication projects that don’t meet appropriate levels.
  • Tools available: there are several free GitHub integrations for this purpose, including Codacy (free for open source). We require that teams apply at least one.
• Perform code review. This involves two steps:
  • Contact the appropriate language/technology guild to request a code review. For instance, if your project is written in Clojure, go to #guild-clojure asking for code quality and a general code and architecture review.
  • Contact Engineering Productivity ( [email protected] ) to request a basic code review and recommendation. Important note: Engineering Productivity will NOT check your code continuously; please factor in this responsibility as part of your maintenance plan.

Contact OSS Evangelist Lauri Apple ([email protected]) for help in satisfying these criteria. In the coming months, we will announce the setup of an OSS Team that will help you.

Approvals will be given approximately one week after the presentation.

Team Tech Security will verify: “We performed a basic security review and found no severe security vulnerabilities.
”Team Engineering Productivity will verify: “We approve that the level of code quality suits Zalando´s deliverables.

The docker image fails to build

The docker image fails to build

Use skrop docker repo

In order to be more open source friendly, use the skrop docker repo.

[Sandbox]: Create Unsplash API call

Feature

We need to use Unspalsh API to get fashion images

Acceptance Criteria

• API call added
• App is registered in Unsplash

Add Focal Point cropping functionality to NewTransformFromQueryParams filter

The functionality that has been introduced by #96 should also be added to the NewTransformFromQueryParams filter.

SHOULD semantically version project artifacts . You MUST tag all versions in GitHub with the exact version name. E.g.: 0.1.0.

Actual Status

There is no publishing concept in this project yet. We need to onboard one, applying that rule of using semantic versioning, GitHub versions and GIT tags.

Tasks

• Document how to manually publish this project to Zalando Open-Source Docker Registry (including the manual GIT-Tag and GH-Version)
• Configure Travis CI to perform that release task (check with Arpad how they do it)
  • Should it try to continuous-deliver at each merge to master?
  • If so, how to automatically "decide" which digit of the semantic version to increment?
• Document how to manage versions (the ideal version of it, on top of the manual version already documented).

Improve documentation

Create a better structure for the docs

missing content-length and ioutil.ReadAll usage

@aryszka @rgritti
after profiling and load testing a skrop based app I found a possible source of considerable performance penalties:

skrop/filters/imagefilter.go

Line 222 in 59b76fe

buf, err := ioutil.ReadAll(rsp.Body)

when the image get read from the body and saved on the stateBag ioutil.ReadAll is used. This will start from a very small buffer and will keep duplicating the size in order to fit the image. Considering the source images are usually pretty big in terms of size, even with an exponential growth the buffer will need to be doubled a lot of times. To do that internally the Bytes.MakeSlice function will be called. This function seems not to be very efficient and under an even very moderate load will rapidly occupy the biggest part of the flame graph (usually around 70/80%). Even when the initial slice size is similar to the input and the buffer is doubled a single time, the performance impact is very high.

To avoid the usage of ReadAll something like this can be used:

buf := bytes.NewBuffer(make([]byte, 0, rsp.ContentLength)) // eventually some extra bytes could be added to make sure no makeSlice will happen
_, err := buf.ReadFrom(rsp.Body)

// use buf.Bytes() to pass around the read bytes

of course if content-length is not set in the source there is not much we can do, but one idea may be to have an option to have a fallback initial buffer size that can be customized accordingly to the average size of the inputs.

Playing around with this approach I also discovered another strange behavior:

skrop/filters/imagefilter.go

Line 185 in 59b76fe

rsp.Body = ioutil.NopCloser(bytes.NewReader(buf))

during the FinalizeResponse the body is set to a buffer reader, I was expecting that the content-length would be set automatically accordingly to the size of the buffer, but it is actually not set, this means that having a loopback filter that will have to read from the body will lead to the same fallback case where we cannot rely on content-length in order to initialize our buffer. I tried to manually set rsp.ConentLength to the length of the buffer, but I'm not sure that is the most idiomatic way to solve the issue and it also look like the buffer size is not enough to avoid a buffer doubling and some extra bytes need to be added (tried with 4k and it never called makeSlice)

Automatic Github and Docker releases from Travis

Automatic Github and Docker releases from Travis

Use go modules

• The compatibility bug was solved on h2non/bimg so we would like to revert the bimg library.
• we would like to use go modules to manage dependencies

[Sandbox]: Create Sandbox Application

As a user
I want to be able to play with filters in web app
So that I can get proper URL for Skrop

MozJPEG support

Hi,

From libvips docs it looks like that it's not using mozjpeg compression by default. But since skrop service supposed to be used for processing pictures for Web, it would make sense to enable compression using mozjpeg. Compression time would slightly increase, but at the end resulting file size would be reduced.

Limits of bimg

Currently skrop is strictly coupled with bimg for all the image processing.

While bimg provides a good coverage for the basic operations it is a very limited wrapper on top of all the vips capabilities.

Ideally would be nice to use vips bindings directly. Of course bimg comes out of the box with some nice abstractions and wrappers to overcame the nightmare of all the segmentation faults that we may have using the bindings directly.

One option may be to just copy the part of bimg that we need, or to fork it.

A concrete example of the limits is customizing the jpeg encoding settings.
we cannot pass down the no_subsample option, leading to very poor quality for compressions lower than 85, also we cannot use different quantization tables (mozjpeg one may lead to better quality), and some other advanced settings that could allow us to fine tune the quality and the size of the images

SHOULD sign every commit.

Use docker image for running tests

To speed up the CI

[Sandbox]: Add mocked images for first screen

Feature

Skrop supports file system only for now, so we need to add predefined images

Acceptance Criteria

• Predefined images added

Create more stages in Travis

Create more stages in Travis in order to have a more modular build

Move sandbox(website) to a separate repository.

Let's do not merge sandbox/website feature branch to the master branch, instead let's create a separate repo for a website.

Few ideas how to move forward:

1. Have two projects under STUPS by Zalando github org: skrop and skrop-website.
2. Use monorepo and have both projects under the same repo name skrop.

As an additional point I would think of migrating skrop from STUPS by Zalando github org to Zalando SE github org.

Add a project skeleton

Feature

Add the project UI skeleton

Introduce better compression

Integrate the guetzli library from google.

[Sandbox]: Create First Screen with Unsplash

Feature

Create a first screen of the Sandbox Application that contains preloaded images from Unsplash.
Use already created branch: https://github.com/zalando-stups/skrop/tree/142-unsplash-screen

##Design

Take a look at 1 Screen: https://share.proto.io/GXTZBH/

API

API call should be provided by #151

Acceptance Criteria

• A user can click on an image
• When a user clicks on an image the editor opens

Avoid calling the image transformation multiple times

Avoid calling the image transformation multiple times, for filters which are not merged

Create a local cache

Create a local cache

Implement new crop by focus area filter

A filter that based on a focal point and desired width and height returns the cropped version of a give image

Create the CONTRIBUTING.md file

Use the template

[Sandbox]: Add filters models & factory

Feature

We need to create filters TypeScript models that represent filter fields with respective types.
Also we need to add factory that generates Semantic UI React components according to the type, e.g. if property type is boolean it should return Checkbox component.

Supported filters:

• Resize
• Crop
• Blur
• Overlay
• Background

Acceptance Criteria

• Filters models created
• Factory produces React components based on the filter name (string value)

Improve the build time

• Create an intermediary image for vips and alpine, so that the build and CI doesn't take so long
• Make releases automatic
• Don't create docker image during travis build
• Use apt packages from travis and cache them

Building a Useful, User-Friendly Project

Follow the rules here

Upgrade dependencies

• go version
• vips version
• skipper
• alpine

Instrument with opentracing

Stripping Metadata

currently image.Process will not strip image metadata.
We could either default to strip it here

skrop/filters/imagefilter.go

Line 194 in d97836a

func applyDefaults(o *bimg.Options) *bimg.Options {

in order to have a smaller default output

or we can provide a filter to add the required option.

[RFC] Filters for caching

There are many parameters caching filters can take. Based on these, they can look different. The goal of this issue is to identify the best way these caching filters can look like. Here are different options:

Putting they type of cache in the filter name and create many filters:

localFileCache(directory)
inMemoryCache(namespace)
s3Cache(url, username, password)

Giving the caching strategy as a parameter:

cache("localFileSystem", directory)
cache("memory", namespace)
cache("S3", url, username, password)

There are other questions as well, like should we give the caching parameters to the filter, or should they be configured once, when skrop starts? In case there is a global config, the filters could look like:

localFileCache()
inMemoryCache()
s3Cache()

Note: This approach brings less flexibility, as parameters can't be configured for each route

There might be other options as well. Let's discuss about this!

MUST only publish/upload your projects to https://github.com/zalando-incubator

[Sandbox]: Add Heroku configuration

Feature

We need to add a Heroku configuration in order to deploy project there.

Acceptance Criteria

• Heroku configuration added
• README section how to deploy added
• Sandbox App is deployed

[Sandbox]: Save React state

Feature

We need to save React state in localStorage and hydrate it when page refreshed

Acceptance Criteria

• Every time React state is updated state is saved to localStorage
• When page is refreshed previous React state is hydrated

MUST follow the SDLC Rules and use Zappr to ensure the four-eyes principle, even when integrating code implemented by an external contributor.