# PixelFreeEffects: a cross-platform beauty and retouching SDK for camera and video apps

> PixelFreeEffects is a C++ beauty and retouching engine for mobile and desktop applications, covering skin smoothing, face reshaping, body reshaping, makeup, colour grading, filters, 2D stickers, green screen keying and watermarks across iOS, Android, HarmonyOS, Windows, macOS, Linux and Flutter. The repository ships platform bindings, integration docs and demo apps rather than a single library, and the documentation is written in Chinese.

**uu-code007/PixelFreeEffects** — ✨ 望图 PixelFree 美颜SDK - 全平台美颜特效引擎（iOS/Android/harmonyOS/windows/macOS/linux）| 直播/短视频/相机/照片处理 | 高性能+轻量级

- Repository: https://github.com/uu-code007/PixelFreeEffects
- Stars: 1,032 · Forks: 96
- Language: C++
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/uu-code007-pixelfreeeffects

## The effect catalogue is the product

The functional list in the README is long, and reading it is the fastest way to understand what this SDK is for.

The basic beauty group covers whitening, skin smoothing, reddening, sharpening, eye brightening, removal of nasolabial folds, removal of dark circles, teeth whitening and AI blemish removal. Skin detail work adds texture, clear soft light, highlight soft light, water light and matte, each with a 0 to 1 intensity. Skin tone adjustment offers natural, fair, pink white, wheat and tanned, with a tone degree and a cool or warm colour temperature control. There are 50 filters, and one-click beauty presets in natural, cute, goddess and clean styles.

The reshaping group is the longest list in the table and it is the one worth reading closely, because it shows the granularity of the implementation. It covers eyes, face, cheekbones, forehead, chin, nose, jaw, short face, philtrum, eye spacing, smile corners, eye rotation, eye opening, upper and lower eye position, eye height, nose size, nose height, nose vertical position, nose tip, nose bridge, brow thickness, brow length, brow lift, brow spacing, brow tilt, upper and lower lip thickness, lip fullness and lip width. That is around thirty distinct geometric parameters on the face alone.

Body reshaping is a separate group with its own enum, PFBodyBeautyType, and a stated default of 0.5 for neutral with a range of 0 to 1. The parameters cover slimming, waist, hourglass figure, curves, overall slimming, hip lifting, buttock enhancement, breast enhancement, long legs, swan neck, shoulder slimming, straight shoulders, arms, upper arms, thighs and calves, split into left and right for the arm and leg pairs.

There is also a camera colour grading group with brightness, contrast, exposure, highlights, shadows, saturation, colour temperature and global HLS, 60 2D face stickers, a custom watermark that takes an image and a position, and 10 full makeup looks with adjustable intensity for brows, blush, eyeshadow, eyeliner, mascara, lip colour, highlighter, shading and foundation.

The stated design goal for the skin work is that smoothing preserves more detail, so that beautification and realism coexist. That is the hard problem in this field, since over-smoothing is what makes consumer beauty filters look like a mask.

## Nine platform directories, and a shared C++ core

The repository layout is the clearest statement of the architecture, and it is a set of per-platform packages rather than a single library.

The directories are SMBeautyEngine_andriod, SMBeautyEngine_flutter, SMBeautyEngine_harmonyOS, SMBeautyEngine_iOS, SMBeautyEngine_linux, SMBeautyEngine_mac, SMBeautyEngine_uniapp, SMBeautyEngine_win_python and SMBeautyEngine_windows. There is also SMUpdateService, a separate directory for the update mechanism, and a pixbuffer.podspec at the root for the iOS pod packaging.

So the pattern is a shared core with a thin binding per platform. The primary language is C++, which is the right choice for an image and video processing engine that has to run at camera frame rates on a phone, and the bindings exist to expose that core to each platform's native language or to a cross-platform framework.

The supported platform table in the README lists the system version requirements. iOS above 9.0, Android above 5.0, Windows above 10.0.0, HarmonyOS above 12.0, Flutter 3.3.0 or newer, and Linux is listed as supported with no version constraint given.

The two entries that stand out are HarmonyOS and Flutter. HarmonyOS is a recent addition and has its own directory, its own documentation entry and a minimum version of 12.0. Flutter has its own directory, its own doc and its own minimum version, and the presence of a win_python directory suggests a Python binding for Windows alongside the native ones.

The uniapp directory is the one whose purpose the README does not explain. UniApp is a cross-platform application framework, and the directory name implies a binding for it, but there is no uniapp entry in the integration documentation list, which covers iOS, Android, Flutter, Windows, the FAQ, the release notes and custom stickers.

That gap is worth noting if UniApp is your target, because the docs do not cover it.

## Green screen keying is not segmentation, and the README says so

One line in the feature table deserves to be quoted in full, because it is the kind of thing that is usually left ambiguous in a vendor README.

The green screen background replacement entry says it only removes a green background, and that it is background replacement, not person segmentation.

That is a real limitation and a real distinction. A chroma key removes pixels matching a key colour, which works when the background is a controlled green screen. It does not produce a cut-out subject with a new background behind it, because it has no model of what a person is.

For a broadcast workflow with a real green screen, chroma keying is the right tool and cheap to run. For a consumer camera app that wants to replace the background behind a person in a room, chroma keying does not work at all, because there is no green screen to key against.

The README separates the feature into its own category, 绿幕背景替换, distinct from the face and body work, which is consistent with it being a different kind of operation rather than a nicer version of the same one.

The other two capabilities that sit outside the beauty model are the 2D stickers, of which there are 60 for faces, and the custom watermark. The stickers are decorative overlays rather than analysis, and the watermark takes an image and a position, which is a compositor operation.

So the engine is a pipeline: analyse and reshape the face and body, apply skin and colour work, then composite decorative elements on top. Understanding which stage you are at tells you which options apply.

## Pre-adapted for Chinese audio and video vendors

The README has a section for already adapted audio and video vendors, listing four: 七牛云 (Qiniu Cloud), 声网 (Agora), 腾讯 (Tencent) and 即构 (ZEGO).

That list is the clearest signal of where this SDK is used. These are Chinese real-time audio and video vendors and cloud platforms. Adapting to them means the beauty pipeline runs inside an existing streaming stack rather than in a standalone camera app.

This is a different integration problem from the face reshaping. A beauty engine that processes a camera frame has a straightforward contract: hand it a texture or a buffer, get back a buffer. Inside a streaming SDK, the frame arrives on a vendor-specific callback, may be in a vendor-specific pixel format, may need to be copied into a texture the GPU can sample, and the result has to be pushed back into the vendor's encoder path.

Doing that adaptation once, for four vendors, is most of the value of the section. A team picking this SDK for a Chinese streaming product inherits work that would otherwise be four separate integrations.

The documentation set backs this up. There are separate integration documents for iOS, Android, Flutter and Windows, plus a frequently asked questions page, a release notes file and a document on custom stickers, which is the one extension point the docs describe.

The release history is worth a glance too. The tags are v2.5.05 from 2026-03-24, v2.5.02 from 2026-01-05 and v2.5.01 from 2025-12-26, whose release note mentions optimising the skin smoothing and sharpening effect and comparing it against leading vendors such as Kuaishou. The last push was on 2026-07-21.

## Demos, and the licensing question to settle early

There are demo applications to try, and they are distributed the way mobile demos usually are. The Android demo is a direct download hosted on pgyer with a QR code, and the iOS demo is a TestFlight link.

Neither route involves an install of the SDK, which is deliberate. A beauty engine is something you evaluate visually, and the project has put YouTube clips of each effect in the README for the same reason: a one-click beauty demonstration, a skin beautification demonstration, a face reshaping demonstration, a filter demonstration, a sticker demonstration and a colour grading demonstration, each as a short video.

The performance figure is presented the same way, as an image. There is a screenshot of a performance test with all beauty effects enabled, and the README does not put a number on it in text, so the figure to look at is in res/option.png rather than in the prose.

On licensing, the project is MIT-licensed and the licence file is in the repository root. The README's own wording is also worth reading carefully, since it describes the software as a commercial grade beauty SDK, and a note at the end says that all demo material is sourced from the internet, with a request to contact the listed address if there is an infringement and a promise to remove material immediately.

For a commercial product, the terms of the licence file are what matter, so read it.

## What the SDK does not tell you

The documentation set is organised by platform and by feature, and there are gaps a technical decision depends on.

The README does not describe the input contract. Whether the engine takes a byte buffer, a texture handle or an image object, what pixel formats it accepts, and whether it works on GPU or CPU, are all in the per-platform documents rather than in the overview, and a team evaluating this will spend time in doc_iOS.md, doc_android.md, doc_flutter.md and doc_windows.md to find out.

It also does not state what happens to a frame rate budget when all effects are on. The performance figure is a screenshot, and the README does not say whether the engine drops frames, reduces effect quality, or requires the caller to manage a budget.

The face and body parameter lists are given without a coordinate system or an anchor definition, which is normal for this kind of SDK and a real risk for anyone applying it to a non-standard preview geometry, for example a mirrored front camera.

What the README is clear about is the scope of the effect catalogue and the platforms, and the vendor integrations. Those are the parts a reader can rely on without opening the documentation.

The practical sequence is therefore: pick your platform, read that integration document, try the demo on the actual device, and then check the licence file, in that order.

## Conclusion

PixelFreeEffects suits a team building a camera, live streaming, short video or ID photo application that needs beauty effects with a native feel on each platform, because the effect catalogue is already implemented and the per-platform integration documents cover the four main targets. It is the wrong tool if you need a server-side batch pipeline, since the engine is built for device-side camera and video frames, and it is the wrong choice if green screen compositing is a requirement, because the README states that the keying only removes a green background and is not portrait segmentation. Before you adopt it, read the integration document for your platform, and check the licence file directly.

## FAQ

### What platforms does PixelFreeEffects support?

The README lists iOS above 9.0, Android above 5.0, Windows above 10.0.0, HarmonyOS above 12.0, Flutter 3.3.0 or newer, and Linux as supported. The repository has a separate SMBeautyEngine directory for each target.

### Does PixelFreeEffects do background replacement for people?

No. The green screen background replacement feature only removes a green background, and the README states explicitly that it is background replacement rather than person segmentation.

### What beauty and retouching effects does PixelFreeEffects provide?

Basic beauty covers whitening, skin smoothing, reddening, sharpening, eye brightening, removal of nasolabial folds and dark circles, teeth whitening and AI blemish removal. On top of that there are 50 filters, 60 2D face stickers, 10 full makeup looks, camera colour grading, custom watermarks, and separate face and body reshaping groups.

### How are the body reshaping parameters controlled in PixelFreeEffects?

The body reshaping options are grouped under a PFBodyBeautyType enum, with a default of 0.5 for neutral and a range of 0 to 1, covering slimming, waist, hourglass figure, curves, hip lifting, buttocks, breasts, legs, swan neck, shoulders, arms and legs with left and right variants for the arm and leg pairs.

### How do I integrate PixelFreeEffects into my app?

The README points to per-platform integration documents for iOS, Android, Flutter and Windows under doc/, plus a frequently asked questions page, release notes and a document on custom stickers. Demo apps are available for Android as a direct download and for iOS through TestFlight.

## Sources

- [Issues](https://github.com/uu-code007/PixelFreeEffects/issues)
- [License: MIT](https://github.com/uu-code007/PixelFreeEffects/blob/master/LICENSE)
- [README](https://github.com/uu-code007/PixelFreeEffects/blob/master/README.md)
- [Releases](https://github.com/uu-code007/PixelFreeEffects/releases)
- [uu-code007/PixelFreeEffects on GitHub](https://github.com/uu-code007/PixelFreeEffects)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/uu-code007-pixelfreeeffects
