Home Articles Books Search About
日本語

Diagnosing and Fixing Memory-Related Crashes in an iOS OCR App

KotenOCR is an iOS app that performs OCR on classical Japanese texts using ONNX Runtime. It ships with 6 ONNX models totaling approximately 230MB on disk. After reaching 300 downloads, the crash rate was found to be 6.7% (20 crashes). No crash logs appeared in Xcode Organizer, so a different investigation approach was required. Investigation Approach Four parallel investigation tracks were pursued: Memory and model size analysis Image processing pipeline review ONNX Runtime thread safety audit Camera and UI lifecycle inspection Root Causes The investigation identified four issues, listed here in order of estimated severity. ...

Parallelizing OCR Recognition on iOS with Swift Concurrency for up to 6.7x Speedup

Parallelizing OCR Recognition on iOS with Swift Concurrency for up to 6.7x Speedup

OCR Pipeline Structure An OCR pipeline using ONNX Runtime on iOS generally follows these steps: Text region detection on the full image (Detection) Character recognition for each detected region (Recognition) Reading order estimation and text assembly Detection runs once on the entire image. Recognition, however, runs once per detected region. When the number of regions is large, recognition dominates the total processing time. The Problem with Sequential Processing Running recognition in a simple for loop means processing time scales linearly with the number of regions. ...

Achieving Up to 7.6x Faster Image Delivery by Optimizing Cantaloupe IIIF Server Cache

Achieving Up to 7.6x Faster Image Delivery by Optimizing Cantaloupe IIIF Server Cache

Introduction I run Cantaloupe, an IIIF-compliant image server, in a Docker environment with S3 as the image source. IIIF viewers (such as Mirador and OpenSeadragon) generate dozens to hundreds of simultaneous tile requests every time the user zooms or pans. By reviewing the cache settings and tuning parameters, I was able to speed up tile delivery by up to 7.6x. In this article, I share the methods and results. Environment Server: AWS EC2 (2 vCPU, 7.6GB RAM) Cantaloupe: islandora/cantaloupe:2.0.10 (based on Cantaloupe 5.0.7) Image Source: Amazon S3 (S3Source) Test Image: 25167×12483px TIFF (512×512 tiles) Reverse Proxy: Traefik v3.2 Setup: Docker Compose Problem: Cache Is Disabled by Default After investigating the default settings of the islandora/cantaloupe image, I found the following state: ...

Fixing Custom Marker Lag on Zoom in MapLibre GL JS with GeoJSON Layers

Fixing Custom Marker Lag on Zoom in MapLibre GL JS with GeoJSON Layers

Introduction When placing custom markers on a map with MapLibre GL JS, a common approach is to pass custom DOM elements to maplibregl.Marker. This allows flexible CSS styling, such as round markers with count badges. However, this approach has a problem: markers lag behind the map during zoom and pan operations. The lag becomes particularly noticeable with many markers or on mobile devices, and zooming out can cause coastal markers to appear over the ocean. ...

5x Faster XSLT Processing: Migrating from Saxon-JS to Saxon-HE

TL;DR By switching from npx xslt3 (Saxon-JS) to Java Saxon-HE for TEI XML → HTML transformation, build time dropped from 1m48s to 23s (~5x speedup). Background Kōi Genji Monogatari Text DB is a digital edition of The Tale of Genji with 54 TEI XML files (one per chapter). The build script (Python) invoked npx xslt3 54 times to transform each XML into HTML. python3 scripts/prebuild.py xsl # XSLT for all 54 chapters This was the slowest step in the entire build pipeline. ...