react-native-image-stitcher 0.15.2 → 0.16.1

package/dist/camera/classifyStitchError.js

@@ -0,0 +1,42 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.classifyStitchError = classifyStitchError;
+function classifyStitchError(message) {
+    // Insufficient overlap surfaces two ways: cv::Stitcher's
+    // ERR_NEED_MORE_IMGS ("need more images") and the manual pipeline's
+    // "0 valid pairwise matches / frames may not overlap enough" — both are
+    // the same recoverable "pan more slowly" case.
+    if (/need more images|pairwise match|overlap enough/i.test(message)) {
+        return 'STITCH_NEED_MORE_IMGS';
+    }
+    if (/homography/i.test(message)) {
+        return 'STITCH_HOMOGRAPHY_FAIL';
+    }
+    // Degenerate camera params — the rapid/wide-pan divergent-warp path.
+    // Broadened beyond the original "camera params" so a future reword of
+    // the native throw can't silently drop the "pan more slowly" copy: the
+    // per-frame warp guard and the cumulative-canvas guard carry "warpRoi"
+    // / "canvas too large" / "degenerate" respectively (see cpp/stitcher.cpp
+    // degenerateFrameException / degenerateCanvasException).  Kept AFTER the
+    // homography branch and BEFORE the OOM branch so a true OOM string still
+    // routes to STITCH_OOM.
+    if (/camera params|warpRoi|degenerate|canvas too large/i.test(message)) {
+        return 'STITCH_CAMERA_PARAMS_FAIL';
+    }
+    // v0.16 — the native post-stitch validator rejected the output as
+    // disjoint / fragmented / wildly mis-proportioned (frames didn't connect
+    // into one coherent panorama).  The cpp throw carries "stitch validation"
+    // / "disjoint" / "fragmented" (see cpp/stitcher.cpp validateStitchOutput).
+    // Kept BEFORE the OOM branch so its distinct message isn't swallowed.
+    if (/stitch validation|disjoint|fragmented|low-quality stitch/i.test(message)) {
+        return 'STITCH_LOW_QUALITY';
+    }
+    // OOM, including the pre-stitch headroom abort ("pre-stitch memory abort"
+    // / "memory abort") that fires when even the minimal streaming config
+    // won't fit — same user remedy (shorter sweep), so same code.
+    if (/out of memory|oom|memory abort/i.test(message)) {
+        return 'STITCH_OOM';
+    }
+    return 'PANORAMA_FINALIZE_FAILED';
+}
+//# sourceMappingURL=classifyStitchError.js.map

package/dist/camera/cropGeometry.d.ts

@@ -0,0 +1,136 @@
+/**
+ * cropGeometry — pure coordinate + quad helpers behind the item-7
+ * draggable-corner crop editor (`RectCropPreview`).
+ *
+ * The editor shows the full result image with a `resizeMode="contain"`
+ * letterbox: the image is centred and uniformly scaled to fit the layout
+ * box, leaving symmetric bars on one axis.  The 4 draggable corners live in
+ * ON-SCREEN coordinates (the touch space PanResponder reports), but the
+ * native crop needs IMAGE-PIXEL coordinates.  These helpers are the
+ * letterbox transform and its inverse — extracted verbatim from
+ * `example/InscribedRectDebug.tsx` (~lines 178-204), which mapped an
+ * inscribed-rect from image px → screen the same way.
+ *
+ * Everything here is pure (no React, no native) so it's unit-testable
+ * without booting a render — same posture as `contentRotationDeg` and
+ * `buildPanoramaInitialSettings`.
+ *
+ * Coordinate conventions:
+ *   - A `Point` is `{ x, y }`.  Screen points are in the layout box's
+ *     local space (origin = box top-left); image points are in pixel
+ *     space (origin = image top-left, range [0..imageW] × [0..imageH]).
+ *   - A `Quad` is exactly 4 points.  `orderQuadCorners` canonicalises
+ *     winding to [TL, TR, BR, BL] so downstream native perspective
+ *     rectify gets corners in the order it expects.
+ */
+/** A 2-D point in either screen-local or image-pixel space. */
+export interface Point {
+    x: number;
+    y: number;
+}
+/** The contain-fit letterbox layout of the image inside its box. */
+export interface ContainLayout {
+    /** Layout box width (on-screen px). */
+    width: number;
+    /** Layout box height (on-screen px). */
+    height: number;
+}
+/** Exactly four points (corners of a crop quad). */
+export type Quad = [Point, Point, Point, Point];
+/**
+ * The contain-fit transform: uniform scale + centring offsets that map
+ * image-pixel space into the on-screen layout box.  Returns `null` when
+ * any dimension is non-positive (nothing to lay out).
+ *
+ * `scale` is `min(box.w / imageW, box.h / imageH)` — the same
+ * `resizeMode="contain"` math RN's <Image> applies — and `offX`/`offY`
+ * centre the scaled image, producing the letterbox bars.
+ */
+export declare function containFit(layout: ContainLayout, imageW: number, imageH: number): {
+    scale: number;
+    offX: number;
+    offY: number;
+} | null;
+/**
+ * Map an on-screen point (layout-box local coords) → image-pixel coords.
+ * Inverse of {@link imageToScreen}.  The result is clamped to
+ * `[0..imageW] × [0..imageH]` so a corner dragged onto / past the
+ * letterbox bar still yields a valid in-bounds pixel for the native crop
+ * (the user can't pick pixels that don't exist).
+ *
+ * Returns the un-mapped point unchanged when the layout is degenerate
+ * (see {@link containFit}) — the caller has no valid letterbox yet.
+ */
+export declare function screenToImage(point: Point, layout: ContainLayout, imageW: number, imageH: number): Point;
+/**
+ * Map an image-pixel point → on-screen point (layout-box local coords).
+ * Inverse of {@link screenToImage}.  Used to seed the draggable corners
+ * from an image-space initial rect and to keep the overlay aligned to the
+ * letterboxed image.
+ *
+ * Returns the un-mapped point unchanged when the layout is degenerate.
+ */
+export declare function imageToScreen(point: Point, layout: ContainLayout, imageW: number, imageH: number): Point;
+/**
+ * Re-order 4 arbitrary corner points into canonical
+ * [TL, TR, BR, BL] (clockwise from top-left) winding.
+ *
+ * Strategy (robust to slight perspective skew, no trig):
+ *   - Top two = the two points with the smallest `y`; bottom two = the
+ *     largest `y`.  Within each pair, the smaller `x` is left.
+ * Ties on `y` (a perfectly axis-aligned rect) resolve deterministically
+ * because the sort is stable and we then split by `x`.
+ *
+ * This matches the corner order the native `cropToQuad` perspective
+ * rectify expects (dst rect: TL→TR→BR→BL).
+ */
+export declare function orderQuadCorners(pts: Quad): Quad;
+/**
+ * 2× the signed area of a polygon via the shoelace formula.  Positive for
+ * counter-clockwise winding, negative for clockwise, ~0 for degenerate.
+ * Exported for tests + reused by {@link isQuadValid}.
+ */
+export declare function signedArea2(pts: Quad): number;
+/**
+ * True when the 4 points form a usable crop quad:
+ *   1. **Non-degenerate area** — `|signed area|` ≥ `minArea` (default
+ *      `1`, i.e. at least 1 px²).  Rejects all-collinear / zero-size.
+ *   2. **Convex** — every cross-product of consecutive edges shares one
+ *      sign (allowing zero for a straight, axis-aligned corner).  Rejects
+ *      self-intersecting / "bowtie" quads, which the native perspective
+ *      warp can't rectify.
+ *
+ * Operates on the points in their given winding (call `orderQuadCorners`
+ * first if you need canonical order); convexity is winding-agnostic.
+ */
+export declare function isQuadValid(pts: Quad, minArea?: number): boolean;
+/**
+ * Target rectangle size for the perspective `dst` quad, derived from the
+ * 4 ORDERED ([TL, TR, BR, BL]) image-pixel corners:
+ *   - `w` = average of the top edge (TL→TR) and bottom edge (BL→BR)
+ *     lengths.
+ *   - `h` = average of the left edge (TL→BL) and right edge (TR→BR)
+ *     lengths.
+ * Averaging opposite edges gives a stable output size for a skewed quad
+ * (each pair of opposite edges differs under perspective; the mean is the
+ * least-distorting target).  Rounds to whole pixels — the native crop
+ * allocates an integer-sized bitmap.
+ *
+ * Caller must pass corners already in [TL, TR, BR, BL] order (use
+ * {@link orderQuadCorners}); the math assumes that winding.
+ */
+export declare function rectSizeForQuad(orderedImagePts: Quad): {
+    w: number;
+    h: number;
+};
+/**
+ * True when an ORDERED ([TL, TR, BR, BL]) image-pixel quad is, within
+ * `tolerancePx`, an axis-aligned rectangle — i.e. the cheap axis-aligned
+ * `cropToRect` path applies and no perspective warp is needed.  The parent
+ * uses this to choose `cropToRect` vs `cropToQuad`.
+ *
+ * Checks the two top/bottom corners share a `y` and the two left/right
+ * corners share an `x`, all within tolerance.
+ */
+export declare function isAxisAlignedRect(orderedImagePts: Quad, tolerancePx?: number): boolean;
+//# sourceMappingURL=cropGeometry.d.ts.map

package/dist/camera/cropGeometry.js

@@ -0,0 +1,223 @@
+"use strict";
+// SPDX-License-Identifier: Apache-2.0
+/**
+ * cropGeometry — pure coordinate + quad helpers behind the item-7
+ * draggable-corner crop editor (`RectCropPreview`).
+ *
+ * The editor shows the full result image with a `resizeMode="contain"`
+ * letterbox: the image is centred and uniformly scaled to fit the layout
+ * box, leaving symmetric bars on one axis.  The 4 draggable corners live in
+ * ON-SCREEN coordinates (the touch space PanResponder reports), but the
+ * native crop needs IMAGE-PIXEL coordinates.  These helpers are the
+ * letterbox transform and its inverse — extracted verbatim from
+ * `example/InscribedRectDebug.tsx` (~lines 178-204), which mapped an
+ * inscribed-rect from image px → screen the same way.
+ *
+ * Everything here is pure (no React, no native) so it's unit-testable
+ * without booting a render — same posture as `contentRotationDeg` and
+ * `buildPanoramaInitialSettings`.
+ *
+ * Coordinate conventions:
+ *   - A `Point` is `{ x, y }`.  Screen points are in the layout box's
+ *     local space (origin = box top-left); image points are in pixel
+ *     space (origin = image top-left, range [0..imageW] × [0..imageH]).
+ *   - A `Quad` is exactly 4 points.  `orderQuadCorners` canonicalises
+ *     winding to [TL, TR, BR, BL] so downstream native perspective
+ *     rectify gets corners in the order it expects.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.containFit = containFit;
+exports.screenToImage = screenToImage;
+exports.imageToScreen = imageToScreen;
+exports.orderQuadCorners = orderQuadCorners;
+exports.signedArea2 = signedArea2;
+exports.isQuadValid = isQuadValid;
+exports.rectSizeForQuad = rectSizeForQuad;
+exports.isAxisAlignedRect = isAxisAlignedRect;
+/**
+ * The contain-fit transform: uniform scale + centring offsets that map
+ * image-pixel space into the on-screen layout box.  Returns `null` when
+ * any dimension is non-positive (nothing to lay out).
+ *
+ * `scale` is `min(box.w / imageW, box.h / imageH)` — the same
+ * `resizeMode="contain"` math RN's <Image> applies — and `offX`/`offY`
+ * centre the scaled image, producing the letterbox bars.
+ */
+function containFit(layout, imageW, imageH) {
+    if (layout.width <= 0
+        || layout.height <= 0
+        || imageW <= 0
+        || imageH <= 0) {
+        return null;
+    }
+    const scale = Math.min(layout.width / imageW, layout.height / imageH);
+    const dispW = imageW * scale;
+    const dispH = imageH * scale;
+    const offX = (layout.width - dispW) / 2;
+    const offY = (layout.height - dispH) / 2;
+    return { scale, offX, offY };
+}
+/**
+ * Map an on-screen point (layout-box local coords) → image-pixel coords.
+ * Inverse of {@link imageToScreen}.  The result is clamped to
+ * `[0..imageW] × [0..imageH]` so a corner dragged onto / past the
+ * letterbox bar still yields a valid in-bounds pixel for the native crop
+ * (the user can't pick pixels that don't exist).
+ *
+ * Returns the un-mapped point unchanged when the layout is degenerate
+ * (see {@link containFit}) — the caller has no valid letterbox yet.
+ */
+function screenToImage(point, layout, imageW, imageH) {
+    const fit = containFit(layout, imageW, imageH);
+    if (!fit)
+        return point;
+    const x = (point.x - fit.offX) / fit.scale;
+    const y = (point.y - fit.offY) / fit.scale;
+    return {
+        x: clamp(x, 0, imageW),
+        y: clamp(y, 0, imageH),
+    };
+}
+/**
+ * Map an image-pixel point → on-screen point (layout-box local coords).
+ * Inverse of {@link screenToImage}.  Used to seed the draggable corners
+ * from an image-space initial rect and to keep the overlay aligned to the
+ * letterboxed image.
+ *
+ * Returns the un-mapped point unchanged when the layout is degenerate.
+ */
+function imageToScreen(point, layout, imageW, imageH) {
+    const fit = containFit(layout, imageW, imageH);
+    if (!fit)
+        return point;
+    return {
+        x: fit.offX + point.x * fit.scale,
+        y: fit.offY + point.y * fit.scale,
+    };
+}
+/**
+ * Re-order 4 arbitrary corner points into canonical
+ * [TL, TR, BR, BL] (clockwise from top-left) winding.
+ *
+ * Strategy (robust to slight perspective skew, no trig):
+ *   - Top two = the two points with the smallest `y`; bottom two = the
+ *     largest `y`.  Within each pair, the smaller `x` is left.
+ * Ties on `y` (a perfectly axis-aligned rect) resolve deterministically
+ * because the sort is stable and we then split by `x`.
+ *
+ * This matches the corner order the native `cropToQuad` perspective
+ * rectify expects (dst rect: TL→TR→BR→BL).
+ */
+function orderQuadCorners(pts) {
+    // Sort a copy by y ascending so [0,1] are the top pair, [2,3] bottom.
+    const byY = [...pts].sort((a, b) => a.y - b.y);
+    const [t0, t1, b0, b1] = byY;
+    // Within each horizontal pair, smaller x is the left corner.
+    const [tl, tr] = t0.x <= t1.x ? [t0, t1] : [t1, t0];
+    const [bl, br] = b0.x <= b1.x ? [b0, b1] : [b1, b0];
+    return [tl, tr, br, bl];
+}
+/**
+ * 2× the signed area of a polygon via the shoelace formula.  Positive for
+ * counter-clockwise winding, negative for clockwise, ~0 for degenerate.
+ * Exported for tests + reused by {@link isQuadValid}.
+ */
+function signedArea2(pts) {
+    let sum = 0;
+    for (let i = 0; i < pts.length; i++) {
+        const a = pts[i];
+        const b = pts[(i + 1) % pts.length];
+        sum += a.x * b.y - b.x * a.y;
+    }
+    return sum;
+}
+/**
+ * True when the 4 points form a usable crop quad:
+ *   1. **Non-degenerate area** — `|signed area|` ≥ `minArea` (default
+ *      `1`, i.e. at least 1 px²).  Rejects all-collinear / zero-size.
+ *   2. **Convex** — every cross-product of consecutive edges shares one
+ *      sign (allowing zero for a straight, axis-aligned corner).  Rejects
+ *      self-intersecting / "bowtie" quads, which the native perspective
+ *      warp can't rectify.
+ *
+ * Operates on the points in their given winding (call `orderQuadCorners`
+ * first if you need canonical order); convexity is winding-agnostic.
+ */
+function isQuadValid(pts, minArea = 1) {
+    if (Math.abs(signedArea2(pts)) < minArea * 2)
+        return false;
+    return isConvex(pts);
+}
+/**
+ * Target rectangle size for the perspective `dst` quad, derived from the
+ * 4 ORDERED ([TL, TR, BR, BL]) image-pixel corners:
+ *   - `w` = average of the top edge (TL→TR) and bottom edge (BL→BR)
+ *     lengths.
+ *   - `h` = average of the left edge (TL→BL) and right edge (TR→BR)
+ *     lengths.
+ * Averaging opposite edges gives a stable output size for a skewed quad
+ * (each pair of opposite edges differs under perspective; the mean is the
+ * least-distorting target).  Rounds to whole pixels — the native crop
+ * allocates an integer-sized bitmap.
+ *
+ * Caller must pass corners already in [TL, TR, BR, BL] order (use
+ * {@link orderQuadCorners}); the math assumes that winding.
+ */
+function rectSizeForQuad(orderedImagePts) {
+    const [tl, tr, br, bl] = orderedImagePts;
+    const top = dist(tl, tr);
+    const bottom = dist(bl, br);
+    const left = dist(tl, bl);
+    const right = dist(tr, br);
+    return {
+        w: Math.round((top + bottom) / 2),
+        h: Math.round((left + right) / 2),
+    };
+}
+/**
+ * True when an ORDERED ([TL, TR, BR, BL]) image-pixel quad is, within
+ * `tolerancePx`, an axis-aligned rectangle — i.e. the cheap axis-aligned
+ * `cropToRect` path applies and no perspective warp is needed.  The parent
+ * uses this to choose `cropToRect` vs `cropToQuad`.
+ *
+ * Checks the two top/bottom corners share a `y` and the two left/right
+ * corners share an `x`, all within tolerance.
+ */
+function isAxisAlignedRect(orderedImagePts, tolerancePx = 1) {
+    const [tl, tr, br, bl] = orderedImagePts;
+    return (Math.abs(tl.y - tr.y) <= tolerancePx
+        && Math.abs(bl.y - br.y) <= tolerancePx
+        && Math.abs(tl.x - bl.x) <= tolerancePx
+        && Math.abs(tr.x - br.x) <= tolerancePx);
+}
+/** Convexity test: all consecutive edge cross-products share a sign. */
+function isConvex(pts) {
+    let sign = 0;
+    for (let i = 0; i < pts.length; i++) {
+        const a = pts[i];
+        const b = pts[(i + 1) % pts.length];
+        const c = pts[(i + 2) % pts.length];
+        const cross = (b.x - a.x) * (c.y - b.y) - (b.y - a.y) * (c.x - b.x);
+        if (cross !== 0) {
+            const s = cross > 0 ? 1 : -1;
+            if (sign === 0)
+                sign = s;
+            else if (s !== sign)
+                return false;
+        }
+    }
+    return true;
+}
+/** Euclidean distance between two points. */
+function dist(a, b) {
+    return Math.hypot(a.x - b.x, a.y - b.y);
+}
+/** Clamp `v` into the inclusive `[lo, hi]` range. */
+function clamp(v, lo, hi) {
+    if (v < lo)
+        return lo;
+    if (v > hi)
+        return hi;
+    return v;
+}
+//# sourceMappingURL=cropGeometry.js.map

package/dist/camera/displayDecodeImageProps.d.ts

@@ -0,0 +1,25 @@
+/**
+ * DISPLAY_DECODE_IMAGE_PROPS — props every <Image> that displays a
+ * FULL-RES capture (a stitched panorama or a photo file) must spread.
+ *
+ * Why this exists (the accumulation half of the OOM crash):
+ *   On Android 8+, decoded bitmap pixels live in the NATIVE heap, and the
+ *   source here is the full-resolution capture file — a wide panorama can
+ *   be tens of megapixels.  Without `resizeMethod="resize"`, Android/Fresco
+ *   decodes the source at FULL resolution into a native bitmap that the
+ *   mounted <Image> pins (not LRU-evictable), and Fresco's URI-keyed cache
+ *   keeps it even after the view unmounts.  Each capture (especially wide
+ *   panoramas) then accumulates tens of MB of native heap until lmkd
+ *   OOM-kills the app.  'resize' decodes at the on-screen (~device-width)
+ *   size instead, making per-image memory tiny and panorama-size-
+ *   independent.  No-op on iOS (harmless).
+ *
+ * Centralised (rather than a bare `resizeMethod="resize"` at each call
+ * site) so the decode strategy + its rationale have one home, and so the
+ * contract is unit-testable without mounting a component.  Spread it:
+ *   <Image source={...} resizeMode="cover" {...DISPLAY_DECODE_IMAGE_PROPS} />
+ */
+export declare const DISPLAY_DECODE_IMAGE_PROPS: {
+    readonly resizeMethod: "resize";
+};
+//# sourceMappingURL=displayDecodeImageProps.d.ts.map

package/dist/camera/displayDecodeImageProps.js

@@ -0,0 +1,29 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.DISPLAY_DECODE_IMAGE_PROPS = void 0;
+// SPDX-License-Identifier: Apache-2.0
+/**
+ * DISPLAY_DECODE_IMAGE_PROPS — props every <Image> that displays a
+ * FULL-RES capture (a stitched panorama or a photo file) must spread.
+ *
+ * Why this exists (the accumulation half of the OOM crash):
+ *   On Android 8+, decoded bitmap pixels live in the NATIVE heap, and the
+ *   source here is the full-resolution capture file — a wide panorama can
+ *   be tens of megapixels.  Without `resizeMethod="resize"`, Android/Fresco
+ *   decodes the source at FULL resolution into a native bitmap that the
+ *   mounted <Image> pins (not LRU-evictable), and Fresco's URI-keyed cache
+ *   keeps it even after the view unmounts.  Each capture (especially wide
+ *   panoramas) then accumulates tens of MB of native heap until lmkd
+ *   OOM-kills the app.  'resize' decodes at the on-screen (~device-width)
+ *   size instead, making per-image memory tiny and panorama-size-
+ *   independent.  No-op on iOS (harmless).
+ *
+ * Centralised (rather than a bare `resizeMethod="resize"` at each call
+ * site) so the decode strategy + its rationale have one home, and so the
+ * contract is unit-testable without mounting a component.  Spread it:
+ *   <Image source={...} resizeMode="cover" {...DISPLAY_DECODE_IMAGE_PROPS} />
+ */
+exports.DISPLAY_DECODE_IMAGE_PROPS = {
+    resizeMethod: 'resize',
+};
+//# sourceMappingURL=displayDecodeImageProps.js.map

package/dist/camera/guidanceGraphics.d.ts

@@ -0,0 +1,58 @@
+/**
+ * guidanceGraphics — code-drawn replacements for the two authored guidance
+ * GIFs (rotate-to-landscape, pan-capture).  Built from pure React-Native
+ * core `View` + `Animated` primitives — NO `react-native-svg`, NO bundled
+ * image assets — so the library keeps its "zero extra native deps for
+ * guidance" contract (see `RectCropPreview`) AND no longer needs the host
+ * to add Fresco's `animated-gif` module on Android just to make the
+ * coach-marks move.
+ *
+ * Why not GIFs:  the authored GIFs were 280 px sources shown at 240 dp;
+ * on a ~2.6×-density phone that 240 dp is ~630 physical px, so the 280 px
+ * source was up-scaled ~2.25× → visibly pixelated.  A 256-colour GIF also
+ * bands.  These vector-ish primitives are resolution-independent (they're
+ * just borders + transforms the GPU rasterises at native density) and fully
+ * themeable via `GUIDANCE_TOKENS`.
+ *
+ * Both graphics:
+ *   • run a single `Animated.loop` on the NATIVE driver (transform/opacity
+ *     only) so the loop is off the JS thread;
+ *   • take a `playing` flag — the host renders them only while `visible`,
+ *     but we still gate the loop so a mounted-but-paused graphic costs
+ *     nothing;
+ *   • scale every dimension off a single `size` (defaults to the shared
+ *     `GUIDANCE_TOKENS.graphicSize`) so callers can resize without restyle.
+ */
+import React from 'react';
+import { type StyleProp, type ViewStyle } from 'react-native';
+/** Pan direction the pan-graphic should animate (mirrors PanHowToOverlay). */
+export type PanGraphicDirection = 'down' | 'right';
+export interface GuidanceGraphicProps {
+    /** Canvas square size in px.  Defaults to `GUIDANCE_TOKENS.graphicSize`. */
+    size?: number;
+    /** Run the animation loop.  `false` parks the value at rest. */
+    playing?: boolean;
+    /** Outer style passthrough. */
+    style?: StyleProp<ViewStyle>;
+}
+/**
+ * RotatePhoneGraphic — a portrait phone outline that rotates 0°→90°→0°
+ * (portrait → landscape → portrait) on a loop, riding a faint amber guide
+ * ring with a clockwise arrowhead, demonstrating the "rotate to landscape"
+ * gesture.  Replaces `rotate-to-landscape.gif`.
+ */
+export declare function RotatePhoneGraphic({ size, playing, style, target, }: GuidanceGraphicProps & {
+    /** Orientation to rotate TO: 'landscape' (default) or 'portrait'. */
+    target?: 'landscape' | 'portrait';
+}): React.JSX.Element;
+/**
+ * PanPhoneGraphic — a phone outline (landscape for Mode-A `down`, portrait
+ * for Mode-B `right`) with an amber sweep band that travels across the pan
+ * axis on a loop, demonstrating the camera sweep.  The band fades in/out at
+ * the travel ends so the loop reset is invisible.  Replaces
+ * `pan-capture.gif`.  The bouncing direction arrow stays in PanHowToOverlay.
+ */
+export declare function PanPhoneGraphic({ direction, size, playing, style, }: GuidanceGraphicProps & {
+    direction: PanGraphicDirection;
+}): React.JSX.Element;
+//# sourceMappingURL=guidanceGraphics.d.ts.map