react-native-image-stitcher 0.15.1 → 0.15.2

package/CHANGELOG.md

@@ -16,6 +16,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.15.2] — 2026-06-11
+
+### Fixed
+
+- **Sharp non-AR camera preview (WYSIWYG follow-up).**  The v0.15.1
+  letterbox pinned the vision-camera format by aspect ratio only, so
+  `useCameraFormat` could settle on a degenerate 4:3 format — observed as
+  a 192×144 video stream on the iPhone 16 Pro — rendering the preview as
+  upscaled mush behind a full-resolution capture.  The format filter now
+  also requests `{ videoResolution: 'max' }`, so among 4:3 formats the
+  highest-resolution one is chosen: a sharp preview plus full-res frames
+  into the non-AR stitcher, with aspect kept as the top-priority filter so
+  4:3 capture parity holds.  A bounded target (e.g. 1920×1440) is
+  deliberately avoided — the nearest such format on the iPhone 16 Pro is
+  10-bit-only (`x420`/`x422`), which the frame processor's 8-bit
+  `420v`/`420f` pipeline rejects with `device/pixel-format-not-supported`;
+  vision-camera exposes no per-format pixel formats to JS, so `'max'`
+  (empirically the device's 8-bit full-res format) is the robust choice.
+  Tap-to-photo stills are capped at ~12 MP (`photoResolution: 4032×3024`,
+  lowest priority) so the iPhone 16 Pro's max-video format doesn't default
+  to a 24 MP still — the panorama path uses the video stream, not
+  `takePhoto`, so the cap costs nothing there.
+
 ## [0.15.1] — 2026-06-08
 
 ### Fixed

package/dist/camera/CameraView.js

@@ -102,9 +102,47 @@ exports.CameraView = (0, react_1.forwardRef)(function CameraView({ device, flash
     // aspect on essentially every phone camera (incl. ultra-wide), so a
     // matching format is virtually always available; `useCameraFormat`
     // returns the closest match and never throws.
+    //
+    // Resolution preference matters too: filtering on aspect ALONE lets
+    // vision-camera settle on whatever 4:3 format sorts first — observed as
+    // a 192×144 VIDEO stream on the iPhone 16 Pro (the photo still uses the
+    // format's full-res photo dims, so you'd get a sharp capture behind a
+    // mush preview).  So we also request the highest video resolution.
+    //
+    // Why `'max'` and not a bounded target like 1920×1440?  We tried the
+    // bounded target and it FAILED on the iPhone 16 Pro: the nearest
+    // 1920×1440 format is a 10-bit format (pixel formats x420 / x422 only —
+    // and it is NOT flagged HDR, so the `videoHdr` filter can't dodge it).
+    // The frame processor + the stitcher's CV pipeline need 8-bit
+    // `420v`/`420f`, so vision-camera raises
+    // `device/pixel-format-not-supported` and silently falls back to a
+    // default pixel format — breaking non-AR stitching.  vision-camera does
+    // NOT expose a format's supported pixel formats to JS (no
+    // `pixelFormats` field; `FormatFilter` has no pixel-format key), so we
+    // can't select an 8-bit format by inspection.  Empirically the device's
+    // MAX 4:3 video format is 8-bit (420v/420f) on the iPhone 16 Pro, and
+    // Android formats are near-universally 8-bit YUV_420_888, so `'max'` is
+    // the robust choice: a sharp preview on a frame-processor-compatible
+    // pipeline.  Trade-off: the max format tends to run at 30 fps (fine for
+    // hold-to-pan) and feeds full-res frames to the non-AR gate — if that
+    // ever shows up as dropped frames we can downscale for the gate
+    // natively while keeping full-res keyframes.  Aspect stays the
+    // top-priority filter, so 4:3 WYSIWYG parity holds on every device.
+    //
+    // Still resolution is capped at ~12 MP.  The max-video 4:3 format pairs
+    // with a 24 MP photo (5712×4284) on the iPhone 16 Pro by default — 2×
+    // the file size + per-capture memory for no benefit on the panorama
+    // path (which uses the VIDEO stream, not takePhoto).  `photoResolution`
+    // is the LOWEST-priority filter, so it only breaks ties between equal
+    // max-video formats (e.g. the 12 MP-photo vs 24 MP-photo variants that
+    // share the same 4032×3024 video) — it never trades preview/stitch
+    // sharpness for a smaller still.  4032×3024 = 12 MP at 4:3; nearest-
+    // match keeps stills near there on any device.
     const format = (0, react_native_vision_camera_1.useCameraFormat)(device ?? undefined, [
         { photoAspectRatio: 4 / 3 },
         { videoAspectRatio: 4 / 3 },
+        { videoResolution: 'max' },
+        { photoResolution: { width: 4032, height: 3024 } },
     ]);
     // Measured size of our container, so we can size the <Camera> view to
     // the largest box of the capture's aspect ratio that fits inside it

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "react-native-image-stitcher",
-  "version": "0.15.1",
+  "version": "0.15.2",
   "description": "Pose-aware panorama capture + stitching for React Native. One <Camera> component, both tap-to-photo and hold-to-pan modes, both AR-backed and IMU-fallback capture paths.",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/camera/CameraView.tsx

@@ -163,9 +163,47 @@ export const CameraView = forwardRef<Camera | null, CameraViewProps>(function Ca
   // aspect on essentially every phone camera (incl. ultra-wide), so a
   // matching format is virtually always available; `useCameraFormat`
   // returns the closest match and never throws.
+  //
+  // Resolution preference matters too: filtering on aspect ALONE lets
+  // vision-camera settle on whatever 4:3 format sorts first — observed as
+  // a 192×144 VIDEO stream on the iPhone 16 Pro (the photo still uses the
+  // format's full-res photo dims, so you'd get a sharp capture behind a
+  // mush preview).  So we also request the highest video resolution.
+  //
+  // Why `'max'` and not a bounded target like 1920×1440?  We tried the
+  // bounded target and it FAILED on the iPhone 16 Pro: the nearest
+  // 1920×1440 format is a 10-bit format (pixel formats x420 / x422 only —
+  // and it is NOT flagged HDR, so the `videoHdr` filter can't dodge it).
+  // The frame processor + the stitcher's CV pipeline need 8-bit
+  // `420v`/`420f`, so vision-camera raises
+  // `device/pixel-format-not-supported` and silently falls back to a
+  // default pixel format — breaking non-AR stitching.  vision-camera does
+  // NOT expose a format's supported pixel formats to JS (no
+  // `pixelFormats` field; `FormatFilter` has no pixel-format key), so we
+  // can't select an 8-bit format by inspection.  Empirically the device's
+  // MAX 4:3 video format is 8-bit (420v/420f) on the iPhone 16 Pro, and
+  // Android formats are near-universally 8-bit YUV_420_888, so `'max'` is
+  // the robust choice: a sharp preview on a frame-processor-compatible
+  // pipeline.  Trade-off: the max format tends to run at 30 fps (fine for
+  // hold-to-pan) and feeds full-res frames to the non-AR gate — if that
+  // ever shows up as dropped frames we can downscale for the gate
+  // natively while keeping full-res keyframes.  Aspect stays the
+  // top-priority filter, so 4:3 WYSIWYG parity holds on every device.
+  //
+  // Still resolution is capped at ~12 MP.  The max-video 4:3 format pairs
+  // with a 24 MP photo (5712×4284) on the iPhone 16 Pro by default — 2×
+  // the file size + per-capture memory for no benefit on the panorama
+  // path (which uses the VIDEO stream, not takePhoto).  `photoResolution`
+  // is the LOWEST-priority filter, so it only breaks ties between equal
+  // max-video formats (e.g. the 12 MP-photo vs 24 MP-photo variants that
+  // share the same 4032×3024 video) — it never trades preview/stitch
+  // sharpness for a smaller still.  4032×3024 = 12 MP at 4:3; nearest-
+  // match keeps stills near there on any device.
   const format = useCameraFormat(device ?? undefined, [
     { photoAspectRatio: 4 / 3 },
     { videoAspectRatio: 4 / 3 },
+    { videoResolution: 'max' },
+    { photoResolution: { width: 4032, height: 3024 } },
   ]);
 
   // Measured size of our container, so we can size the <Camera> view to