LightlyStudio: a local browser app for curating and annotating image datasets

The problem LightlyStudio targets in a multimodal ML workflow

Most teams that train vision models end up with the same loose collection of tools: a folder of images, a JSON or CSV of labels, a script that computes embeddings, a notebook that plots them, and a separate labeling tool. Moving between them means exporting and re-importing, and the state of the dataset lives in whichever file was written last.

LightlyStudio collapses that into one local application. The repository describes it as "The Unified Data Platform for Multimodal ML", and the README's own summary is "Curate, Annotate, and Manage Your Data in LightlyStudio." The intended user is an engineer or annotator working on computer vision data who wants the embedding plot, the image grid, the annotation editor and the evaluation view in one browser window rather than four.

The topics on the repository are computer-vision, curation, image-labeling and mlops, which matches the scope: it is a data preparation and inspection tool, not a training framework. The README links to a tutorial that goes from raw images to a trained YOLO model, but the training itself happens in the external tooling the tutorial points at.

How the local database, embeddings and browser UI fit together

The architecture is a two-stage split. A Python script loads your data into a local database, then a server process serves a browser UI on top of that database. The README states this explicitly: "Load your data into the local database with a Python script, then start the server and explore it in your browser."

The loading step is done through the `lightly_studio` Python package, which exposes `ImageDataset.load_or_create()` and `add_samples_from_coco()`. Embeddings are computed as part of indexing, which is why the README can claim the embedding plot works alongside the image grid. The server side lives in a sibling package, `lightly_studio_serve`, and the frontend in `lightly_studio_view`. The workspace root `pyproject.toml` explains why they are separate: it exists "so that every member resolves against one `uv.lock`", letting `lightly-studio` depend on `lightly-studio-serve` for shared wire models "without the two ever drifting apart."

That is a deliberate coupling decision. The cost is that the workspace pins `uv` exactly, at `required-version = "==0.12.6"`, and pins `antlr4-python3-runtime==4.9.3` because the `lightly_train` plugin's omegaconf and hydra dependencies crash on the 4.13.x line. Anyone relocking this repository outside that exact `uv` version should expect a different lockfile.

Installing LightlyStudio and indexing your first COCO dataset

Installation is a single pip package. The README's "Try it in 60 seconds" section gives two commands that download an example dataset with images, annotations and evaluation results, with no account required.

pip install lightly-studio
lightly-studio quickstart

According to the README, that starts a local browser app. The project states that images and datasets never leave your machine.

To index your own data, the README's COCO example creates a Python file and runs it. The dataset download helper is skipped if the files already exist.

import lightly_studio as ls

dataset_path = ls.utils.download_example_dataset(download_dir="dataset_examples")

dataset = ls.ImageDataset.load_or_create()
dataset.add_samples_from_coco(
    annotations_json=f"{dataset_path}/coco_subset_128_images/instances_train2017.json",
    images_path=f"{dataset_path}/coco_subset_128_images/images",
)

ls.start_gui()

Running `python example_coco.py` starts the UI server on localhost:8001, and the README says to open the printed URL to inspect images with their annotations. It also notes that `host` and `port` parameters can be passed to `start_gui()` to customize the address, and that the app can be reopened later with `lightly-studio gui` instead of re-running the indexing script.

For segmentation instead of object detections, the README says to pass `annotation_type=ls.AnnotationType.SEGMENTATION_MASK` to `add_samples_from_coco()`. Python versions 3.9 to 3.14 are supported on Windows, Linux and macOS, though the README recommends Python 3.10 for plugin compatibility.

Where LightlyStudio stops being the right tool

The local-first design is also the main constraint. The README says images and datasets never leave your machine, which is a privacy win and a collaboration problem. There is no described mechanism for multiple annotators to work on the same dataset concurrently, no role or permission model, and no hosted sync. If your labeling pipeline depends on a shared queue with reviewer roles, this is not that product.

The scale claim needs reading carefully. The README says it "Works smoothly with 2M+ images, embeddings included, on a single MacBook (M1, 16GB RAM)." That is a statement about the reference machine, not a guarantee for your embedding model or image resolution. Embeddings for large datasets are stored in the local database, so the practical ceiling depends on how many vectors you generate and how wide they are. The README does not document a sharding or remote-database mode.

Plugin compatibility is a second sharp edge. The README points to Python 3.10 for plugins such as SAM autolabeling, even though the package itself runs on 3.9 through 3.14. So the version you install depends on whether you need plugins, and that is a decision to make before creating the environment rather than after.

Finally, the scope is images and video. There is a Video Dataset guide in the docs, but nothing in the README suggests text, audio or tabular support. For those, look elsewhere.

How it differs from FiftyOne and other dataset inspection tools

The closest comparison in this space is FiftyOne, which also gives a Python API for loading datasets and a browser app for exploring them with embeddings and label views. The difference in approach is packaging and coupling. FiftyOne is a single Python package with an optional App; LightlyStudio splits the workspace into `lightly_studio`, `lightly_studio_serve` and `lightly_studio_view`, and the root `pyproject.toml` says the split exists so the client and server share wire models through one `uv.lock`.

That means LightlyStudio's frontend and backend are versioned together by construction. The release list shows this in practice: `v1.1.1` and `lightly-studio-serve/v0.1.0` were both tagged on 2026-09-14, with `v1.1.0` a week earlier. If you have ever debugged a mismatch between a Python client and a separately released web UI, this is the trade the maintainers made.

The other difference is the explicit plugin surface. The README has a Plugins section in its workflow table and calls out a `lightly-studio-sam3-plugin` as an example. FiftyOne has its own plugin ecosystem, so this is not unique, but LightlyStudio's documentation ties plugin use to a specific Python version, which is a more prescriptive stance than most tools take.

Neither project is a labeling workforce. If you need managed annotators, both are the wrong layer.

Licence, maintenance and the cost of upgrading

The licence is Apache-2.0, shown by the badge in the README and the LICENSE file at the repository root. Apache-2.0 permits commercial use and modification, and includes an explicit patent grant. It does not give legal advice, and if you redistribute a modified version you should read the notice and attribution clauses yourself.

Maintenance looks current. The last push to the default branch was on 2026-09-15, and the most recent release, v1.1.1, was tagged on 2026-09-14. The repository is not archived.

The upgrade cost is concentrated in the workspace pins. The root `pyproject.toml` pins `uv` at exactly 0.12.6 and explains that uv rewrites parts of `uv.lock` as its serialisation evolves, so two uv versions relocking the same requirements produce different files. The comment states the pin keeps CI and local relocks byte-identical. If you vendor this repository and run a newer uv, expect lockfile churn that is not caused by any dependency change.

The `antlr4-python3-runtime==4.9.3` constraint is the other one to watch. It exists because `moto[server]` pulls antlr unconstrained while the `lightly_train` plugin's omegaconf and hydra require the 4.9 line and crash on import with 4.13.x. Removing that constraint will break plugin imports, not the core package.

Editorial conclusion

Adopt LightlyStudio if your data can stay on one machine and your workflow is image or video curation, labeling or model evaluation, especially if you want the embedding plot and the annotation editor in the same window. Skip it if you need a hosted multi-user labeling service with role-based access, or if your stack is text or tabular. Before committing, verify the SQLite file stays manageable on your own dataset size, confirm your Python version against the 3.9 to 3.14 range, and check which plugin interfaces you need, since the README points to Python 3.10 for plugin compatibility such as SAM autolabeling.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. lightly-ai/lightly-studio on GitHub
3. Project website
4. README
5. Releases