v3.5.5 — builds on aarch64 and OpenCV 5, toolchain found where it is installed

v3.5.5 — builds on aarch64 and OpenCV 5, toolchain found where it is installed

No API or model changes. Supersedes v3.5.3, and v3.5.4 (tagged minutes earlier; its Dockerfiles missed the new cmake/ directory, so it has no images).

What changed

• Native builds on aarch64 (Jetson, GB10 / DGX Spark, Grace). The repository vendors x86-64 copies of PDFium and the PDF renderer; a build on another architecture linked the first and then reported the second as "not found". CMake now reads the ELF header of the vendored PDFium and fetches the pinned bblanchon/pdfium-binaries release for the target when it does not match (SHA-256 verified), and builds the renderer, fastpdf2png 2.0.10, as a subproject with the same toolchain. The server looks for the renderer next to its own executable first, and a binary for another CPU is rejected with its architecture named. The install scripts check the ELF architecture of what is installed and never keep a mismatch.
• CUDA and TensorRT are found where distributions put them. nvcc on PATH, else CUDAToolkit_ROOT, CUDA_HOME, CUDA_PATH, /usr/local/cuda, the newest /usr/local/cuda-<version>, /opt/cuda; TensorRT as a tarball root, the installer's /usr/local/tensorrt, or the distribution packages. TENSORRT_DIR became an optional hint. A plain cmake -B build works on a GB10 with the Debian TensorRT packages.
• OpenCV 5 compiles. OpenCV 5 moved the contour and transform helpers into its geometry module; the build links it when present and keeps working with OpenCV 4.
• A CUDA-enabled ONNX Runtime on aarch64 is the one thing you still build yourself (Microsoft publishes it for x86-64 only). The configure step prints the exact commands; docs/build/native.md has the section.
• CPU server: idle-memory reaper. The CPU server now runs the same reaper as the GPU server, so a long-running CPU deployment returns freed request memory on glibc and jemalloc alike.
• Logs. nvJPEG decoder messages are structured JSON through the rate-limited logger; a batch the batched API refuses is one line per interval, not one per batch.
• fastpdf2png 2.0.10 (the PDF renderer): builds as a subproject, honours PDFium_DIR, continues after short writes, forked workers exit safely and a failed fork() falls back to in-process rendering. Rendered pages are byte-identical to 2.0.0 on x86-64, aarch64 and macOS.
• CI builds and tests on GitHub's arm64 runners as well.

Verified

aarch64 (Ubuntu 24.04, OpenCV 4.6)	configure fetches the arm64 SDK, server and renderer build, unit tests pass, PDF results identical to x86-64 line for line
x86-64 (RTX 5090, OpenCV 4.10 and 5.0)	376 unit tests, FUNSD F1 85.40%, response shapes of every endpoint identical to v3.5.2, ten fixture PDF results byte-identical
renderer old vs new	byte-identical pages on 7 PDFs × 1 and 4 workers (x86-64 and macOS), same daemon replies, fork-blocked run still renders every page
/ocr/pdf latency (80-page scan / 40 × 23 MP pages)	0.78 s / 1.84 s, unchanged

Upgrade notes

• -DTENSORRT_DIR is no longer needed; it still works as a hint.
• Source builds produce build/fastpdf2png and build/libpdfium.so next to the server; the committed x86-64 copies in bin/ remain as the fallback on x86-64 only.
• TURBO_BUILD_FASTPDF2PNG=OFF skips the renderer build (the Docker images do this and use the script route).

Images

• GPU (TensorRT, x86_64): ghcr.io/aiptimizer/turboocr:v3.5.5 (also :latest)
• CPU (ONNX Runtime, amd64+arm64): ghcr.io/aiptimizer/turboocr-cpu:v3.5.5 (also :latest, and ghcr.io/aiptimizer/turboocr:v3.5.5-cpu)

Models are unchanged from v3.5.0.