Estimate Depth (HuggingFace)

How it fits

Typical backends

Caveats

• I/O contractExactly one arm is produced, fixed at deploy time by the connected consumer; it is not all three at once. Fan into multiple instances when a graph needs more than one arm.
• Parameter interactionThe backend is chosen by scanning the resolved model: any `.onnx` artefact routes through ONNX runtime, otherwise use_pipeline toggles between the transformers pipeline and the eager transformers network. Adding an `.onnx` file to the repo silently flips the inference path.
• CompatibilityThe selected carrier must match the checkpoint scale: a metric checkpoint pairs with MetricDepthMap (metres, near small, far large) while a relative or inverse-depth checkpoint (the default) emits an unscaled ordinal map. The component does not convert relative depth to metric.
• State lifetimemodel and use_pipeline are hot-swappable at runtime; either change reloads the network in place and reclaims previous GPU memory while processing continues.
• Hard constraintThe ONNX backend prefers a CUDA execution provider and falls back to the CPU provider; if neither is installed it aborts startup rather than degrading.
• FallbackThe pipeline and eager transformers backends silently run on CPU when CUDA is unavailable under device, which is workable for development but slow for production.
• AccuracyThe depth visualisation Image is min-max normalised per frame, so its absolute brightness is not comparable across frames; use a depth-map arm for cross-frame measurements.
• I/O contractDepth is bicubically resized to the input frame size on every backend, so the map and the visualisation always share the source spatial dimensions.
• State lifetimedevice is captured once at startup; switching between CPU and GPU requires a redeploy.