Skip to main content

DetectEngine

ffai_core::engine

Trait DetectEngine 

Source 
pub trait DetectEngine: Send + Sync {
    // Required methods
    fn info(&self) -> EngineInfo;
    fn detect(
        &self,
        image: &ImageBuffer,
        opts: &DetectOptions,
    ) -> Result<DetectOutput>;
    fn class_names(&self) -> &[String];

    // Provided method
    fn detect_batch(
        &self,
        images: &[ImageBuffer],
        opts: &DetectOptions,
    ) -> Result<Vec<DetectOutput>> { ... }
}

Required Methods§

Source

fn info(&self) -> EngineInfo

Source

fn detect( &self, image: &ImageBuffer, opts: &DetectOptions, ) -> Result<DetectOutput>

Source

fn class_names(&self) -> &[String]

Class names for the ids in DetectOutput, in id order. They come from the weight manifest, so they belong to the engine rather than to every output it produces.

Provided Methods§

Source

fn detect_batch( &self, images: &[ImageBuffer], opts: &DetectOptions, ) -> Result<Vec<DetectOutput>>

Detect over many images, using the whole machine.

This is a first-class path, not a convenience wrapper, because it is where a detector’s throughput actually lives. Measured on Diana: running images concurrently is worth 3.6-5.3x over calling Self::detect in a loop, with byte-identical output and no change whatever to the per-image path — because intra-image parallelism is nearly exhausted (24 cores buy one image only 1.42x) while the images themselves are independent.

The trait is Send + Sync, so one loaded model serves every thread. That is the structural advantage over the Python reference: measured on the same machine, PyTorch gets slower under threading (0.68-0.72x) because of the GIL, and its escape hatch — multiprocessing — pays a full model copy per worker.

The default implementation is sequential so existing engines keep working; an engine that can do better should override it.

Dyn Compatibility§

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors§