litert-community/EDSR-x4-LiteRT

Model

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 1016 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 31.7 ms p50 · output matches CPU (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/edsr-x4/CARD.md

1

10 commits

3 linked in READMEs

updated Sep 8, 2026

See the code

README

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 1016 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 31.7 ms p50 · output matches CPU (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/edsr-x4/CARD.md

EDSR (×4) — Super-resolution (LiteRT GPU)

On-device ×4 single-image super-resolution running fully on the LiteRT CompiledModel GPU delegate (no CPU fallback). EDSR (CVPR 2017 winner) upscales a low-res image 4× with sharp detail. The first super-resolution model in the litert-community zoo. ~23 ms/frame on a Pixel 8a.

  • Architecture: EDSR-baseline (16 residual blocks, no BatchNorm) + sub-pixel upsampler — pure CNN.
  • Weights: eugenesiow/edsr-base (super-image, DIV2K) · Apache-2.0.
  • Size: 7.7 MB.

EDSR ×4 super-resolution

Left: bicubic ×4. Right: EDSR ×4 (sharper fur / whiskers / eyes). Photo: Unsplash (free license).

I/O

  • Input: [1, 3, 128, 128] NCHW, RGB, x/255 (0–1).
  • Output: [1, 3, 512, 512] NCHW, RGB in 0–1 — clamp and ×255.

GPU conversion

EDSR is a pure CNN, but its PixelShuffle sub-pixel upsampler lowers to rank-5/6 reshapes that the Mali delegate rejects (the classic super-resolution wall). The fix (exact): PixelShuffle(r) ≡ a fixed-weight grouped-identity ConvTranspose2d(stride=r), which is then converted with ZeroStuffConvT2d (nearest-upsample + stride zero-stuff mask + flipped conv). Result: 68/68 nodes on the delegate, 1 partition; device corr 0.999946, ~23 ms. CPU-exact vs PyTorch (corr 1.0).

Minimal usage

Kotlin (Android, LiteRT CompiledModel GPU)

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

inBufs[0].writeFloat(lrNCHW)             // [1,3,128,128] RGB, x/255
model.run(inBufs, outBufs)
val sr = outBufs[0].readFloat()          // [3*512*512] RGB 0..1 (clamp, *255) -> HR bitmap

Python (LiteRT / ai-edge-litert)

import numpy as np
from ai_edge_litert.interpreter import Interpreter

it = Interpreter(model_path="edsr.tflite"); it.allocate_tensors()
inp, out = it.get_input_details(), it.get_output_details()
it.set_tensor(inp[0]["index"], x)        # [1,3,128,128] float32, RGB, x/255
it.invoke()
sr = it.get_tensor(out[0]["index"])[0]   # [3,512,512] 0..1 -> clamp, *255

Conversion

Converted with litert-torch (build_edsr.py): loads the Apache-2.0 EDSR-base weights, rewrites PixelShuffle → ConvTranspose → ZeroStuffConvT2d, and exports the ×4 graph.

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.

RuntimeBackendGraph on GPULatency
LiteRT CompiledModel (LITERT_CL)GPU68 / 68~23 ms
TFLite benchmark_model (TfLiteGpuDelegateV2)GPU (OpenCL)68 / 68103.4 ms
TFLite benchmark_modelCPU (XNNPACK, 4 threads)—1966.8 ms

The two GPU rows are different runtimes, not a contradiction. The LITERT_CL figure is the one recorded when this model shipped, taken through LiteRT's own CompiledModel accelerator — the path the Kotlin sample app and the LiteRT API use. The TfLiteGpuDelegateV2 figure is the classic TFLite OpenCL delegate, measured with a tool anyone can download and re-run. They agree on how much of the graph the GPU takes; they disagree on speed, and the classic delegate is the slower of the two here. Read the TfLiteGpuDelegateV2 row as a reproducible floor, not as this model's speed on LiteRT.

Snapdragon NPU (Hexagon)

The NPU is 2.59x faster than the GPU (12.09 ms against 31.35 ms) and loads 5.62x faster (110 ms against 617 ms).

backendinference (median / min)load
NPU (Hexagon v81)12.09 ms / 11.71 ms110 ms
GPU (Adreno)31.35 ms / 29.78 ms617 ms

Measured on a Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81, Android 16), LiteRT CompiledModel 2.2.0, one accelerator per process, 5 warm-up runs then N=50 timed runs, median reported. Every run held thermal status NONE throughout. Headroom 0.69, where 1.0 is the throttling threshold.

The NPU rows here ran artifacts compiled ahead of time for SM8850 with QAIRT 2.47.0; the GPU rows ran the published files as they are. LiteRT can also compile for the NPU on the device at first load, which is what lets you ship the published file unchanged — that path and the ten runtime libraries it needs are in the NPU recipe, and we did not measure it here. GPU wiring is in the GPU recipe.

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).

FileInference (median)Spread (min–max)RunsPeak memory
edsr.tflite1,015.9 ms1,012.3–1,021.4 ms150766 MB

License

Apache-2.0 (super-image / eugenesiow). EDSR trained on DIV2K.

android
edsr
image-to-image
litert
on-device
real-time
super-resolution
tflite
upscaling

litert-community/EDSR-x4-LiteRT

Model

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 1016 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 31.7 ms p50 · output matches CPU (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/edsr-x4/CARD.md

1

10 commits

3 linked in READMEs

updated Sep 8, 2026

See the code

README

Measured on device (edge-compat): Raspberry Pi 5 · LiteRT 2.2.0.dev20260804 · CPU/XNNPACK, 4 threads · 1016 ms p50 (2026-08-31); browser · Chromium 151 on M4 Max · LiteRT.js 2.5.3 · WebGPU · 31.7 ms p50 · output matches CPU (2026-08-11). Record: https://github.com/john-rocky/edge-compat/blob/main/cards/edsr-x4/CARD.md

EDSR (×4) — Super-resolution (LiteRT GPU)

On-device ×4 single-image super-resolution running fully on the LiteRT CompiledModel GPU delegate (no CPU fallback). EDSR (CVPR 2017 winner) upscales a low-res image 4× with sharp detail. The first super-resolution model in the litert-community zoo. ~23 ms/frame on a Pixel 8a.

  • Architecture: EDSR-baseline (16 residual blocks, no BatchNorm) + sub-pixel upsampler — pure CNN.
  • Weights: eugenesiow/edsr-base (super-image, DIV2K) · Apache-2.0.
  • Size: 7.7 MB.

EDSR ×4 super-resolution

Left: bicubic ×4. Right: EDSR ×4 (sharper fur / whiskers / eyes). Photo: Unsplash (free license).

I/O

  • Input: [1, 3, 128, 128] NCHW, RGB, x/255 (0–1).
  • Output: [1, 3, 512, 512] NCHW, RGB in 0–1 — clamp and ×255.

GPU conversion

EDSR is a pure CNN, but its PixelShuffle sub-pixel upsampler lowers to rank-5/6 reshapes that the Mali delegate rejects (the classic super-resolution wall). The fix (exact): PixelShuffle(r) ≡ a fixed-weight grouped-identity ConvTranspose2d(stride=r), which is then converted with ZeroStuffConvT2d (nearest-upsample + stride zero-stuff mask + flipped conv). Result: 68/68 nodes on the delegate, 1 partition; device corr 0.999946, ~23 ms. CPU-exact vs PyTorch (corr 1.0).

Minimal usage

Kotlin (Android, LiteRT CompiledModel GPU)

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

inBufs[0].writeFloat(lrNCHW)             // [1,3,128,128] RGB, x/255
model.run(inBufs, outBufs)
val sr = outBufs[0].readFloat()          // [3*512*512] RGB 0..1 (clamp, *255) -> HR bitmap

Python (LiteRT / ai-edge-litert)

import numpy as np
from ai_edge_litert.interpreter import Interpreter

it = Interpreter(model_path="edsr.tflite"); it.allocate_tensors()
inp, out = it.get_input_details(), it.get_output_details()
it.set_tensor(inp[0]["index"], x)        # [1,3,128,128] float32, RGB, x/255
it.invoke()
sr = it.get_tensor(out[0]["index"])[0]   # [3,512,512] 0..1 -> clamp, *255

Conversion

Converted with litert-torch (build_edsr.py): loads the Apache-2.0 EDSR-base weights, rewrites PixelShuffle → ConvTranspose → ZeroStuffConvT2d, and exports the ×4 graph.

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.

RuntimeBackendGraph on GPULatency
LiteRT CompiledModel (LITERT_CL)GPU68 / 68~23 ms
TFLite benchmark_model (TfLiteGpuDelegateV2)GPU (OpenCL)68 / 68103.4 ms
TFLite benchmark_modelCPU (XNNPACK, 4 threads)—1966.8 ms

The two GPU rows are different runtimes, not a contradiction. The LITERT_CL figure is the one recorded when this model shipped, taken through LiteRT's own CompiledModel accelerator — the path the Kotlin sample app and the LiteRT API use. The TfLiteGpuDelegateV2 figure is the classic TFLite OpenCL delegate, measured with a tool anyone can download and re-run. They agree on how much of the graph the GPU takes; they disagree on speed, and the classic delegate is the slower of the two here. Read the TfLiteGpuDelegateV2 row as a reproducible floor, not as this model's speed on LiteRT.

Snapdragon NPU (Hexagon)

The NPU is 2.59x faster than the GPU (12.09 ms against 31.35 ms) and loads 5.62x faster (110 ms against 617 ms).

backendinference (median / min)load
NPU (Hexagon v81)12.09 ms / 11.71 ms110 ms
GPU (Adreno)31.35 ms / 29.78 ms617 ms

Measured on a Samsung Galaxy S26 (Snapdragon 8 Elite Gen 5 / SM8850, Hexagon v81, Android 16), LiteRT CompiledModel 2.2.0, one accelerator per process, 5 warm-up runs then N=50 timed runs, median reported. Every run held thermal status NONE throughout. Headroom 0.69, where 1.0 is the throttling threshold.

The NPU rows here ran artifacts compiled ahead of time for SM8850 with QAIRT 2.47.0; the GPU rows ran the published files as they are. LiteRT can also compile for the NPU on the device at first load, which is what lets you ship the published file unchanged — that path and the ten runtime libraries it needs are in the NPU recipe, and we did not measure it here. GPU wiring is in the GPU recipe.

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).

FileInference (median)Spread (min–max)RunsPeak memory
edsr.tflite1,015.9 ms1,012.3–1,021.4 ms150766 MB

License

Apache-2.0 (super-image / eugenesiow). EDSR trained on DIV2K.

android
edsr
image-to-image
litert
on-device
real-time
super-resolution
tflite
upscaling