InspireFaceInspireFace1.2.4.d9
Home
Get started
Get and build the SDK
Examples
  • English
  • 简体中文
GitHub
Home
Get started
Get and build the SDK
Examples
  • English
  • 简体中文
GitHub
  • Introduction
  • Get started
  • Features
  • Guides

    • Architecture and lifetime
    • Model packs
    • Image inputs and coordinates
    • Sessions and tracking
    • Face analysis
    • Recognition and FeatureHub
    • Facial landmarks
    • Liveness detection
    • Face capture
    • More API recipes
  • Language and platform

    • C API
    • C++
    • Python
    • Java
    • Windows
    • Android
    • Apple
    • iOS
    • macOS
    • HarmonyOS
  • Get and build the SDK

    • Overview and downloads
    • Source and common options
    • Linux
    • Windows
    • macOS
    • Android
    • iOS
    • HarmonyOS
    • NVIDIA TensorRT
    • Rockchip NPU
    • Python packaging
    • Java packaging
  • Hardware deployment

    • x86 CPU
    • ARM
    • NVIDIA TensorRT
    • Rockchip NPU
    • Python on Rockchip
  • InspireCV
  • Complete examples
  • API coverage
  • Performance
  • Image processing benchmarks
  • Troubleshooting

x86 CPU

Use the CPU SDK with a general model pack such as Pikachu or Megatron on Windows x64, Linux x86_64 and Intel macOS. Image preparation, model inference and feature comparison all contribute to frame time. Keep their costs separate when tuning an application.

PlatformSDK setupBuild from source
Windows x64C/C++ and PythonWindows build
Linux x86_64C API · C++ · PythonLinux build
Intel macOSmacOS integration · PythonmacOS build

Match the library to the process architecture. Apple Silicon running a native arm64 application uses the ARM path; an x86_64 application under Rosetta needs an x86_64 library.

Image processing and preprocessing

InspireCV provides CPU paths for preparing images before inference. Recent source changes expand SSE/AVX2 coverage across Image operations and Task preprocessing. Existing API calls can use the available optimized paths without changes to application code.

StageWork covered by optimized pathsTypical use
GeometryResize, affine sampling, rotation and flipsPreview scaling, camera orientation and face alignment
Pixel operationsChannel conversion, arithmetic, thresholds and blendingPrepare channel order and pixel values
Tensor outputFloat conversion, normalization and layout conversionWrite model inputs into application-owned storage

The available path depends on the operation, pixel type, channel count and CPU. See the Image and Task examples for input formats, transforms and buffer ownership.

Source version

These additions are available in the latest standalone InspireCV source covered here. The current InspireFace dependency has not yet incorporated them. Check the bundled dependency when building an InspireFace SDK; its version number alone does not establish which image-processing paths it includes.

AVX2 build options

For standalone InspireCV, leave INSPIRECV_ENABLE_AVX2 at its default OFF when the library will run on several different CPUs.

SettingBehavior
OFF — defaultKeeps AVX2 kernels separate from the rest of the library. Supported operations can still select them when runtime checks confirm CPU and OS support.
ONCompiles all C++ sources with AVX2 enabled; GCC and Clang also enable FMA. Every target machine must support the instructions used by that build.

OFF does not mean that AVX2 is disabled everywhere. Runtime dispatch was already available; the recent changes extend the operations it covers. Other x86 paths still have their own instruction requirements, including SSE4.1 in Task, so test on the oldest CPU and OS you intend to support. Do not assume a build with ON will run under Rosetta.

The InspireCV build instructions show where to set this option. A prebuilt SDK's compilation options cannot be changed by an application at runtime.

Measure the application workload

  • Reuse the session and buffers. Keep a session for each ordered camera stream, and reuse a Task pipeline and destination storage when the shape stays the same.
  • Enable only the outputs you need. Detection, recognition and optional analysis have separate costs. Measure the same workload when comparing builds.
  • Include the full frame path. Camera conversion, memory copies, queuing and display can add latency beyond the SDK call itself.

The image-processing benchmarks include a runner for measuring public Image and Task calls on your machine. The SDK performance guide measures detection, tracking and feature extraction. Compare the same input, compiler settings and warm-up procedure; image-operation timings alone do not predict the frame rate of a complete application.

Edit this page
Last Updated:: 10/2/26, 8:07 PM
Contributors: Jingyu
Next
ARM