/**
 * CameraView — the SDK's drop-in replacement for the raw
 * vision-camera ``<Camera />``.
 *
 * Why wrap it?
 *   1. **Default props** — always ``isActive={true}``, ``photo={true}``,
 *      and honouring the hook's flash state.  Every call-site in the
 *      mobile app repeated the same tuple; the SDK canonicalises it.
 *   2. **Branded guidance overlay** — optional ``guidance`` prop renders
 *      a themed banner over the preview without the host app having to
 *      know about positioning / contrast.
 *   3. **Forward ref** — so ``useCapture``'s ref attaches cleanly.
 *
 * The component is intentionally thin — anything more elaborate goes
 * into a separate screen (e.g. AuditCaptureSurface that combines this
 * view with thumbnails and a shutter button).  Keeping CameraView at
 * the vision-camera layer means host apps that want a highly-custom
 * UI can still use it as their building block.
 */
import React from 'react';
import { type ViewStyle } from 'react-native';
import { Camera, type CameraDevice, type CameraProps } from 'react-native-vision-camera';
export interface CameraViewProps {
    /** Output of ``useCapture().device``.  If null, a placeholder is shown. */
    device: CameraDevice | null | undefined;
    /** Flash / torch state from ``useCapture().flash``. */
    flash?: 'off' | 'on';
    /**
     * v0.13.2 — zoom factor for the mounted device.  Used in multi-cam
     * mode to switch lenses (0.5× ultra-wide ↔ 1× wide) on a single
     * device.  `undefined` leaves vision-camera at its default zoom.
     */
    zoom?: number;
    /** Whether the preview is actively rendering.  Defaults to true. */
    isActive?: boolean;
    /**
     * Enable video recording on the underlying camera.  Required for
     * `useVideoCapture().startRecording()` — vision-camera throws
     * `capture/video-not-enabled` if you call startRecording without
     * this flag set.  Defaults to `false` so apps that only take photos
     * don't pay the video-pipeline allocation cost.
     *
     * Photo capture remains enabled regardless of this flag, so a
     * single `<CameraView video />` can do both tap (photo) and
     * hold (video → stitch) flows.
     */
    video?: boolean;
    /**
     * Opt into HIGH-RESOLUTION still capture (e.g. document scanning).  Raises
     * the photo-resolution cap so the picker selects the device's largest 4:3
     * still (e.g. 12.5 MP / 4080×3060 on the A35) and runs the camera at
     * `photoQualityBalance="quality"`.  The chosen format's VIDEO stream is
     * unchanged (still the 4:3 preview the frame-processor detection runs on),
     * so the preview + detection are unaffected — only the captured photo gets
     * bigger.  Default off (keeps the 4032px cap for back-compat).
     */
    highResCapture?: boolean;
    /**
     * iOS: opt into AVDepthData delivery for stills, so `useCapture` can save
     * a `<photo>.depth.bin` sidecar (see `extractPhotoDepth`).  Biases the
     * format picker toward `supportsDepthCapture` formats and sets
     * vision-camera's `enableDepthData`.  Depth only materialises when the
     * MOUNTED DEVICE is depth-capable (a multi-lens virtual device or the
     * LiDAR camera — the lens-driven `selectCaptureDevice` multicam pick
     * qualifies; a plain single wide-angle does not).  No-op on Android and
     * on depth-less devices/formats — capture proceeds without a sidecar.
     * Default off (depth delivery adds per-shot latency).
     */
    captureDepthData?: boolean;
    /**
     * Panorama keyframe QUALITY (non-AR path): floors the picked format's
     * VIDEO long edge at 1280 so the frame-processor stream — the source of
     * non-AR pano keyframes — stops delivering 640×480 tiles.  The 60 fps
     * preference still ranks within the floored set.  Soft on devices with
     * no qualifying format.  Default off.
     */
    keyframeQualityCapture?: boolean;
    /**
     * v0.23 anti-blur EXPOSURE CAP (non-AR path): the maximum exposure time,
     * in milliseconds, to allow while capturing.  0 / omitted = don't cap
     * (today's behaviour, session pinned at ≤60 fps).
     *
     * Implemented as an fps FLOOR, because the library owns THIS vision-camera
     * instance and vision-camera bounds exposure by the frame interval: it maps
     * the `fps` prop to `activeVideoMaxFrameDuration = 1/fps`, and auto-exposure
     * can never expose longer than one frame.  So requesting `maxExposureMs=8`
     * asks for a ≥125 fps session (≤1/125 s exposure); the format picker is
     * steered toward a high-fps format and the session fps ceiling is raised to
     * match.  This is NOT a fight with the session owner (the failure mode of a
     * raw AVCaptureDevice cap) — it is this instance's own public knob.
     *
     * Degrades gracefully: if the device's fastest 4:3 format tops out below the
     * requested rate, the session runs at that max (a looser-than-requested but
     * still-shortened exposure), never slower than today's 60 fps.  Interacts
     * with `keyframeQualityCapture`: a 1280-video floor can exclude the highest-
     * fps formats (often 720p), so enabling both trades some exposure ceiling
     * for keyframe resolution.
     */
    maxExposureMs?: number;
    /** Optional themed guidance banner.  Renders over the preview at the top. */
    guidance?: string;
    /** Extra style layer applied on top of the default full-screen layout. */
    style?: ViewStyle;
    /** Pass-through to vision-camera for anything custom. */
    cameraProps?: Partial<CameraProps>;
    /**
     * Called when the user taps the preview.  Host apps may use this to
     * drive focus-on-tap, AE/AF lock, etc.  Not wired into vision-camera's
     * focus API by this component on purpose — host apps have different
     * preferences (focus-on-tap vs. tap-to-lock).
     */
    onPreviewTap?: (event: {
        x: number;
        y: number;
    }) => void;
    /**
     * Forwarded from vision-camera's `<Camera onError>` AFTER lifecycle
     * errors are filtered.  The SDK's built-in filter swallows:
     *
     *   * `system/camera-is-restricted` — screen-lock / DoNotDisturb
     *     temporarily revokes camera access; vision-camera re-acquires
     *     on resume.  Logged to console.warn, NOT surfaced.
     *   * `system/camera-has-been-disconnected` — another app grabbed
     *     the camera.  Same auto-recovery.
     *   * `device/camera-already-in-use` — same class as above.
     *
     * Real errors (permission denials, hardware failures, malformed
     * format requests) are forwarded.  Hosts can therefore safely
     * pipe this to a redbox / Crashlytics without getting paged on
     * routine screen-lock events.
     */
    onError?: (error: unknown) => void;
}
export declare const CameraView: React.ForwardRefExoticComponent<CameraViewProps & React.RefAttributes<Camera | null>>;
//# sourceMappingURL=CameraView.d.ts.map