Release v1.11.0 - Every Format and Side-Car a Release Ships, and a Derived COCO's Identifiers

What a published annotation set needs from the tool, found while preparing Songdo Vision OBB. The conversion is unchanged from v1.10.0: converter.py, evaluator.py, analysis.py, optimizer.py and detector.py are byte-identical, so no measured number moves and every existing results folder and provenance record stays valid.

The viewer reads every format a set ships

A published set usually holds the same boxes more than once: the canonical YOLO files, a DOTA copy beside them, a COCO record at the subset root. The viewer picked one silently and gave a reader no way to tell which, and the copies are not interchangeable, since the derived ones are rounded and carry no confidence.

hbb2obb-view images          # OBB: yolo from labels_obb, also dota, coco

The status bar now names the reading on screen and the one the key would switch to, and t and y advance the oriented and horizontal layers through everything the set holds. Every frame is re-read on a switch, not just the one on screen, so flicking between two readings compares the same boxes throughout. formats_present() lists the readings a directory holds and coco_beside() pairs it with the record one level up, which is the rule --verify already used. The bar is two lines as of this release, the second being the key legend, which no longer fits beside the status.

Two files a release ships that the viewer could not see

Both of these are what hbb2obb itself writes, so they affected any set converted with the flags a release needs.

• The confidence side-car was only read when --show_confidence was given. c toggles the colouring at any time, and a set whose label files stay strictly standard has no score in them to toggle, so the key did nothing. --confidence_dir, defaulting to labels_confidence/ beside the images, is now read either way and costs one directory read.
• read_polygons read the contours as pixels. --normalize writes them relative exactly as it writes the labels, so on a 4K frame every contour collapsed into the top-left pixel and g looked like a broken layer. The whole file decides whether it is relative, as read_yolo does, so one contour running past an edge cannot flip it.

A derived COCO file can keep its source's identifiers

Converting a set produces a fresh numbering, so a release derived from a published COCO record silently renumbered every image and annotation and broke the correspondence with the record it came from.

hbb2obb-convert labels_obb --to coco -f yolo \
  --coco_from /path/to/source/coco_annotations.json \
  --coco_info /path/to/info.json

--coco_from carries the image and annotation ids, licenses and supercategory of the source, refusing unless the frame sets, per-frame box counts and per-row classes all agree. info is never carried in, since it names the record being written, and --coco_info supplies it. Without either flag the numbering is exactly what it always was.

Also

• The two flags above are documented in --help and nowhere else: they are what a derived release needs, not what someone converting their own labels needs.
• The README's key table gains t and y, and says that the side-car confidences and the relative contours are read with no flag.

Full changelog: v1.10.0...v1.11.0