Skip to main content

Toposync first-party extension: task-oriented vision operators.

Project description

Toposync Vision extension

First-party extension focused on public task-oriented vision operators for the Pipelines runtime.

What it provides

  • vision.detect
  • vision.track
  • vision.segment_instances
  • vision.pose_estimate (skeleton only; not launched yet)

The public surface is task-based, not vendor-based. The official first-party runtime is ONNX Runtime, with CPU as the default execution path.

Dependencies

  • The default toposync application bundle includes the first-party ONNX Runtime CPU stack.
  • The GPU-oriented first-party bundles are published separately:
    • toposync-vision-cuda
    • toposync-vision-directml
  • The official extension package now also includes the first-party tracker stack:
    • simple_iou_kalman
    • norfair

Notes

  • vision.detect resolves ModelManifest entries and builds an ONNX Runtime backend automatically when runtime=onnxruntime.
  • By default, the ONNX Runtime backend prefers CPUExecutionProvider. Optional acceleration is opt-in via the toposync-vision-cuda / toposync-vision-directml bundles or TOPOSYNC_VISION_ONNXRUNTIME_PROVIDERS.
  • Manifest files can be loaded from TOPOSYNC_VISION_MANIFESTS_DIR or TOPOSYNC_VISION_MANIFEST_PATHS.
  • Custom manifests imported from the UI are persisted under .toposync-data/vision-manifests/ for the selected processing server.
  • Built-in first-party manifests ship inside the wheel, but their ONNX weights do not. When no checkout-local artifact exists, official model ids resolve to TOPOSYNC_DATA_DIR/vision-models/... (or .toposync-data/vision-models/... by default).
  • The extension now ships a built-in RTMDet detection shortlist in extensions/vision/manifests/:
    • rtmdet_det_tiny
    • rtmdet_det_small
    • rtmdet_det_medium
  • The extension now also ships a built-in RF-DETR detection shortlist in extensions/vision/manifests/:
    • rfdetr_det_nano
    • rfdetr_det_small
    • rfdetr_det_medium
  • In a source checkout, existing local artifacts under extensions/vision/models/... are still honored.
  • In installed environments, official artifacts belong under the managed model store in TOPOSYNC_DATA_DIR/vision-models/... and are intentionally not bundled in the published package.
  • The validated manual provisioning flow is documented in docs/VISION_MODEL_PROVISIONING.md.
  • The initial assisted-provisioning foundation for RTMDet detection is already exposed in catalog metadata:
    • upstream checkpoint/config/metafile/paper links
    • planned local builder backend
    • planned supported platforms
    • explicit-consent requirement
  • The UI can also trigger installation for models that have an admin-configured source. Supported source env vars are:
    • TOPOSYNC_VISION_MODEL_SOURCE_<MODEL_ID>
    • TOPOSYNC_VISION_MODEL_URL_<MODEL_ID>
    • TOPOSYNC_VISION_MODEL_PATH_<MODEL_ID>
    • TOPOSYNC_VISION_OFFICIAL_MODEL_SOURCE_DIR
    • TOPOSYNC_VISION_OFFICIAL_MODEL_BASE_URL
  • RTMDet detection now also has an experimental assisted local build path:
    • Linux only in this phase
    • requires a local container runtime (docker or podman) on the processing server
    • still downloads the upstream checkpoint directly on that machine
    • still validates the exported end2end.onnx against the manifest checksum
    • now records provenance per job, including actor, accepted upstream sources, builder metadata, and final ONNX sha256
    • still keeps manual upload as the stable fallback path
    • can be started from the model recovery card or the Processing Servers screen
  • RF-DETR detection now also has an experimental assisted local build path:
    • supports linux, darwin, and windows hosts in this phase
    • uses a host Python builder (rfdetr[onnx]) instead of MMDeploy
    • downloads the upstream checkpoint directly on that machine before exporting the ONNX locally
    • keeps manual ONNX upload available as the stable fallback path
    • is prioritized in the operator UI when nothing is installed and the local builder is actually available on that machine
  • Remote download sources are only enabled when the manifest explicitly allows redistribution. The current built-in RTMDet/RTMDet-Ins manifests do not, so the safe first-party flow is local admin-managed copy.
  • Product policy: RTMDet and RTMDet-Ins stay on guided_upload for now. RF-DETR is available only through assisted local build in this phase; it is not mirrored, bundled, or redistributed by TopoSync.
  • Product policy: Ultralytics/YOLO is not part of the official first-party vision runtime path.
  • The extension now also ships a built-in RTMDet-Ins segmentation shortlist:
    • rtmdet_ins_tiny
    • rtmdet_ins_small
    • rtmdet_ins_medium
  • RTMDet manifests use the dedicated mmdet_rtmdet parser, letterbox preprocessing, and COCO-80 labels.
  • RF-DETR manifests use the dedicated rfdetr_detr parser and the official DETR-style dets + labels ONNX outputs.
  • RTMDet-Ins manifests use the dedicated mmdet_rtmdet_ins parser and produce real binary mask artifacts.
  • The processing server status now exposes:
    • heuristic hardware recommendations
    • runtime upgrade suggestions for CUDA / DirectML bundles
    • a per-task model catalog with availability (available, manifest_only, incompatible)
    • installation capability and progress for models that can be fetched/copied automatically
    • badges such as recommended, fastest, best_quality, edge
  • vision.detect can either filter the stream to packets that contain detections (emit_mode="events") or keep every frame annotated (emit_mode="annotate").
  • vision.track is now first-party and detector-agnostic: it consumes payload["vision"]["detections"].
  • Every TrackedObject now carries camera_id, and can optionally carry world_anchor plus appearance_embedding_artifact_name for future multi-camera association work.
  • vision.segment_instances writes payload["vision"]["segmentations"], attaches mask artifacts when enabled, and exposes the top mask as the semantic image key mask.
  • vision.pose_estimate already reserves the public operator id, config schema, packet contract, and task=pose registry path so future pose models can land without breaking the architecture.
  • Tracking contracts already carry optional keypoints, so future pose-aware trackers do not require a structural rewrite.
  • ModelManifest now also accepts optional capabilities such as reid, so future re-identification models can be cataloged without changing the registry shape.
  • The pipeline editor now chooses models by task, not framework/vendor id. Basic setup is guided for common users, while advanced details expose runtime/model internals and custom manifest import when needed.
  • The first-party tracking backends are:
    • simple_iou_kalman
    • norfair
  • vision.track supports:
    • emit_mode="events" for split-stream lifecycle packets per object
    • emit_mode="annotate" for frame passthrough with payload["vision"]["tracks"]
  • vision.detect keeps per-object lifecycle semantics out of scope; use vision.track when you need temporal identity instead of simple frame filtering.
  • Crop by bbox remains in com.toposync.cameras as camera.object_crop; it is not instance segmentation.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

toposync_ext_vision-0.1.3.tar.gz (80.5 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

toposync_ext_vision-0.1.3-py3-none-any.whl (115.2 kB view details)

Uploaded Python 3

File details

Details for the file toposync_ext_vision-0.1.3.tar.gz.

File metadata

  • Download URL: toposync_ext_vision-0.1.3.tar.gz
  • Upload date:
  • Size: 80.5 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.7.9

File hashes

Hashes for toposync_ext_vision-0.1.3.tar.gz
Algorithm Hash digest
SHA256 3147f49ba60d1647b2639d9f75c44938ae6fc141eef655887edf290bdafe36df
MD5 43eb864bcbee54425e272b563672bb3f
BLAKE2b-256 524f0e70404fe968659e5bee93482e3a52ffc9a4d2a3390eceb303d5eb8b0885

See more details on using hashes here.

File details

Details for the file toposync_ext_vision-0.1.3-py3-none-any.whl.

File metadata

File hashes

Hashes for toposync_ext_vision-0.1.3-py3-none-any.whl
Algorithm Hash digest
SHA256 9ade57afd65fd529261193250182a7a8c3da50473e2e7dacac85683e9a7cb7aa
MD5 d04c22466b00bf03f3d79212a51f64a0
BLAKE2b-256 1f7fca6f8a2c8ab69bc817c0c75c87e94a10330f371e6d9eae6c0619e59afe46

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page