Skip to main content

SFE Toolkit FAQ

For integrators using the SFE Toolkit (face, iris, palm). This page covers SDK-wide questions; for questions specific to a particular use case (face access, video surveillance, etc.), see the use case's own FAQ section. For error symptoms and fixes, see Troubleshooting (coming soon).

Are templates compatible across SDK versions and extractor models?

For which template versions can be matched against each other, see Face template version compatibility (matching) in the Features documentation.

There is no template conversion: sfeFaceTemplateExport / sfeFaceTemplateImport serialise a template to and from bytes, they do not re-extract it into another version.

Practical guidance:

  • Prefer a single extractor tier across the fleet for consistent thresholds and accuracy. Cross-tier matching works within the V2 group, but the averaged-score behaviour means an operating threshold tuned on one tier won't map exactly onto a mixed-tier pairing.
  • Keep source enrollment images so re-enrollment is possible when you move outside a compatible group — e.g. an SDK upgrade that changes the template version group, or a switch to/from Legacy or Server/NIST templates.
Are detection / liveness / template-extraction results reproducible across inference engines?

Reproducibility is governed by the model variant, not the engine itself. Each SFE Toolkit solver ships with a specific model variant:

  • Float32 models (ONNX Runtime on Windows / Linux) — numerically close across execution providers (CPU, CUDA, TensorRT). Small drift from floating-point order and kernel differences, but matching scores, liveness values, and bbox coordinates stay close to the reference.
  • Float16 models (ONNX Runtime on Android, packaged to reduce APK size) — small additional drift versus float32, in the same ballpark.
  • Int8 quantized models (Rockchip RKNN, NXP TFLite VX delegate, Ambarella CVFlow) — quantization is a lossy transformation, so int8 outputs do not match the float32 reference exactly. Drift can be material, especially around operating thresholds.

In practice the model variant is determined by which solver you load, so engine class remains a useful indicator — but the root cause of divergence is the model variant, not the engine.

Practical guidance:

  • Treat the float32 build as the reference baseline for benchmarking and threshold tuning.
  • For fleets that include quantized accelerators, validate end-to-end (FAR / FRR, liveness EER, gallery-match accuracy) on the deployed model variant — do not extrapolate from float32 numbers.
  • The template-compatibility constraint applies on top of model-variant differences: enrolling on one variant and matching on another adds a second source of variance and is only safe if the extractor model is identical on both ends.
Do I need a hardware accelerator, or will pure CPU work?

CPU works on every supported platform — the ONNX Runtime CPU execution provider is the default and runs on Windows, Linux, Android, and embedded Linux targets.

When CPU is enough:

  • Desktop / server-class devices (Windows / Linux / Android) — typical application latency budgets are met by CPU inference for the fast and balanced tiers; accurate is usually fast enough on modern x86.

When an accelerator is required:

  • Embedded platforms (Rockchip, Ambarella, NXP, Jetson) — CPU is generally too slow for real-time inference; the per-frame latency budget for real-time applications requires offloading detection, landmarks, liveness, and template extraction to the NPU (Rockchip / Ambarella / NXP) or GPU (Jetson). Accelerator-specific solver variants ship for these targets — see the Hardware Accelerators table.

Choice driver: target hardware capability + per-frame latency required by your application.

What is the maximum on-device gallery size for reliable 1:N?

The maximum gallery size is bounded by three constraints:

  • License ceiling. Every license carries a maximum gallery size set at generation time. If your gallery exceeds it, the identification call fails. Contact Innovatrics if you need a higher cap configured for your deployment.
  • Device memory. Gallery memory grows linearly with the number of templates; the available memory budget on your target device sets an upper bound below the license ceiling.
  • Per-call latency. On-device 1:N matching scales linearly with the gallery size; the per-recognition latency your application accepts is the third practical bound.
How should the gallery be persisted (file / SQLite / encrypted blob)?

The SDK does not dictate storage — templates are fixed 522-byte binary blobs (SFE_FACE_TEMPLATE_SIZE), and the integrator owns the persistence layer.

Common patterns:

  • Flat file per entity — simplest; one file per SFEEntity UUID, contents are the template bytes. Good for small galleries (up to a few thousand) and append-mostly enrolment.
  • Single SQLite DB indexed by SFEEntity UUID — better for larger galleries; gives you transactional enrolment, easy backup, and an index on the entity ID. The 522-byte template is just a BLOB column.
  • Encrypted blob (e.g. AES-256-GCM, sealed by a device key) — required when biometric privacy regulations (GDPR, BIPA, equivalents) mandate at-rest encryption of biometric data.

Use sfeFaceTemplateExport / sfeFaceTemplateImport (sfe_face.h) for the serialisation step in any of these patterns — they handle the on-disk byte format. Encryption is applied by the application to the serialised bytes before they hit storage.

Can I migrate templates from another vendor's SDK?

No. Innovatrics face templates are a proprietary fixed-size binary format and are not interchangeable with templates from other vendors' face SDKs. There is no template-conversion path.

Re-enrollment from source images is required when migrating an existing gallery in from another vendor. If source images are not available (the prior vendor only retained templates), the gallery must be rebuilt from new enrolment captures.