Direct answer
Orientation errors occur when the pixels sent to a model, the metadata that describes their orientation, and the coordinates used by the application disagree. CameraX ImageAnalysis provides rotation information for captured frames, while imported images may carry EXIF orientation metadata. A preview that appears upright does not prove that the inference input or OCR coordinates use the same transform. Treat source pixels, rotation metadata, crop, resize, model input, detected boxes, UI overlay, and exported image as separate stages, each with an explicit coordinate space. Do not assume every image is physically rotated to match its displayed orientation. The capture path may supply unrotated pixels plus rotation metadata; an import path may rely on EXIF; a preprocessing library may apply one of these and clear or preserve metadata. Record which path is used and what transform was actually applied. A transform applied twice can rotate an image incorrectly, while a transform omitted from coordinate mapping can make recognized text boxes appear displaced even when OCR content is right. Build a synthetic orientation fixture set with clear labels in all corners, asymmetric shapes, portrait and landscape cases, and EXIF orientation variants. Add a CameraX capture fixture for the device rotation values exposed by the selected use case and an imported-file fixture for each EXIF orientation the app chooses to support. Compare raw decoded pixels, transformed pixels, model input dimensions, recognition box coordinates, overlay position, crop and export. Keep the expected geometry in a versioned test manifest; do not rely on a human remembering how the preview looked. Use one transform pipeline with documented order, for example decode/obtain planes, apply orientation, crop, resize, construct model input, then map result coordinates back to source or display coordinates. The exact order must match the implementation and task. Rotation and resize are not generally interchangeable when crop coordinates are involved. Store the transform matrix or the minimal operations needed to reproduce it, not only a boolean “rotated” flag. If model output uses normalized coordinates, record which image dimensions those values reference. Validate export separately. A displayed overlay may use transformed view coordinates while the saved original still uses its original pixel matrix and EXIF. Decide whether export writes a corrected image, preserves the original plus metadata, or stores a result overlay; then test the exact bytes and metadata. The project facts describe Cove Photo’s structured visible-text result but do not establish every camera/import orientation path. This guide provides a geometry test method and makes no OCR-accuracy, camera-support, or device-compatibility claim.
Text boxes are rotated after importing a camera photo
A user imports a portrait image that looks upright in the gallery. OCR text is recognized, but result boxes appear sideways and a crop export is rotated differently from the preview. The app supports both CameraX capture and file import.
Decision
Trace pixel and coordinate transforms separately for capture and import, using asymmetric labeled fixtures with known orientation metadata.
Expected outcome
The team locates whether rotation, EXIF handling, crop/resize, coordinate mapping, or export first diverges without changing the model or image-proxy lifetime.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Orientation and rotation fixture set
- Preprocessing and coordinate records
- Recognition, display, and export assertions
A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.
Implementation workflow
- Inventory each image ingress path. Record whether the source is CameraX or imported content, raw dimensions, available rotation metadata, EXIF orientation, decoder behavior, and the app build. Capture and import are separate fixtures even if they show the same photo.
- Create asymmetric orientation fixtures. Use synthetic labels and shapes in all four corners, portrait/landscape rotations, and EXIF variants. Version expected source coordinates and visible orientation; symmetric test images can hide a double rotation.
- Trace transforms and coordinate spaces. Record decoded pixels, orientation operation, crop, resize, model-input shape, model output coordinate convention, inverse mapping, and overlay coordinates. Ensure each stage names its width/height and transform revision.
- Compare display and export outputs. Check preview, OCR boxes, crop, saved image bytes, and EXIF metadata independently. Decide whether export preserves original pixels or writes a corrected orientation, then assert the chosen contract.
- Inject transform regressions. Test missing EXIF, already-rotated pixels, double rotation, crop before/after resize, navigation, and malformed metadata. Change one transform rule at a time and keep recognition correctness separate from geometric alignment.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Camera capture and imported-image paths have separate records for pixel dimensions and orientation metadata.
- The transform order and coordinate spaces are versioned from source pixels through model input, overlay, crop, and export.
- Synthetic asymmetric fixtures detect missing or double rotation and verify OCR-box mapping after crop/resize.
- No inference accuracy, camera compatibility, or device-support claim is inferred from a geometry test.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Preview orientation | What the user sees in the camera/gallery view | Does not alone prove the model received identically oriented pixels. |
| Model-input geometry | Decoded pixels plus explicit orientation/crop/resize transform | Defines the image and coordinate basis used for inference. |
| Export geometry | Saved pixel matrix, overlay mapping, and EXIF policy | Must be tested independently because display transforms may not alter saved bytes. |
Failure patterns to prevent
- Assuming portrait pixels mean portrait content
- Rotating preview without rotating inference input
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
- ML Kit text recognition
- Android CameraX image analysis rotation and output
- AndroidX ExifInterface API reference
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.
Frequently asked questions
If the preview looks upright, is the model input upright too?
Not necessarily. Preview rendering can apply a transform while the analyzer receives raw pixels plus rotation metadata. Inspect and test the exact inference input.
Should EXIF be applied before or after resizing?
Use one documented transform order matching the pipeline, then test crop and coordinate mapping. Rotation, crop, and resize can change the coordinate basis and are not interchangeable.
Does correct OCR text prove the bounding boxes are correct?
No. Text recognition and geometric mapping are separate outputs. Use asymmetric fixtures with known boxes and validate display and export coordinates independently.