SINet-V2-Camouflage-LiteRT

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 275 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 13.1 ms p50 · output differs from CPU (max rel diff 1.2) (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/sinet-v2-camouflage/CARD.md

SINet-V2 — Camouflaged / concealed object detection (LiteRT GPU)

On-device camouflaged object detection running fully on the LiteRT CompiledModel GPU delegate (no CPU fallback). SINet-V2 (TPAMI 2022) finds objects that blend into their background — hidden animals, concealed items, defect/polyp-style targets — where ordinary segmentation fails.

• Architecture: Res2Net-50 backbone + neighbor-connection decoder + group-reversal attention — pure CNN.
• Weights: GewelsJI/SINet-V2 (COD10K) · Apache-2.0.
• Size: 100 MB.

Input (left) → the concealed subject revealed (right). Photo: Unsplash (free license).

I/O

• Input: [1, 3, 352, 352] NCHW, RGB, ImageNet-normalized (mean [0.485,0.456,0.406], std [0.229,0.224,0.225]).
• Output: [1, 1, 352, 352] sigmoid map — high = camouflaged/concealed object. Resize + threshold/overlay.

GPU conversion

SINet-V2 is a pure CNN (Res2Net + conv decoder). It converts fully GPU-compatible (2447/2447 nodes on the delegate, 1 partition; device corr 0.994) with two patches: ZeroPadMaxPool for the Res2Net stem (-inf PADV2) and align_corners=True → False on the bilinear upsamples. CPU-exact vs PyTorch (corr 0.997).

Minimal usage

Kotlin (Android, LiteRT CompiledModel GPU)

val options = CompiledModel.Options(Accelerator.GPU)
val model = CompiledModel.create(context.assets, "sinet.tflite", options, null)
val inBufs = model.createInputBuffers()
val outBufs = model.createOutputBuffers()

inBufs[0].writeFloat(inputNCHW)          // [1,3,352,352] RGB, ImageNet-norm
model.run(inBufs, outBufs)
val map = outBufs[0].readFloat()         // [352*352] sigmoid; high = concealed object

Python (LiteRT / ai-edge-litert)

import numpy as np
from ai_edge_litert.interpreter import Interpreter

it = Interpreter(model_path="sinet.tflite"); it.allocate_tensors()
inp, out = it.get_input_details(), it.get_output_details()
it.set_tensor(inp[0]["index"], x)        # [1,3,352,352] float32, RGB, ImageNet-norm
it.invoke()
cam = it.get_tensor(out[0]["index"])[0, 0]   # [352,352] camouflage map (0..1)

Conversion

Converted with litert-torch (build_sinet.py): loads the Apache-2.0 SINet-V2 (Res2Net) weights and exports the final camouflage map.

Performance

Measured on a Pixel 8a (Tensor G3, Android 16) with the standard TFLite benchmark_model tool — 10 warm-up runs then 50 timed runs, reported as the tool's mean.

Any on-device figure recorded when this model shipped came from a different runtime. It was taken through LiteRT's own CompiledModel accelerator (logcat reports it as LITERT_CL), which is the path the Kotlin sample app and the LiteRT API use, and it appears elsewhere on this card. The rows above are the classic TFLite OpenCL delegate, measured with a tool anyone can download and re-run. The two are not comparable, so read the rows above as a reproducible floor rather than as this model's speed on LiteRT.

Snapdragon NPU (Hexagon)

This file runs on the Qualcomm Hexagon NPU as published — no conversion and no pre-compiled artifact. LiteRT compiles it on the device and caches the result.

Measured on a physical Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81) with LiteRT CompiledModel 2.2.0 — 5 warm-up runs then 50 timed runs, one accelerator per process, every row taken at device thermal status NONE.

The NPU is 4.0x faster on inference here (3.11 ms against 12.53 ms). The first launch pays once for on-device compilation; every launch after that loads in 135 ms against 1268 ms for the GPU (9.4x), because the GPU rebuilds its shaders each time. The file is fp16 and needs no int8 quantization to reach the NPU.

Running it on the NPU

Put these in jniLibs/arm64-v8a/. None of them are distributed from this repository — the first two come from Google, the rest from Qualcomm's own SDK:

Pick the runtime matching the device's Hexagon version: SM8550 → v73, SM8650 → v75, SM8750 → v79, SM8850 → v81.

val env = Environment.create(
    context,
    mapOf(
        Environment.Option.DispatchLibraryDir to context.applicationInfo.nativeLibraryDir,
        // Required for on-device compilation. Without it the model silently runs on CPU.
        Environment.Option.CompilerPluginLibraryDir to context.applicationInfo.nativeLibraryDir,
    ),
)
val options = CompiledModel.Options(Accelerator.NPU).apply {
    qualcommOptions = CompiledModel.QualcommOptions(
        htpPerformanceMode = CompiledModel.QualcommOptions.HtpPerformanceMode.BURST
    )
}
val model = CompiledModel.create(context.assets, "sinet.tflite", options, env)

Build settings: useLegacyPackaging = true under packaging { jniLibs { … } }, so the DSP can open the skel from a real path, and Kotlin 2.3+ for LiteRT 2.2.0's metadata.

Every NPU failure here is silent. There is no error when the NPU is unavailable — you get a plausible CPU number instead. Confirm from logcat which delegate took the graph: Replacing 1 out of 1 node(s) with delegate (DispatchDelegate) is the NPU, while ... (TfLiteXNNPackDelegate) is the CPU. A missing library is reported only as a W-level dlopen failed line under a generic No compiler plugin found summary.

On the conditions. Thermal headroom is reported as measured, where 1.0 is the throttling threshold. All rows were taken at a comparable headroom and compare directly; figures taken at a different headroom will differ. Each accelerator ran in its own process, because LiteRT's Environment is shared within one and the first model load fixes the options for every later one.

Raspberry Pi 5 (CPU)

Measured on a Raspberry Pi 5 Model B Rev 1.1 (8 GB, Raspberry Pi OS 64-bit) with the LiteRT benchmark_model tool from litert-cli-nightly 0.2.0.dev20260805: CPU inference (XNNPACK, 4 threads), 3 invocations per file of 10 warm-up plus 50 timed runs (the tool caps a phase at 150 s, so very slow graphs run fewer — the Runs column is the actual timed total). The latency is the median across invocations; the spread is the min–max over all timed runs. No thermal throttling occurred during these runs (vcgencmd get_throttled stayed 0x0).

License

Apache-2.0 (SINet-V2 / GewelsJI). Trained on COD10K.