MyVision: Browser-Based Image Annotation With a Bundled COCO-SSD Auto-Labeller

The Labelling Bottleneck MyVision Targets

Annotation is the slow part of a computer vision pipeline. Someone has to open each image, decide what counts as an object, draw a shape around it, and assign a class. MyVision is aimed at that step. The README describes it as a free online image annotation tool used for generating computer vision based ML training data, designed to speed up the labelling process and help maintain workflows with large datasets. The intended user is an engineer or annotator preparing object detection data, not someone training a model inside the tool. There is no training loop here, no metrics, no export to a model checkpoint. The output is labelled data plus a format conversion path. Two shape types are supported: bounding boxes and polygons. The README also shows polygon editing operations for adding, removing and moving individual points, which matters when an object boundary is irregular and a rectangle would include too much background. If your task is classification, keypoints, or semantic segmentation at the pixel level, none of those are described in the material, so treat them as out of scope rather than assumed.

Everything Runs in the Browser, Including the Model

The architecture is a static client application. The README states that no setup is required to run the project: you open the public/index.html file and you are all set. There is no backend described, no database, no upload endpoint. That single decision explains most of the tool's properties. Images stay on the machine because there is nowhere to send them. The README makes this explicit for the auto-annotation path: MyVision uses the popular COCO-SSD model to generate bounding boxes for your images and, by operating locally in your browser, retains all data within the privacy of your computer. The data flow is therefore: load images into the browser, draw or accept suggested boxes and polygons, then export. Import works the same way in reverse. The README notes that you can import existing annotation projects and continue working on them in MyVision, and that the same process can convert datasets from one format to another. That conversion role is easy to overlook. If your team already has labels in one format and a downstream trainer expects another, the import and export pair is the whole feature. The cost of this design is that every image and every annotation lives in browser memory and whatever storage the page uses. The README does not describe autosave, a session limit, or recovery behaviour after a tab crash, so plan around that gap rather than assuming it is handled.

COCO-SSD Suggestions and Their Ceiling

The auto-annotation feature is a pre-trained COCO-SSD model producing bounding boxes. This is a suggestion mechanism, not a labelling authority. COCO-SSD detects the object classes present in the COCO dataset, so anything outside that class list will not be proposed, and a custom class such as a specific machine part or a defect type will need to be drawn by hand. The README frames the feature as a way to skip the hard work of annotating, which is fair for images full of people, cars, and other COCO categories, and much less true for domain-specific imagery. Two practical consequences follow. First, review time does not disappear; it shifts from drawing to correcting, and correcting a wrong box can cost as much as drawing a right one. Second, the model runs in the browser, so the first load includes model weights. The README does not state whether those weights are vendored in the repository or fetched at runtime, and that distinction decides whether the tool works on an air-gapped machine. Check it before you plan an offline deployment. The upside is real: for a dataset that overlaps COCO categories, pre-filled boxes turn a per-object drawing task into a per-object accept-or-reject task.

Running It Locally and Building From Source

There are two paths, and they serve different people. For annotators, the README says to open public/index.html directly. No install, no server. For anyone changing the code, the repository gives a Node workflow. Requirements are Node version 10+ and NPM version 6+, stated in the README. The commands are npm install for dependencies, npm run watch to run the project in watch mode, and the README adds that all changes should be made in the src directory and observed in publicDev. That last line is the one to remember. The source you edit lives in src, the served development output lives in publicDev, and the shipped static entry point lives in public/index.html. Three directories, three roles. If you edit files in public and then run the watch task, you are editing the wrong tree. The README does not document a production build script, so the relationship between the src build output and the committed public directory is not spelled out in the supplied material. Verify that before you fork. Also note the version floors: Node 10 and NPM 6 are old baselines, and a modern toolchain may or may not build the project without changes. That is a guess about compatibility, not a documented fact, so test it rather than trusting it.

Format Support and the Conversion Use Case

The README lists supported dataset formats as a table image, table3.png, rather than as text. This review cannot enumerate the formats from the supplied material, and that is itself a finding: the one piece of information a prospective adopter most needs is locked inside a screenshot. The topics list on the repository points at COCO, VGG and YOLO, which suggests the broad families involved, but topic tags are not a format guarantee. If format coverage decides your adoption, open the image and read the table before anything else. What the README does confirm is that import and export together act as a converter. Import an existing project, export it in a different format. For a team whose labels are trapped in a legacy format, that is a migration tool with no server component and no upload step. The constraint is fidelity. A converter can only carry the information the target format can express. Polygons do not survive a round trip into a format that only stores rectangles, and class taxonomies do not survive a format that stores integer class indices unless the mapping is preserved. The README does not discuss round-trip fidelity or lossy conversions, so test a sample of your real data in both directions before trusting it with a full dataset.

Where MyVision Is the Wrong Tool

The clearest limitation is release cadence. The repository's only listed release is 1.0.0, published on 2020-09-15. The last push timestamp is recent, so the repository is not archived and work may be ongoing, but a published release history with a single entry from 2020 tells you the project has not been versioned for downstream consumers in years. If your organization needs pinned releases, changelogs, or a security response process, that is a mismatch. The second limitation is the absence of any collaboration or review layer. There is no server, so there is no shared queue, no annotator assignment, no inter-annotator agreement check, and no audit trail. For a two-person project that is fine. For a labelling team of twenty, the lack of a backend is a structural problem, not a missing feature. The third is the GPL-3.0 licence. If you fork MyVision, modify it, and distribute it, copyleft obligations attach to the distributed work. Running it internally as a tool is a different situation from shipping it inside a product, and the two are easy to confuse. That is a licensing question for your counsel, not something this review can settle. Finally, the auto-labeller is a bounding box generator only. If your labels need masks, expect to draw polygons by hand.

How It Compares With Label Studio

Label Studio is the obvious alternative for teams that outgrow a static page. The difference is architectural, not cosmetic. Label Studio is a server application: you deploy a backend, annotators connect to it, and projects, tasks and completions live in a database. That gives you multi-user assignment, review and agreement metrics, and a persistent record of who labelled what. MyVision has none of that because it has no server at all. The trade runs the other way too. A server means deployment, authentication, storage, and a machine that holds your images. MyVision's README can claim that operating locally in your browser retains all data within the privacy of your computer precisely because there is no backend to leak from. If your images cannot leave the workstation, that is a decisive difference in MyVision's favour, and no amount of Label Studio configuration changes it. The practical split: single annotator or a small trusted group with sensitive images, MyVision. A labelling operation with roles, review stages and a need for audit, Label Studio. If you are unsure, the deciding question is whether anyone other than the person who drew a box needs to approve it. If yes, you want a server.

Maintenance, Licensing and What to Check First

Maintenance cost here is low in the way that static tools are low: there is nothing to operate. No database to back up, no service to patch, no uptime to monitor. The cost moves to the edges. You are responsible for the browser, for where annotated data is stored between sessions, and for the export step. The README does not describe autosave or persistence, so treat browser state as volatile until you confirm otherwise. Upgrades are the other edge. With a single published release from 2020, there is no upgrade path to reason about; you either track the master branch or pin a commit. Pinning a commit is the safer default for a tool that touches training data. On licensing, MyVision is GPL-3.0. The practical implication is that distributing a modified version carries copyleft obligations for the distributed work, while internal use is a different analysis. Whether your specific deployment counts as distribution, and what that means for a tool embedded in a commercial pipeline, is a question for a lawyer. What you can do without one is check the repository layout: confirm that public/index.html exists as the README claims, confirm that publicDev is generated by npm run watch, and read table3.png to see whether your formats are listed. Those three checks take minutes and settle most adoption questions.

Editorial conclusion

Adopt MyVision if you need a zero-install browser annotator for bounding boxes and polygons and you want COCO-SSD suggestions without uploading images anywhere; the README states no setup is required beyond opening public/index.html. Do not adopt it if you need instance segmentation masks, a server-side review workflow, or a project with a recent release history, since 1.0.0 dates to September 2020. Before committing, verify three things in the repository itself: which formats the table3.png support matrix actually lists, whether the COCO-SSD model files are vendored in the repo or fetched at runtime, and whether the public and publicDev directories are both present in the checkout.

Official sources

1. License: GPL-3.0
2. OvidijusParsiunas/myvision on GitHub
3. Project website
4. README
5. Releases