Built-in YOLO export (detection + instance segmentation)

[wkentaro]

What to build

Provide a built-in YOLO export so users can produce YOLO-format labels (detection and instance segmentation) directly, rather than relying on external converter scripts. YOLO txt is table-stakes interop for the current ecosystem.

Acceptance criteria

• Polygons/rectangles export to YOLO format (normalized coordinates, class index mapping)
• Instance segmentation export is supported where applicable
• Round-trip is documented (what is and isn't preserved)
• An example under examples/ demonstrates the export

Blocked by

None - can start immediately

[wkentaro]

This was generated by AI during implementation.

Picked this up for autonomous implementation but stopped before writing code: the brief is underspecified on one load-bearing decision that needs a maintainer call, so implementing it now would mean guessing at public surface that is hard to change later.

The blocker: what form should the "built-in" export take?

The brief asks for a built-in YOLO export "rather than relying on external converter scripts." But today every format converter in this repo is a standalone script under examples/ (examples/instance_segmentation/labelme2voc.py, labelme2coco.py, examples/bbox_detection/labelme2voc.py). There is exactly one installed console script (labelme), so there is no installed-converter precedent to follow. "Built-in ... rather than external scripts" reads as a deliberate move away from the example-script approach, but the brief doesn't say what to build instead. The options are materially different:

• (a) Another examples/yolo/labelme2yolo.py script (mirrors VOC/COCO). Lowest risk, but this is arguably the "external converter script" pattern the issue wants to replace.
• (b) An installed CLI subcommand (e.g. labelme export yolo ...). Invents a public CLI surface.
• (c) A library API (e.g. labelme.export.to_yolo(...)), demonstrated by an examples/ script. Invents a public Python API.
• (d) A GUI action (Export → YOLO).

This determines the whole shape of the PR and public API that is costly to change after release, so it's your call rather than something I should pick silently.

Secondary decisions that follow from the above (so the next pass can run unattended):

• Detection vs segmentation output: YOLO detection (class cx cy w h, normalized) and YOLO-seg (class x1 y1 x2 y2 ..., normalized polygon) are distinct label formats. One mode with a --format {bbox,polygon} flag, or emit both?
• Class-index source: existing exporters read a labels.txt with a leading __ignore__/_background_ offset; YOLO is 0-based with no such rows. Confirm a plain 0-based labels.txt (one class per line) is the intended source.
• Shape coverage: which shape_types map to a detection box (rectangle, and bbox-of-polygon?) and which to a seg polygon (polygon, plus 4-corner rectangles/oriented_rectangle, and mask via contour)? What to do with circle/line/point.
• Round-trip note (AC Save file correctly with file dialog #3): confirm the expected "what is / isn't preserved" content (group_id/instances, flags, description, mask fidelity).

Demoting ready-for-agent -> ready-for-human. Once you pick (a)-(d) and confirm the secondary points, it can go back to ready-for-agent and an agent can implement it end-to-end.