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.4.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.4-py3-none-any.whl (115.1 kB view details)

Uploaded Python 3

File details

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

File metadata

  • Download URL: toposync_ext_vision-0.1.4.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.4.tar.gz
Algorithm Hash digest
SHA256 25985078e60da1b4cdfc1f1a70ca7477f74db104896b6a6fa59e33d248932716
MD5 db16e205e32369cf1c728a4732542566
BLAKE2b-256 c58a0f9853a5d814e51574c1e5c21f85c4b93509eff0a3b8c375b15f1ea831d9

See more details on using hashes here.

File details

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

File metadata

File hashes

Hashes for toposync_ext_vision-0.1.4-py3-none-any.whl
Algorithm Hash digest
SHA256 7a65ba7e818fd09671bae79c6e4369f36c33a5e451c65e9bfa0e932bf8a602f0
MD5 dbd70a5193fb0954b38cb454aed3a48c
BLAKE2b-256 2eff09ae6ad0724eca063ffdcfc227ca751c99796de56255f7dc7fa4ecc123d3

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