PESDK for Android: a commercial photo editor SDK and its demo app

A demo app, and a README that is generated rather than written

The repository is the demo application for the PhotoEditor SDK, and the description says so plainly: PhotoEditor SDK, a fully customizable photo editor for your app.

The first thing in the README is a comment block that says the file is automatically generated by grovvy, that it should not be modified because changes will be erased, and that the file is framed by a decorative box. So the documentation you read is emitted by a generator from somewhere else, which means the prose is a template with values substituted, and it also means the repository is laid out as a generated artefact rather than a hand-maintained document.

The repository structure is a normal Android Gradle project. There is an app/ directory holding the demo application, a build.gradle and settings.gradle at the root, a gradle.properties, the gradle wrapper with gradlew and gradlew.bat, and then three directories whose names hint at the licensing model: default_res_files/, example_files/ and release-notes/. The .github directory holds the workflows, and there is a CHANGELOG.md.

The primary language is Java, the default branch is master, the last push was on 2026-09-26 and the current release tag is v10.10.16 from the same day, following v10.10.14 in April 2026 and v10.10.13 in March 2026. The homepage is photoeditorsdk.com.

One oddity worth knowing before you read the badges: the version badge in the README points at 10.7.3 and an Artifactory repository, while the release tags are in the v10.10.x range. The badge and the tags are not in step, so trust the tags for the version you would actually depend on.

The feature set is broad, and most of it is designed to be extended

The feature list is long, but the interesting pattern is that almost every category is extensible rather than fixed.

There are over 60 handcrafted filters covering style and mood settings. The API lets you add your own filters, and the mechanism described is a LUT workflow: design a filter in Photoshop, GIMP or Lightroom, apply it to a provided identity image, and the response is recorded and saved as a new filter. So the filter library is a starting set, and your own look is added by exporting a lookup table.

The Overlay tool produces lighting effects like lens flare and bokeh, and also textures like crumpled paper or plaster, and you can import your own overlay assets.

The adjustment section covers brightness, contrast, saturation and clarity. The transform section unifies cropping, flipping and rotation in one feature. There is a text feature with a replaceable font library that can be exchanged, reduced or expanded. A categorised sticker library is optimised for exploration and can be complemented with your own sticker packages. A frame tool works with any photo size or ratio, and a photo roll provides stock photography and templates in presorted categories, with an API for expansion, reduction and rearrangement.

The brush engine is described as optimised for touch screen with different brush strokes.

So the shape of the product is a complete editor whose assets are the swappable part. That is a sensible commercial model, because the engineering is fixed and the differentiation happens in the asset library, and it is also the part to interrogate: a white label editor whose fonts, stickers, filters and frames you replace is a different product from one where you adopt the vendor's aesthetic.

Two implementation notes are worth pulling out. The SDK claims a live filter preview on high-resolution images, which is unusual because it is the usual thing a photo editor gives up. And all operations are non-destructive, so a user can revise or discard work quickly, which changes the workflow from a destructive pipeline to an edit history.

The API level floor, the export ceiling and the tablet behaviour

Three platform facts are stated precisely enough to plan against.

The minimum SDK is Android API Level 21, and the README puts a number on what that covers: nearly 98% of all Android devices with touchscreen. The build SDK badge reads 31, which is the compile-time target.

The export figure is stated as fast image export up to 4294 MegaPixel. That is a specific number rather than a vague claim, and it is the kind of limit that matters for a product that lets users import large images.

Generic camera support is claimed for most Android phones, which is a separate concern from import and export, and tablet support is handled by using auto layout for the views and adapting to each screen size. The SDK is also written in Java, and the topic tags name renderscript and opengl, which suggests GPU-accelerated image processing.

The design intent stated in the overview is that the SDK can easily be customised to blend with your CI and provide the exact feature set your use case requires, and the features section says you can strip out every feature you deem unnecessary. Taken together with the extensible asset libraries, the pitch is a modular editor where the host app decides what appears.

That flexibility has a cost that the README does not spell out. Every extension point is an API surface you are depending on, and the SDK core section is where the components live. The repository is a demo rather than the SDK source, so what the demo shows is the integration shape, not the implementation.

A commercial licence is required even for a free app

The licence section is the part to read before anything else, and it is unambiguous.

The PhotoEditor SDK is a product of img.ly GmbH, and the README asks you to make sure you have a commercial licence before releasing your app. A commercial licence is required if you want to integrate the SDK into any app, regardless of whether you monetise directly through a paid app, a subscription or a service fee, or indirectly through advertising, and it applies even if you are developing a free app.

There is one exception, and it has a process attached. For a charitable project the licence is free of charge, but you are asked to make contact anyway so the vendor can evaluate whether you qualify for a non-commercial licence and handle the request.

There is also a scope limit worth noting. Every licence for the PhotoEditor SDK is valid for one product only unless the products are closely related. So a company with several apps needs to think about what counts as one product.

The repository carries a LICENSE.md file with the details, and the project licence is recorded as a custom notice that GitHub cannot classify, which is consistent with the fact that the code itself is not published under an open source licence. The repository being public therefore means the demo is public, not that the SDK is free to use.

For an engineer evaluating this, the practical consequence is that there is no fork, no vendoring and no reading of the internals in the way an open source dependency allows. You integrate against a binary artifact and a licence, and the demo repository is the only window onto the API.

Where the PESDK demo is the wrong thing to reach for

The first wrong-tool case is a project that needs an open source photo editor it can fork, audit or vendor. The SDK is a commercial binary, and the licence requires a commercial agreement even for a free application, so there is no path from this repository to a self hosted build.

The second case is a product that needs its photo editing to be a differentiator rather than a commodity. A white label editor with extensible filters, overlays, stickers, frames and fonts is a good fit when the photo editor is plumbing in the product. It is a poor fit when editing quality is the point of the product, because a large part of the perceived quality is the vendor's filter and asset library, and your differentiation has to come from the parts you can replace.

The third case is a team that needs to understand how the rendering works before committing. The repository is the demo app, and the visible documentation stops at the feature list and the SDK core section, with a mention of a generic Android Camera Stack library. The implementation is not here to be read.

There is a fourth practical consideration. The demo exists to be a reference integration, and the release history shows the SDK moving through patch releases regularly, with the last three tags within about six months of each other. That cadence is normal for a commercial SDK and is what a vendor with a support commitment looks like, but it also means the version you integrate has to be chosen deliberately and tracked over time.

What you get from the repository is a working Android application that exercises the whole feature set, which is genuinely useful for judging the API shape and the user experience before you commit to a commercial relationship. The documentation site at photoeditorsdk.com covers the rest, and the README points at a getting started page for the Android integration.

Editorial conclusion

This repository is worth reading if you are evaluating a white label photo editor for an Android app and want to see the feature surface and the extensibility model before talking to the vendor, because the demo shows the full tool set and the API shape without any of the commercial integration work. It is not worth adopting as an open source dependency, since the code is not published and a commercial licence is required even for a free app. Before evaluating further, price a licence for your product, confirm the Android API level and build SDK your app targets against the 21+ and 31 figures in the README, and read LICENSE.md rather than relying on the repository being public.

Frequently asked questions

Official sources

1. imgly/pesdk-android-demo on GitHub
2. Issues
3. Project website
4. README
5. Releases