Composed analysis output: one populated field per active intent that produced a result this call. More...
#include <VisionInsight.hpp>
Collaboration diagram for MayaFlux::Kinesis::Vision::VisionAnalysis:Public Attributes | |
| std::shared_ptr< Core::VKImage > | detect_edges |
| std::optional< DetectFeaturesAnalysis > | detect_features |
| std::shared_ptr< Core::VKImage > | estimate_motion |
| std::optional< FindElementsAnalysis > | find_elements |
| std::optional< MeasureAppearanceAnalysis > | measure_appearance |
| std::optional< float > | motion_activity |
| VisionResult::motion_energy from an active EstimateMotion sequence. | |
| std::optional< TrackObjectsAnalysis > | track_objects |
Detailed Description
Composed analysis output: one populated field per active intent that produced a result this call.
find_elements/detect_features are GPU-produced/GPU-reduced result types: see FindElementsAnalysis and DetectFeaturesAnalysis respectively. detect_edges/estimate_motion are exactly VisionResult::images.canny/flow.
find_elements.contours arrives already sorted by area, largest first, when the caller set FindContoursParams::max_contours > 0 on the query: that cap is driven by contour_topk_select.comp, a real GPU top-K-by-area reduction already in the FindContours pipeline, so "the largest contour" is find_elements->contours.front() for a caller who asked for one, with no separate derived field needed.
track_objects/detect_features carry GPU-computed centroid/bounds (see their own struct docs) rather than a bare vector: both are real reduction shader dispatches, not CPU loops.
detect_edges/estimate_motion have no derived field of their own beyond motion_activity: VisionExtractor::sample() answers "what is it like here" for a region a caller supplies, on demand.
Definition at line 176 of file VisionInsight.hpp.
The documentation for this struct was generated from the following file:
