UniFace's fifteen tasks come with MIT code and weights that are not MIT

Fifteen tasks, fifteen notebooks, and not the same fifteen

The task table has fifteen rows and the examples folder has fifteen numbered notebooks, which reads like a clean one to one mapping and is not quite. The notebooks cover detection, alignment, verification, search, the analyzer, parsing, anonymization, gaze, segmentation, the vector store, head pose, recognition, matting, attributes and mesh. So verification and recognition are separate notebooks while the table lists recognition once, and the table's vector store row has no documentation section of its own anywhere in the grouped links. Running the other way, the link list has a face segmentation page that the table folds into the parsing row alongside a segmentation model. Fourteen notebooks are not obviously anti-spoofing, quality, emotion or face states, since the attributes notebook appears to cover that cluster.

One call does three tasks, and attributes wait for a predictor

The quick example is five lines and the API contract is stated right under it. The analyzer class runs detection, alignment and recognition in a single call over an image, and it returns an iterable of face objects. Four fields are always populated: the bounding box, a confidence score, the landmarks, and the embedding vector. Six more stay at nothing until you pass the predictor that fills them: age, sex, race, emotion, a quality score, and the set of face states. That split is the design decision worth noticing. You get the cheap fields for free, and every attribute model is opt-in, so the cost of an attribute you never read is never paid. The example shows the pattern by passing one demographics predictor and then printing two of its fields alongside the embedding's shape.

The library is MIT and the weights are not

The footer carries the licensing position in two sentences and it is worth reading both. The library itself is MIT. Some pretrained weights are not, and the page tells you to check a dedicated attribution document before shipping commercially. That is the correct thing to say and the reason to say it: a fifteen-model zoo assembled from other people's papers cannot be MIT as a whole, and a company that assumes the repository's licence covers the weights is wrong. The install surface is correspondingly simple, with one extra for CPU and Apple Silicon machines, one for a specific vendor's CUDA build, and a pre-release flag for the latest candidate rather than the stable one:

pip install "uniface[cpu]"          # CPU and Apple Silicon
pip install "uniface[gpu]"          # NVIDIA CUDA
pip install --pre "uniface[cpu]"    # latest pre-release

The runtime ceiling only binds on the oldest interpreter

The optional dependency groups are written twice, once for the accelerator package and once for its graphics variant, and in both cases the same pattern appears. On newer interpreters the requirement is a floor only. On interpreters older than 3.11 the requirement gains a ceiling, below a particular runtime version. So on the oldest Python the project still supports, which is also the one the manifest declares as its floor, the runtime is pinned, and on the five newer versions it supports it floats to whatever is current. Two installations of the same library version can therefore resolve different runtimes, and the difference is invisible unless you read the requirement string. It is also the reason to pick an interpreter deliberately rather than letting a resolver choose.

Weights arrive on first use and are verified by checksum

The line that appears twice on the page, once under the task table and once in the footer, says that weights download on first use and are verified by a checksum. Two practical consequences follow. The first call needs the network even on an air-gapped machine, unless you pre-populate the cache, which means the cache directory becomes part of your deployment in a way a wheel-only dependency does not. The second is that the verification is a checksum rather than a signature, so it protects against a corrupted or tampered download but not against a substituted model published under the same digest scheme. For a library whose output feeds identity decisions, that distinction is the one to be explicit about internally.

Model counts per task range from six detectors to one tracker

The table is also a map of how crowded each subfield is. Detection offers six models, from a retina-based one through two single-centre designs to two YOLO variants and a lightweight alternative. Recognition offers five, including two edge-oriented ones. Landmarks offers three configurations with different point counts, two of them dense face meshes at several hundred points with a third dimension. Parsing names a nineteen-class segmentation network plus a masking model. Gaze estimation lists three ResNet depths and a mobile backbone, which is a rare explicit statement of which backbone trades accuracy for speed. Quality names one network with four size variants, and tracking names one tracker whose distinguishing feature is persistent identifiers across frames rather than a choice of models.

A name collision, two instruction files and a documentation toolchain

Two small things in the repository are worth noting for anyone arriving cold. The footer states that the project is not affiliated with an unrelated commercial product of the same name, which is the sort of line that only gets written when a search for the name lands somewhere unexpected. And the root carries two instruction files for coding agents alongside a changelog, a contributing guide and a pre-commit configuration, which says the project expects automated contributions. The documentation is built with a static site generator configured at the root, with its own optional dependency group holding the theme, two extension packs and two plugins, one of which dates revisions from the commit history.

Editorial conclusion

This suits someone who has been maintaining four or five separate face libraries and wants one import path with the model choice exposed rather than hidden. Three things to know first. The library licence and the weight licences are different, and the README tells you to check the attribution page before shipping commercially, which is the line to read if you are building a product on it. Weights download on first use and are verified by checksum, so the first run needs network and the cache becomes part of your deployment. And the runtime ceiling in the install extras is applied only on the oldest supported interpreter, so two installs of the same version resolve differently.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yakhyo/uniface on GitHub