imglab: a browser-based image annotation tool for dlib, Pascal VOC and COCO exports
To speedup and simplify image labeling/ annotation process with multiple supported formats.
At a glance
- What is it?
- imglab is a client-side annotation tool that runs from the browser and exports landmarks and shapes in dlib, Pascal VOC and COCO formats. The README explicitly asks for maintainers, and that staffing question is the main thing to weigh before adopting it.
- Who is it for?
- imglab fits teams that need landmark or bounding-box annotation exported as dlib XML, dlib pts, Pascal VOC or COCO, and that are comfortable running a static browser application without a server. It does not fit anyone who needs segmentation masks, ellipse or curve annotations, or a vendor with a support contract, since the README states the project needs maintainers and lists Tensorflow export as still in plan.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What imglab is for and who ends up using it
imglab targets a narrow, well-defined job: turning a folder of images into labeled data that an object detector or landmark model can consume. The README describes it as "a web based tool to label images for objects that can be used to train dlib or other object detectors." The emphasis on dlib is not incidental. One of the listed features is that dlib users can "easily adjust the order of parts / landmarks / featurepoints," which matters because dlib's XML format encodes landmark positions as an ordered sequence. Reordering parts after the fact is a real workflow need for anyone building a shape predictor, and most general-purpose annotation tools treat landmark ordering as an afterthought.
The audience is therefore small teams and individuals preparing datasets for dlib-style training, plus anyone who needs Pascal VOC or COCO output without standing up a labeling server. The README also carries a first-timers-only badge and a request for maintainers, which tells you the project is positioned as a community effort rather than a product with a support path. That framing is useful context: the feature set is shaped by what contributors needed, not by an enterprise roadmap.
The mechanism: a static browser app with client-side autosave
The README states the tool is platform independent, runs directly from the browser, and has no prerequisites, with minimal CPU and memory requirements. The stated stack is jQuery, Bootstrap, Riot.js and SVG.js. That combination explains the architecture: Riot.js provides the component layer for the labeling UI, SVG.js draws and manipulates annotation shapes in the browser, and Bootstrap handles layout. There is no mention of a backend service, a database, or an account system.
The data flow implied by the README is local. Annotations are autosaved in browser cache, and export writes the project file to disk. The project file is described as small enough to share over email, and it uses the Nimn data format. That is a meaningful design choice: the intermediate representation is a compact serialization, and the four export targets (dlib XML, dlib pts, Pascal VOC, COCO) are conversions from it. Tensorflow export is listed as in plan, not implemented.
Because everything runs in the browser, the practical ceiling is the browser tab. Large image sets, high-resolution images, and long annotation sessions all live in the same memory space as the SVG rendering layer. The README does not state a tested image count or resolution limit, so that boundary is something you would have to find yourself.
Annotation primitives: points, rectangles, polygons, and what is missing
The README lists feature points and shapes (circles, rectangles, polygons) as supported, and states that "other shapes like ellipses, lines, curves will be added in the future if there is demand." That sentence is the clearest statement of scope in the whole document. If your labeling task requires ellipses or freehand curves, imglab does not currently produce them, and the README makes the addition conditional on demand rather than scheduled.
The quality-of-life features are where the tool earns its place. Any annotation shape can be dragged or resized. Any shape or landmark point can be selected and deleted. Landmark points can be reordered by dragging their label up and down rather than by creating them in a particular sequence. Image opacity can be lowered to make annotation shapes and points stand out, and tracking lines plus mouse coordinates are shown for precise placement. Hotkeys cover switching between images, tools, and labeling data.
Two features deserve separate mention. Auto-suggestion is demonstrated in a GIF, and plugins are demonstrated with Face++ (also tagged as faceplusplus and facepp in the repository topics). The README does not document the auto-suggestion algorithm or the plugin API in the text provided, so anyone planning to rely on either should read /docs/guide.md before assuming how they behave.
Getting it running: import, install, and the documented entry points
The README's usage section is short and points outward. It links to /docs/guide.md/#import for importing images and to /docs/guide.md/#offline-installation for local installation. No install commands, package names, or config keys appear in the README text itself, so I cannot give you a verified command line here. What the README does establish is that no prerequisites are required and the tool runs from the browser, which means the fastest path is the homepage at solothought.com/imglab/ rather than a local build.
The documented feature entry points are all anchors in the same guide: /docs/guide.md/#auto-suggestion, /docs/guide.md/#plugins, /docs/guide.md/#different-shapes, /docs/guide.md/#keyboard-shortcuts, and /docs/guide.md/#zooming-inout. A demo video is linked at youtu.be/Y-bJo_ylHTw. The repository also ships a Features Documentation at /docs/features.md. If you are evaluating the tool, those four files (guide.md, features.md, the demo video, and the homepage) are the entire documented surface. Anything not covered there is undocumented, and the README's own note that the legacy version has been removed means older tutorials and blog posts may describe a version that no longer exists.
The maintainer question is the real risk, not the feature list
The README opens with a blockquote: "This project needs maintainers." Later it repeats the ask under a "Looking for inters/contributors" heading and states the only condition for becoming a maintainer is being polite to user feedback. That is an unusually candid signal. It means the project's direction depends on who shows up, and features like Tensorflow export sit in a plan state rather than a backlog with owners.
A second limitation is structural. Because annotations are autosaved in browser cache and exported manually to disk, clearing site data or switching browsers can lose work that was never exported. The README presents autosave as a convenience and export as the durable step, which is accurate, but it puts the burden of remembering to export on the annotator. For a single person labeling a few hundred images, that is fine. For a team of annotators working in parallel, there is no described mechanism for merging project files, resolving conflicts, or tracking who labeled what.
A third limitation is the shape vocabulary already noted: no ellipses, lines, or curves. And there is no mention of segmentation masks anywhere in the material.
How it differs from LabelImg and CVAT
The closest comparison in this space is LabelImg, which is a desktop Python application that writes Pascal VOC XML and YOLO text files. The difference in approach is deployment: LabelImg is installed locally and runs as a native window, while imglab runs in a browser tab with no prerequisites. imglab also exports dlib XML and dlib pts, which LabelImg does not, and it has explicit support for reordering landmark parts. If your target is a dlib shape predictor, that ordering feature is the reason to pick imglab over LabelImg.
CVAT takes the opposite approach entirely: it is a server-based platform with accounts, task assignment, and multi-user review workflows. imglab has none of that. The trade is direct. imglab gives you a single static application with a small project file you can email; CVAT gives you coordination between annotators at the cost of running infrastructure. The README's claim that the project file is small enough to share over mail is the clearest expression of which side of that trade imglab chose.
Licence, maintenance cost, and what to check before adopting
imglab is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code. It says nothing about whether the project will still work with your browser in two years, and the README's maintainer request is the relevant signal there. If you fork it, the MIT terms let you do so, and the README explicitly invites contributors.
The maintenance cost of adopting imglab is mostly the cost of verifying exports. The tool converts from its internal Nimn representation to four target formats, and format converters are where silent errors live: a swapped coordinate pair or a dropped landmark index produces a dataset that trains but trains badly. The README does not describe a validation step for exported files. So the concrete thing to verify first is round-trip fidelity: annotate one image with a known landmark order, export to dlib XML, and parse it with the same loader your training script uses. Repeat for dlib pts, Pascal VOC, and COCO. If all four parse cleanly, the tool is doing its job. If any of them does not, you have found the boundary before it costs you a training run.
Editorial conclusion
imglab fits teams that need landmark or bounding-box annotation exported as dlib XML, dlib pts, Pascal VOC or COCO, and that are comfortable running a static browser application without a server. It does not fit anyone who needs segmentation masks, ellipse or curve annotations, or a vendor with a support contract, since the README states the project needs maintainers and lists Tensorflow export as still in plan. Before committing, load the tool from the homepage, import a sample image set, draw one landmark and one polygon, and export each of the four supported formats to confirm the output matches what your training pipeline parses.
Community notes