Direct answer
Image preprocessing can create several simultaneous representations of one photo: encoded source, decoded bitmap or camera planes, resized working image, color-converted buffer, model tensor, preview copy, and result/history thumbnail. A useful memory test maps when each representation is created, who owns it, and when it is released. The project memory fact cautions that input tensors and allocator behavior add to runtime memory; Cove Photo has a structured visible-text result but its fact card does not supply a universal image-memory requirement. Do not infer peak RAM from source file size or model download size. Use a versioned image fixture set and record original dimensions, format, orientation, requested target size, decoded config, crop/resize algorithm, color format, tensor shape, and app build. Exact decoded allocation can differ greatly from compressed file bytes. Android’s Bitmap API exposes allocation byte count, while CameraX analysis can deliver CPU-accessible image buffers with formats and resolutions governed by the configured use case. A requested resolution can differ from actual output. Record observed dimensions and buffer metadata rather than assuming the camera path returned the requested size. Build a phase timeline: source acquired, decode starts, decode completes, resize/color conversion, tensor creation, inference handoff, result display, history save, and cleanup. Measure app/process memory at consistent checkpoints with a named tool. Count live copies and record their owner IDs. A frame-copy leak differs from an intentional tensor held through inference; a preview retained for UI differs from a preprocessing scratch buffer. Ensure cancellation and exceptions release the owners that will not be used again. Closing a camera proxy is not a substitute for releasing a separately owned bitmap or tensor. Test input sizes and failure boundaries without publishing a device threshold. Include a small image, a larger image, rotated orientation, unusual aspect ratio, decode rejection, cancellation during conversion, inference failure, and navigation away. Hold model artifact and task constant while varying one image dimension or preprocessing choice. If memory rises, identify whether it is a decoded bitmap, color copy, tensor, UI state, or native allocation; a profiler graph alone may not identify ownership unless correlated with a lifecycle trace. Report only the exact device/build/task and memory metric. Do not claim minimum RAM, image-size support range, or expected peak from one phone. Keep private photos out of public fixtures and production logs; synthetic images or consented, redacted samples are sufficient. The useful result is an ownership map and measured path showing which copies coexist and where they are released, with an explicit unknown if the native runtime’s internal tensor allocation cannot be observed.
OCR works on thumbnails but memory rises on full-size photos
An Android photo feature decodes an imported image, rotates it, resizes it for inference, and keeps a preview. The team sees memory rise but cannot tell whether it comes from duplicate bitmaps, tensors, UI preview, or native runtime.
Decision
Instrument preprocessing phases and ownership, vary one input dimension at a time, and fix the model task while tracking copies and cleanup.
Expected outcome
The team identifies which app-owned representations overlap and which native allocations remain unobservable, without publishing a RAM threshold.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Source dimensions
- Working dimensions
- Object lifetime trace
A device badge must come from an exact device, OS, artifact, runtime, backend, and workload record, not parameter-count intuition.
Implementation workflow
- Describe source and model-input contracts. Record encoded format, dimensions, orientation, color config, requested resize/crop, actual decoded dimensions, output color format, tensor shape, and fixture ID. Do not use compressed file length as the decoded-memory estimate.
- Draw the copy and ownership graph. List source bytes, camera planes or decoded bitmap, transformed working image, tensor, preview, cached thumbnail, and history representation. Assign one owner and release point to each; distinguish retained UI state from scratch data.
- Measure named preprocessing checkpoints. Capture a consistent app/process metric before decode, after decode, after transform, after tensor handoff, during inference, after result display, and after cleanup. Record tool, units, and any native-memory visibility limitation.
- Inject format and lifecycle failures. Test rotation, unusual aspect ratio, decode failure, cancellation, navigation, model error, and repeated capture. Verify that every owned bitmap and tensor is released on success and failure without double-closing camera-managed buffers.
- Compare controlled image variants. Fix model, runtime, prompt, and device state; change one dimension or preprocessing option at a time. Save all outcomes and classify concurrent copies; do not generalize one trace into support or memory promises.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Compressed source length, decoded allocation, transformed copies, tensor, UI preview, and runtime memory have separate names.
- Each app-owned representation has an owner and release condition tested on success, failure, and cancellation.
- Memory findings cite tool/metric, phase, artifact, device, input dimensions, and preprocessing revision.
- No minimum-RAM, universally supported image size, or compatibility statement is inferred without raw device evidence.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Compressed image size | Source file bytes | Useful for storage/transfer but a poor proxy for decoded pixels. |
| Application preprocessing footprint | Decoded bitmap, copies, preview, and tensor by phase | Identifies overlapping app-owned buffers when paired with lifecycle ownership. |
| Whole-process peak | Profiler/system metric during fixed task | Includes runtime and other allocations; only useful when metric and phase are defined. |
Failure patterns to prevent
- Keeping duplicate bitmaps
- Measuring model memory only
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
Can JPEG size predict memory needed for local OCR?
No. Decoded dimensions, pixel format, resize copies, tensors, previews, and runtime buffers all contribute. Measure the actual preprocessing pipeline and name the metric.
Does closing ImageProxy also release the resized bitmap?
No. CameraX owns the proxy; an app-created bitmap or tensor has a separate owner and cleanup path. Test each representation independently because their release times differ.
Can one large-photo test establish a maximum supported resolution?
No. It records one artifact, preprocessing path, device, and task. A support boundary needs repeated raw evidence for the configurations named and defined failure criteria.