LOST: A Docker-Deployed Framework for Building Semi-Automatic Annotation Pipelines

What LOST actually solves: pipelines, not just a labeling canvas

Most annotation tools give you one interface and one workflow. You upload images, draw boxes, export a file. LOST starts from a different premise: the annotation process itself is the thing you configure. The README describes it as a framework for simple collaborative image annotation that offers out of the box annotation pipelines, and separately allows user defined annotation pipelines where different annotation interfaces, tools and algorithms can be combined in one process. That second sentence is the whole point. If your labeling task is standard bounding boxes over a folder of images, LOST is heavier than you need. If your task involves a model proposing candidates, a human confirming or correcting them, a review stage, and a specific export format, then the pipeline abstraction is the reason to look at it. The target user is a computer vision team with an in-house engineer who can own a Docker deployment, not an individual researcher who wants to label 200 images this afternoon. The README also names a concrete deployment context: PlantVillage at Pennsylvania State University used LOST for a Desert Locust tool, which tells you the intended scale is a distributed team of annotators working against a shared server, not a laptop session.

How the pipeline model and the annotation tools fit together

The material identifies two annotation interfaces by name. The Single Image Annotation Tool (SIA) handles bboxes, polygons, points and lines on one image at a time. The Multi Image Annotation Tool (MIA) handles whole image clusters, which is a different interaction: you are assigning labels to groups rather than drawing geometry. A pipeline combines these with algorithms, and the README states the design goal explicitly: LOST was especially designed to model semi-automatic annotation pipelines, achieved by presenting AI generated annotation proposals to an annotator inside the annotation tool. So the data flow is proposal, then human decision, then export. Supporting pieces sit around that core: colored label trees for organizing labels, a review step for annotations, and personal and project based statistics. Storage is abstracted, with connectivity to external file systems such as AWS S3, MS Azure blobstorage or FTP configured through the user interface rather than through a config file you hand-edit. The README also mentions a scalable design that can distribute intensive computing processes across multiple machines, though it does not say in this material how that distribution is configured, and Jupyter-Lab integration is listed for pipeline development. That last item matters practically: it implies you develop a pipeline in a notebook context before it becomes part of the running system.

Getting LOST running: the quick_setup.py path

The README gives a five-step QuickSetup for the 3.x line and notes the steps were tested for Ubuntu. First, install Docker. Second, clone the repository with git clone https://github.com/l3p-cv/lost.git. Third, install the cryptography package into your Python environment with pip install cryptography. Fourth, run the setup script with a target directory and an explicit release string: python3 quick_setup.py /path/to/install/lost --release 3.1.0. Fifth, follow the instructions the script prints to the command line to start LOST. Two details are worth noting. The release flag is not optional in the example, so you are pinning a version at install time rather than tracking master. And the cryptography dependency is installed into your host Python, not inside the container, which means the setup script is doing orchestration work on the host before Docker takes over. The README does not document environment variables, a docker-compose file, or a reverse proxy configuration in the material provided. If you plan to expose LOST to annotators outside your network, which is the stated collaborative use case, that part of the deployment is not covered here and you should expect to work it out from the full documentation site.

The 4.0.0-alpha release and the documentation gap

The release list shows 4.0.0-alpha dated 2026-08-18, with 3.5.5 and 3.5.4 both landing on 2026-08-04. The README, meanwhile, is titled LOST 3.x QuickSetup and its example pins release 3.1.0. It also states plainly that a lot of new features have been added and improvements made compared to version 1, and that the adaptation of the documentation is currently still in progress. Read those two facts together and you get the main adoption risk: the newest release line is an alpha, and the documentation is acknowledged to lag the code. That is not a reason to avoid the project, but it changes how you evaluate it. You are not choosing between LOST and a tool with a frozen, fully documented API. You are choosing a framework whose 3.x line is the one the README walks you through, and whose 4.x line is explicitly pre-stable. Anyone planning a multi-month annotation campaign should decide which line they are on before the first image is uploaded, because migrating mid-campaign is a different problem from installing the right version at the start.

Where LOST is the wrong tool

LOST is self-hosted and container-based. The README's own framing is that you can set it up with Docker on your local machine or run it on a web server, and the quick setup assumes a host with Docker and Python available. That is a real operational commitment: someone has to own the server, the storage credentials, the LDAP integration if you use it, and the e-mail notification configuration. For a two-person team labeling a few thousand images, that overhead is larger than the labeling work itself. The second limitation is the pipeline abstraction. Flexibility in the process model means the process has to be designed. The README positions out of the box pipelines as usable without programming knowledge, but custom pipelines are described as user defined and paired with Jupyter-Lab integration for development, which implies code. If nobody on the team wants to write that code, you get the default pipelines and lose the main differentiator. Third, the documentation state is a genuine constraint, not a formality: with the README saying docs adaptation is in progress and the newest release being an alpha, debugging an unusual pipeline failure may mean reading the source. The README does not describe error handling, logging, or what happens when an algorithm step in a pipeline fails mid-run, and that absence is itself information.

How LOST differs from CVAT and Label Studio

The obvious alternatives are CVAT and Label Studio, both of which also run as web applications and both of which support bounding boxes and polygons. The difference is where the extensibility lives. CVAT is built around annotation itself: a mature set of drawing and tracking tools, automatic annotation via models you attach, and a fixed data model of tasks, jobs and projects. Label Studio is built around configurable labeling interfaces, where you write an XML-style config to define the UI, and it covers text, audio and other modalities alongside images. LOST is built around the pipeline as the unit of composition, with named tools (SIA, MIA) as steps and algorithms placed between them. In practice: if you want a better labeling canvas, CVAT is the more direct answer. If you want to define a custom interface for a non-image task, Label Studio's config approach is the more direct answer. If your problem is that annotation is one stage inside a longer process that includes model inference, review and a specific export, and you want that whole sequence to be a versioned, shareable artifact, LOST's model is the one that matches. The README notes that pipeline projects can be imported, exported and shared with colleagues, which is the concrete expression of that difference.

Licence, maintenance and what you are signing up for

LOST is MIT licensed. That is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and permission notice are retained. It does not impose copyleft obligations on your own code, and it does not come with a warranty. This is a description of the licence text, not legal advice; if you are embedding LOST in a product, have your own counsel read the LICENSE file. On maintenance, the repository is not archived and the last push is 2026-09-09, with three releases in the weeks before that, so the project is active. The maintenance cost you should budget for is not the licence, it is the deployment. You are running containers, a database the README does not name in this material, and connections to external storage. Upgrades are version-pinned through the quick_setup script's release flag, which is good for reproducibility but means each upgrade is a deliberate action rather than an automatic pull. The README lists LDAP integration and e-mail notifications as features, both of which are the kind of thing that needs configuring and testing against your own directory and mail server before annotators depend on them. None of that is unusual for self-hosted software. It is simply the part of the cost that does not appear in a feature list.

Editorial conclusion

Adopt LOST if you need to define your own annotation process rather than accept a fixed labeling UI, and you are willing to run Docker and maintain a server. Do not adopt it if a single-file CVAT or Label Studio deployment already covers your labeling needs, or if you need a documented, stable 4.x API today, since 4.0.0-alpha shipped in August 2026 while the README still points at the 3.x QuickSetup. Verify three things before committing: that quick_setup.py with your target release string completes on your OS, that your storage backend (S3, Azure Blob, FTP) works from the UI, and that the pipeline features you depend on are described in the current docs rather than only in the code.

Official sources

1. l3p-cv/lost on GitHub
2. License: MIT
3. Project website
4. README
5. Releases