Raspberry Pi MIPI CSI cameras driven by Raspberry Pi's `libcamera` stack on a Raspberry Pi camera node. These sensors connect directly to the Pi's CSI-2 ribbon port and are exposed to Camera Server through the `rpi-libcamera` adapter.

- Relevant info: the supported sensor list mirrors what Raspberry Pi's own `libcamera` implementation recognizes. A sensor listed here is recognized by the adapter; test the exact module and Pi model before event use.
- Sensor names below are the libcamera sensor IDs. The friendly Raspberry Pi product name is shown in parentheses when one exists.
- Autofocus controls (AfMode, lens position) are only available on sensors that have a focus lens, such as the IMX708 (Camera Module 3). Fixed-focus sensors expose the rest of the libcamera controls but hide AfMode.

## Official Raspberry Pi sensors

- OV5647 (Raspberry Pi Camera Module V1)
- IMX219 (Raspberry Pi Camera Module V2)
- IMX708 (Raspberry Pi Camera Module 3)
- IMX477 (Raspberry Pi HQ Camera)
- IMX500 (Raspberry Pi AI Camera)
- IMX296 (Raspberry Pi Global Shutter Camera)

## Third-party sensors

- IMX290
- IMX327
- IMX378
- IMX519
- OV9281

## Relevant info

- These sensors are supported by Raspberry Pi's `libcamera` implementation and are surfaced through the `rpi-libcamera` adapter on a Raspberry Pi camera node.
- Test the exact sensor, Pi model, and libcamera build before event use. Behavior can vary with the sensor revision, the Pi's camera stack version, and the cable used.
- The IMX500 (AI Camera) and IMX296 (Global Shutter Camera) have specialized modes that are outside the standard still-capture path. Confirm the capture mode you need before relying on them at an event.


Raspberry Pi

- Use a sharing station at the guest handoff point so staff can confirm a result, show the QR code, or send the email.
- Use a replay station on a larger screen when guests or staff should browse finished sessions.
- Use kiosk or guided mode for public-facing screens that should stay on a narrow, event-specific flow.


Choose station roles

- From Devices, send a station to the correct event page instead of walking to the screen and typing a URL by hand.
- For public screens, keep the station pinned to its event role so guests cannot wander into operator-only parts of the app.
- If a screen shows the wrong page during the event, correct it from Devices and confirm the physical display updates.


Keep stations on task

- Test every station on the real event network before doors open, especially tablets, TVs, and older browsers.
- Confirm power, screen sleep settings, fullscreen mode, Wi-Fi or Ethernet stability, and the station name shown in Devices.
- Walk the real guest flow once: capture, review, share, scan QR, open the link, and replay the result on the intended screen.


Pre-event checklist

- Open the station page on each tablet, TV, kiosk, or operator browser, then confirm it appears online in Devices.
- Give each station a practical name based on its physical location, such as Share counter, Replay TV, or Staff tablet.
- Keep the Devices page open during setup so you can see which screens are connected before guests arrive.


Register and identify screens

| Shortcut | Action |
| --- | --- |
| Ctrl + , | Toggle dashboard layout editor. |
| Ctrl + L | Cycle dashboard display mode (normal / locked / minimal). |
| Escape | Close the dashboard layout editor. |


Dashboard & layout

| Shortcut | Action |
| --- | --- |
| Ctrl + Shift + mouse wheel | Zoom into the area under the cursor. |
| Ctrl + Shift + 0 | Reset magnification to 1x. |
| Escape | Reset magnification to 1x. |


Screen magnifier

| Shortcut | Action |
| --- | --- |
| Ctrl + Shift + H | Go to the dashboard. |
| Ctrl + 1 … 9 | Jump to Quick Nav slot 1–9 (configurable in Quick Nav settings). |
| Ctrl + Shift + O | Open the current page in an external browser. |

Quick Nav presets are configured in Settings > Quick Nav. Each preset can hold up to 9 pages mapped to Ctrl+1 through Ctrl+9.


Navigation

| Shortcut | Action |
| --- | --- |
| F11 or Alt+Enter | Toggle window fullscreen (or browser fullscreen in a web session). |
| Ctrl + Shift + F9 | Cycle demo window size presets (16:9 / 9:16 / 1:1). |
| PageUp | Toggle black screen overlay (for long-exposure photography). |
| Escape or click | Dismiss the black screen overlay. |


Window & display

| Shortcut | Action |
| --- | --- |
| ← / → | Previous / next dataset. |
| ↑ / ↓ | Previous / next frame. |
| PgUp / PgDn | Previous / next iteration. |
| G | Go to frame number. |
| Scroll wheel | Zoom in / out (at cursor). |
| Click + drag | Pan (when zoomed). |
| Double-click | Toggle fit ↔ 100%. |
| + / − | Step zoom in / out. |
| 0 | Fit to screen. |
| 1 | 100% zoom (1:1). |
| F | Cycle fit mode (fit / width / height). |
| B | Cycle background (black / white / checker). |
| C | Cycle guide overlay (off / crosshair / 3×3 / 4×4). |
| ? | Show / hide shortcuts. |
| Escape | Close inspector. |

These shortcuts are active when the Frames inspector is open.


Frames inspector

| Shortcut | Action |
| --- | --- |
| 0 … 5 | On the dataset detail page, clear or set the saved star rating. |
| Escape | Cancel pending transfer, dismiss bulk-action bar, or exit selection mode. |
| Ctrl + , | Open Library settings. |


Library

| Shortcut | Action |
| --- | --- |
| ← / → | Previous / next dataset. |
| 0 … 5 | Clear or set star rating on the current dataset (0 = clear, 1 = one star, 5 = five stars). |
| Escape | Close settings panel, or go back. |
| Ctrl + , | Open Quickview settings. |

Rating shortcuts work on the Quickview page and on the Quickview dashboard tile.


Quickview

| Shortcut | Action |
| --- | --- |
| F10 | Capture a JPG screenshot of the app window immediately. |
| Ctrl + F10 | Capture a JPG screenshot of the app window after a 2-second delay. |
| F7 | Start recording the app window. While recording: pause or resume. |
| F8 | Stop recording and save the clip. |

Recordings are saved in the active working folder under sessions/, each in its own folder named after its final MP4. Screenshots are saved separately under screenshots/.

Demo camera overlay shortcuts work after the overlay is configured. Camera 1, Camera 2, and Both view cycling becomes available once Camera 2 is running.

> Note: the demo-camera-overlay shortcut table from the original in-app help (camera bubble position/resize/zoom keys) is app-shell specific and was intentionally left out of this first migration pass; it can be added as its own page once its module ownership is confirmed.


Screeva

## What this export contains

- Export from Share Settings Logs to download a CSV of email queue recipients.
- Each row includes recipient email, dataset folder, status, sent date, plus configured custom fields.
- The export reflects queue history and filters, so apply your date and state filters before exporting.

## Why teams use it

- Post-event handoff to marketing or CRM systems.
- Delivery auditing for sent versus failed batches.
- Field-level analysis when custom form data is captured during sharing.

## Good practice

- Export at least once during rehearsal to validate field mapping.
- Keep a final export snapshot at event close for reporting and recovery workflows.

Download email list

## Core email flow

- Use email sharing when guests should receive a delivery link after operator confirmation.
- Keep templates, subject line, and reply-to aligned with the event brand before the first capture.
- Use required terms and custom fields only where compliance or follow-up needs justify the extra steps.

## Controls that affect delivery quality

- Enable multiple recipients only when operators are expected to send one capture to several contacts.
- Keep direct download available when email inbox access may be delayed on site.
- Verify SMTP sender configuration and test against real inbox providers before launch.

## Queue operations

- Monitor queue state for sent, pending, uploading, and failed jobs.
- Use queue details to inspect dataset path, attached files, subject preview, and rendered email body.
- Retry failed items from queue actions after fixing config or connectivity issues.


Email sharing

## What offline QR mode changes

- Offline QR mode bypasses cloud relay delivery and serves files from the local machine.
- The share modal shows two QR codes: one for joining Wi-Fi and one for opening the local download page.
- This mode is intended for venues with unstable internet or fully offline operations.

## Setup requirements

- Configure a dedicated sharing hotspot and set the expected Wi-Fi SSID in Share Settings.
- Keep the sharing station and guest phones on that same local network segment.
- Test with real phones before doors open. Do not rely on desktop browser simulation for this mode.

## Operational cautions

- If guests cannot join Wi-Fi, the download QR will still fail even if the code scans correctly.
- If the station sleeps, reboots, or changes network, retest both QR codes immediately.
- Use portal delivery instead when links must remain reachable after the local station is gone.


Offline QR sharing

## Define the output set before opening Share

- Decide which outputs are actually needed at handoff: image, video, combined media, thumbnail, and any print-specific version.
- Keep output naming clear so operators can quickly identify what is guest-facing versus archival.
- Use Process recipes to lock branding, overlays, framing, and ratio choices before the first live capture.
- Keep the output list lean. Too many variants slow down review and increase wrong-action clicks at the station.

## Match outputs to the delivery path

- QR and direct download should point to files that are light enough for phone delivery on event Wi-Fi.
- Email delivery should use the same branded files guests expect from QR, unless you intentionally send a different variant.
- Printing should have its own prepared source strategy (input, processed, both, or auto) so print quality is predictable.
- Portal delivery is best when links must stay valid after the booth machine powers down.

## Operator checklist before doors open

- Confirm one complete flow for each promised action: QR, email, print, and portal link when enabled.
- Confirm filenames and sorting make sense when multiple outputs are attached to the same capture.
- Confirm terms and custom fields only collect what the event actually needs.


Plan deliverables

## When portal delivery is the right choice

- Use portal delivery when links must remain active after the local sharing station is offline.
- Use it for events where guests often open media later, not only on-site.

## Dependencies to verify

- Confirm internet reachability and relay connection from Share Status.
- Confirm the app has a valid login session. Invalid or expired sessions can block relay startup.
- Keep offline QR mode disabled when you need cloud relay behavior, because offline mode bypasses relay delivery.

## Operational notes

- Run a full phone test from scan to final open link before guests arrive.
- Keep one operator check focused on relay and portal status after any network change.


Portal delivery

## Enable printing in the right places

- Turn on printing in Share Settings, then enable the print action in the Share preset used at the station.
- Refresh the printer list and choose a preferred printer before the event starts.
- Set paper size and copy limits so operators cannot accidentally overload a printer line.

## Choose print source strategy

- Input: fastest path from original files.
- Processed: uses branded outputs from recipes.
- Both or auto: useful when some captures have processed files and others do not.
- Enable fallback to input when processed files might not be ready in time.

## Live print workflow checks

- Test single and bulk print flows from the actual Share station.
- Verify quantity prompts only if your team needs per-job copy overrides.
- Watch print job status (queued, printing, completed, failed) during early event traffic.

Printing

## When to use QR sharing

- Use QR sharing when guests scan from the station and complete delivery on their own phone.
- Use it for single captures or multi-select batches from the Share screen.

## Configuration points that matter

- Choose QR placement for operator clarity: overlay on media preview or hidden from inline cards.
- Tune QR size and overlay position so the code stays readable on your actual sharing display.
- Keep direct download enabled when guests should save files immediately after opening the share page.
- Enable "require email before QR" only when your event needs contact collection before phone handoff.

## Live-operation checks

- Confirm Share is enabled and relay status is connected when using cloud QR mode.
- Scan from at least one Android and one iPhone device on the event network.
- Confirm both single-item and bulk QR flows if operators will share multiple captures together.


QR sharing

## QR and offline QR failures

- Confirm Share is enabled, then confirm whether the station is in cloud relay mode or offline QR mode.
- For cloud mode: verify internet and relay connected status before blaming QR generation.
- For offline mode: verify hotspot availability, SSID accuracy, and that guest phones join the same local network.
- Test QR from real phones, not only desktop previews.

## Email delivery failures

- Check queue state first: pending, uploading, failed, or sent.
- Open the failed queue item and inspect error message, recipients, and attached files.
- Recheck SMTP sender settings, required fields, and template placeholders after any config change.

## Print failures

- Confirm printing is enabled in both Share Settings and the active Share preset.
- Confirm the selected printer is online and paper settings match the expected format.
- If processed-source printing fails, test with input or fallback mode to isolate recipe/output timing issues.

## Portal and link persistence failures

- Confirm relay service is running and authenticated.
- If session is invalid, sign in again and rerun a full end-to-end share.
- If offline QR mode is enabled, remember that portal relay delivery is bypassed.

## Missing recipient export

- Export email CSV from Share Settings Logs after applying the intended filters.
- If export is unexpectedly empty, confirm there are queue records in the selected state/date scope.


Sharing or delivery issues

## Full pre-event test sequence

- Capture one real sample and verify all expected outputs exist.
- Run one QR share from the station screen and open it on a real phone.
- Run one email share and confirm inbox delivery, template rendering, and link behavior.
- Run one print job if printing is enabled, including copy-count behavior when quantity prompts are enabled.
- Run one portal delivery validation when cloud relay mode is expected.

## Validate details, not only success

- Confirm filenames and output variants are understandable to operators.
- Confirm terms, custom fields, and required email gates match the event policy.
- Confirm timing is acceptable under normal venue network conditions.

## Record and fix before go-live

- Log every mismatch (wrong branding, missing output, failed queue item, broken QR, print error).
- Fix settings first, then rerun the same test path until results are stable.


Run a test share

- When a result looks correct, promote that dataset as the active reference from the dataset menu in Library or from the Camera Alignment module itself.
- Future datasets on the same untouched rig can reuse the active reference automatically, so you do not need to align every capture again.


Set the active reference

- For markerless alignment, keep the arc within ~120 degrees, centre the subject, favour textured clothing, and light evenly.
- If a camera was bumped, analyze a fresh capture and promote it as the new reference.


Alignment failed

- Default. Cloud/3D runs Xangle-hosted 3D camera registration with no local install. Use this when you want managed processing and fast setup.
- RealityScan/3D is a full desktop 3D camera registration workflow via RealityScan (Epic Games, Windows only). Use this when you want a local 3D workflow and reusable reference files for later processing.
- Track/2D is an in-app 2D alignment path. No external tool is required, but it is meant for fixed arcs and does not recover real 3D camera poses.

## Engine comparison

On clean, properly lit datasets, all three registration engines can produce the same alignment result. For the cleanest alignment, follow the capture guidelines above.

- **Cloud/3D**: Efficiency 7/10. No extra app to install. There is no warranty on result quality, but it is generally good in normal capture conditions.
- **RealityScan/3D**: Efficiency 9/10. Excellent quality in most setups, but it requires a RealityScan license from Epic Games and runs on Windows only.
- **Track/2D**: Efficiency 5/10. Fast and fully in-app. Best for fixed arcs, not full 360 rigs.


Choose the engine

- Cloud camera registration runs on Xangle workers, so no extra software installation is required.
- Images are uploaded only for the active job and are deleted after results are downloaded.
- Usage is measured with camera registration credits: one registration job costs one credit, regardless of camera count.
- Credits are consumed only when the cloud registration job completes successfully.


Cloud camera registration

RealityScan is the default 3D alignment engine in Camera Server. Epic's official install flow is:

1. RealityScan runs on Windows only. Download and install the Epic Games Launcher from the official RealityScan download page.
2. Open the launcher, create or sign in to your Epic Games account, then open the RealityScan tab under the Unreal Engine section.
3. Install the latest RealityScan build. In Camera Server, you can usually leave the RealityScan path empty so it auto-detects the install under C:\Program Files\Epic Games.
4. If RealityScan was installed somewhere else, paste the executable path manually in the Alignment settings.
5. Run one reference dataset from Camera Alignment or Library to confirm Camera Server can launch RealityScan headlessly and write the reference files.

## Cost and licensing

- Epic currently lists RealityScan as free for students, educators, educational institutions, and individuals or companies under $1 million USD in annual gross revenue.
- Above the $1 million USD revenue threshold, Epic sells yearly RealityScan seats. The public license page currently lists CA$1,697 per seat per year and also advertises a 30-day trial.
- Check the official RealityScan licensing page before budgeting or purchasing seats, because public pricing and terms can change.

## Learning and support

- Epic Developer Community provides RealityScan documentation, tutorials, sample datasets, and community forums when you need to learn the tool or troubleshoot the install.


Install RealityScan

An in-app alignment engine that straightens an arc of photos without RealityScan or any calibration markers. It works directly on the images by tracking the center subject from one camera to the next.

## When to use it

- Best for a fixed camera rig where the cameras do not move between captures. Align once, then reuse the result as the active reference for every later dataset.
- A fast, fully offline alternative to RealityScan or COLMAP that needs no external tool and no markers.
- It produces a 2D similarity transform per camera: shift, rotate, and uniform zoom. That is enough to straighten orbit or arc captures, but not enough for full 3D photogrammetry.

## Capture requirements

- **Up to 120 degrees of arc.** Beyond roughly 120 degrees, adjacent cameras stop sharing enough of the same view and the match can drift. Keep the total arc at 120 degrees or less.
- **A centered subject is required.** The engine locks onto whatever sits in the middle of the frame, so the subject must stay roughly centered in every camera.
- **Texture helps.** Dress the subject in patterned or detailed clothing when possible. Flat or single-colour surfaces give the matcher less to lock onto.
- **Light it properly.** Even, bright lighting gives crisp detail to match. Harsh shadows, blown highlights, or a dim subject reduce the number of usable features.

## How it works

- The first camera is the reference. Each following camera is matched to its neighbor, and those small steps are chained back to the reference to stay in the high-overlap region.
- Matching runs inside a centered region of interest so the subject, not a busy background, drives the alignment.
- A common interior crop is computed so every aligned frame stays inside the valid image area with no black edges.

## Tuning the settings

- **ROI width and height (%).** This is the size of the center region used for matching. Widen it if the subject fills the frame; tighten it if the background is pulling the alignment away from the subject.
- **Max ORB features.** Raise it for low-texture scenes to find more matches, but expect slower processing. Lower it when the subject is already richly textured and speed matters more.
- **Sub-pixel refinement iterations.** These are the ECC sub-pixel refinement passes. More iterations can sharpen the lock at the cost of time; the default is a good balance.

## Reusing the result

- When the alignment succeeds, the computed transforms are saved and the dataset becomes the active reference.
- Later datasets captured on the same untouched rig automatically reuse those transforms. If you physically move or re-aim any camera, run the alignment again to refresh the reference.

## Important boundary

Track/2D is purely 2D. It does not recover real 3D camera poses, so it is meant for straightening orbit or arc turntable shots, not for full photogrammetry or Gaussian-splat reconstruction.


Track/2D alignment

- If any camera is bumped, re-aimed, re-focused, or moved during the event, capture a fresh alignment shot and promote it as the new reference before continuing.
- If the rig changes a lot between captures, enable auto re-align for new datasets instead of relying on one long-lived reference.


Recover from a bumped camera

## How to get a strong camera registration

- Frame the subject in the center so each camera sees the same central mass instead of edge clutter.
- Use even, stable lighting and avoid flicker, harsh shadows, or blown highlights.
- Keep the subject still so every camera captures the same moment in time.
- Prefer textured clothing or surfaces so the alignment engine can match the same 3D environment more reliably.

## What RealityScan writes

- Reference XMP sidecars for each registered camera.
- registration.csv for the aligned camera rig.
- A sparse point cloud for the 3D alignment preview.
- Optional: native COLMAP export for downstream processing when that setting is enabled.


Get a strong camera registration

- Hold the trigger to warm up before firing.
- Try shifting the sacrifice / flash slider by 1–2 ms.
- Confirm the camera is detected and online in the camera list.


Camera not triggering

Your guide to browsing, analysing, and downloading media from supported cameras and devices.

## What is camera storage?

This module lets you browse the media stored on connected cameras and mobile devices, verify that every trigger event was captured across the rig, and download the files as organized datasets ready for 3D processing.

## Best practices

- **Start every session with empty cards.** Format or delete all photos and videos from camera storage before shooting. Leftover files from a previous session confuse the shot-matching algorithm and produce false "incomplete" warnings.
- **Resync clocks before a long session.** Open the Network Nodes module and run "Resync clocks" if your Pis or cameras have been online for several hours. Clock drift accumulates over time and large drift can prevent the analyser from correctly matching shots across cameras.
- **Avoid accidental solo triggers.** A single camera triggered alone creates an extra shot entry. If you do fire a test shot on one camera, that is fine: the analyser marks it as a 1-camera solo and excludes it from dataset completeness counts.
- **Wait 3 to 5 seconds between shots.** The matching algorithm uses a 2-second clustering window. Firing faster than every 3 seconds may merge adjacent shots.
- **Use "Analyse All" before downloading.** This scans every camera, calibrates clock offsets, and shows you which datasets are complete or missing files before you commit to a download.

## How dataset matching works

When you click "Analyse All", the system scans every camera card and runs a calibrated timestamp clustering algorithm to determine which files across cameras belong to the same synchronized trigger event:

1. **Group files into captures.** Files with the same base name (for example IMG_0001.JPG + IMG_0001.CR2) are treated as one capture event, or one rendition set.
2. **Calibrate clock offsets.** Camera clocks drift apart over time. The analyser uses offset voting to determine the exact time difference between each camera and camera 1. This works even if clocks are minutes or hours apart.
3. **Cluster by adjusted time.** After normalizing timestamps, captures within a 2-second window that come from different cameras are grouped into a single shot. Each camera can appear at most once per shot.
4. **Classify completeness.** A dataset is complete when all cameras with cards have files for it, incomplete when some cameras are missing, and extra when only one camera fired.

## Dot colors

Each dataset row shows a dot per camera: **Present** (file found), **Missing** (no file for that camera).

## Download modes

- **New timestamp.** Downloads selected shots into your project's input folder using the current time as the dataset folder name, organized by camera. Ready for immediate 3D processing.
- **Photo dump.** Downloads raw files into a flat "Photo Dump" folder without organizing them into datasets. Useful for quick retrieval or manual sorting.

## Typical workflow

1. Format camera cards (start fresh).
2. Resync clocks from Network Nodes if needed.
3. Shoot your session.
4. Click "Analyse All" to see all matched shots and completeness status.
5. Review any incomplete datasets (check for missing cameras).
6. Select the datasets you want, choose "New timestamp" mode, and download.


Storage

Android phones can join a Camera Server rig through Xangle Remote Camera. Set up each phone once by USB, then use the local Wi-Fi network during operation.

## Supported source

- Android phones running Xangle Remote Camera on the same local network as Camera Server.

## Requirements

- Android 8.0 or later (API level 26 or later).
- A USB data cable for the first-time setup and future app updates.
- Developer options and USB debugging enabled on every phone.
- One local Wi-Fi network shared by Camera Server and all phones, without guest-network client isolation.

## First-time setup

Complete these steps for each phone before the event:

1. On the phone, open **Settings**, find **About phone**, then tap **Build number** seven times to enable Developer options. The exact menu names vary by phone manufacturer.
2. Return to **Settings**, open **Developer options**, and enable **USB debugging**.
3. Connect the phone to the computer running Camera Server with a data-capable USB cable. Avoid charge-only cables.
4. Unlock the phone and accept the **Allow USB debugging** prompt. Select **Always allow from this computer** when the phone offers it.
5. Start Camera Server. On the Camera page, open **Camera Adapters** and activate the **Android** adapter.
6. Camera Server detects connected Android phones and installs the bundled **Xangle Remote Camera** app when it is missing or outdated, grants its required permissions, and launches it.
7. Keep the app open, allow Camera and notifications permissions if the phone asks, then disconnect the USB cable after provisioning is complete.

USB is needed only to provision or update the app. Reconnect it later when Camera Server needs to reinstall the app or when troubleshooting a phone that does not appear.

## Update Xangle Remote Camera

Updates are automatic. When Camera Server includes a newer Xangle Remote Camera APK:

1. Connect the phone to the Camera Server computer by USB, unlock it, and accept the USB debugging prompt if it appears.
2. Camera Server detects the new build and installs it on the phone without any extra step.
3. Disconnect the phone once the app has relaunched. It returns to normal Wi-Fi operation when Xangle Remote Camera is open.

Tap the Xangle Remote Camera logo at the top of the phone's screen to check its installed version against Camera Server's version and host.

If a phone does not pick up an update after being connected for a while, use **Reinstall APK** in the Android camera adapter settings in Camera Server to force a fresh install on every connected phone. This is a manual fallback for troubleshooting, not a required step for routine updates.

## Uninstall Xangle Remote Camera

On the phone, open **Settings** > **Apps** > **Xangle Remote Camera** > **Uninstall**. This removes the app and its local capture data. Remove the phone from the Camera Server roster if it remains listed while offline.

For a fleet managed by a technician, the same removal can be performed over USB with Android Debug Bridge. Camera Server does not currently provide an uninstall action.

## Connect over Wi-Fi

1. Connect the computer running Camera Server and every provisioned phone to the same event Wi-Fi network. They must be able to reach each other on the local network.
2. Do not use a guest Wi-Fi network or a network with client isolation enabled. Those configurations prevent Camera Server from discovering phones.
3. Open Xangle Remote Camera on each phone and keep it in the foreground.
4. Wait for each phone to appear in the Camera control roster. A phone appears as one camera; choose its lens in the camera settings.
5. Verify live view, a trigger, and a completed download from every phone before the event starts.

## Relevant info

- Keep the app in the foreground and keep the phone awake during the event.
- Each phone appears as one camera. The selected lens is a setting on that camera, not a separate camera in the roster.
- Before the event starts, run a full trigger and download test on the exact phone model and Wi-Fi network you plan to use.

## Troubleshooting

- **The phone is not detected over USB:** unlock it, confirm USB debugging is enabled, accept the debugging authorization prompt, and try another data-capable cable or USB port.
- **The phone does not appear after moving to Wi-Fi:** confirm the app is open, the phone and Camera Server use the same local network, and neither is on guest Wi-Fi or behind client isolation.
- **The phone drops out during capture:** keep the screen awake, leave Xangle Remote Camera open in the foreground, and prevent the phone from switching to another Wi-Fi network or mobile data.


Android

Canon EOS cameras via EDSDK. Canon remains the most used and most tested path for multi-camera event rigs.

- Relevant info: Canon is the main event-ready path for Windows, Raspberry Pi, and Mac rigs when the body and tethering setup are tested properly.
- Camera names vary by region. Rebel, numbered, and Kiss names are shown together when known.

## EOS R mirrorless

- Canon EOS R, RP, Ra, R1, R3, R5, R5 Mark II, R6, R6 Mark II, R6 Mark III, R7, R8, R10, R50, R50 V / R50V, R100

## EOS M mirrorless

- Canon EOS M50 / EOS Kiss M, M50 Mark II / EOS Kiss M2, M6 Mark II, M200

## EOS DSLR bodies

- Canon EOS-1D X Mark III, 1D X Mark II, 1D X, 1D C, 1D Mark IV, 1D Mark III, 1Ds Mark III, 5D Mark IV, 5D Mark III, 5D Mark II, 5DS, 5DS R, 6D Mark II, 6D, 7D Mark II, 7D, 90D, 80D, 77D / 9000D, 70D, 60D, 50D, 40D

## EOS Rebel / numbered / Kiss bodies

- Canon EOS 850D / Rebel T8i / Kiss X10i, 250D / Rebel SL3 / Kiss X10, 2000D / 1500D / Rebel T7 / Kiss X90, 4000D / 3000D / Rebel T100, 200D / Rebel SL2 / Kiss X9, 800D / Rebel T7i / Kiss X9i, 1300D / Rebel T6 / Kiss X80, 760D / Rebel T6s / EOS 8000D, 750D / Rebel T6i / Kiss X8i, 1200D / Rebel T5 / Kiss X70, 100D / Rebel SL1 / Kiss X7, 700D / Rebel T5i / Kiss X7i, 650D / Rebel T4i / Kiss X6i, 600D / Rebel T3i / Kiss X5, 1100D / Rebel T3 / Kiss X50, 550D / Rebel T2i / Kiss X4, 500D / Rebel T1i / Kiss X3, 1000D / Digital Rebel XS / Kiss F, 450D / Digital Rebel XSi / Kiss X2

## PowerShot models

- Canon PowerShot V10, ZOOM, G7 X Mark III, G5 X Mark II, SX70 HS


Canon

GoPro cameras over USB or wireless. USB is the preferred path for event work. GoPro over Wi-Fi is Experimental and should be tested on the real network before the event.

## Supported models

- HERO11, HERO12, HERO13

## Relevant info

- Direct USB to a Windows host is the preferred connection path for smaller rigs.
- For larger arrays, Raspberry Pi clients over Ethernet are the preferred architecture.
- Before event use, run a full trigger, download, and playback test on the exact cabling, hub layout, and network you plan to deploy.


GoPro

iPhone devices via Xangle Remote Camera. iPhones support live view, photo, video, autofocus, lens selection, and exposure settings when running the Xangle Remote Camera app on the same event Wi-Fi network.

## Supported models

- iPhone 12, 12 mini, 12 Pro, 12 Pro Max
- iPhone 13, 13 mini, 13 Pro, 13 Pro Max
- iPhone SE (3rd generation)
- iPhone 14, 14 Plus, 14 Pro, 14 Pro Max
- iPhone 15, 15 Plus, 15 Pro, 15 Pro Max
- iPhone 16, 16 Plus, 16 Pro, 16 Pro Max, 16e
- iPhone 17, 17 Pro, 17 Pro Max, iPhone Air
- Newer iPhones that ship after this list still work on iOS 17 or later; they appear under their hardware identifier until the model name is added.

## Relevant info

- The app requires iOS 17 or later and must stay in the foreground during an event.
- Disable Auto-Lock so the screen does not turn off mid-capture.
- USB is not required. iPhones connect over Wi-Fi.


iPhone

Sony cameras via USB. Sony support is newer than Canon and GoPro support. Test the exact body before event use, especially for video recording or file download.

## Supported models

- Sony RX0 II / DSC-RX0M2 (photo only, video capture is not supported on this body, see notes below)
- Sony RX1R III / DSC-RX1RM3
- Sony Alpha 1 / ILCE-1, Alpha 1 II / ILCE-1M2, Alpha 6700 / ILCE-6700, Alpha 7C / ILCE-7C, Alpha 7C II / ILCE-7CM2, Alpha 7CR / ILCE-7CR, Alpha 7 IV / ILCE-7M4, Alpha 7 V / ILCE-7M5, Alpha 7R IV / ILCE-7RM4, Alpha 7R IV A / ILCE-7RM4A, Alpha 7R V / ILCE-7RM5, Alpha 7S III / ILCE-7SM3, Alpha 9 II / ILCE-9M2, Alpha 9 III / ILCE-9M3
- ZV-E1, ZV-E10 II / ZV-E10M2, MPC-2610, PXW-Z200, PXW-Z300, PXW-Z380

## Additional notes

- Sony RX0 II / DSC-RX0M2: video capture is not supported. The body can shoot and download photos, but recorded clips stay on the camera SD card and cannot be pulled back to Camera Server over USB.
- For event work, test the exact Sony body, firmware, USB mode, and cabling before deployment.


Sony

USB webcams and capture devices. Webcam support is Experimental, but photo capture and video capture are already usable when the exact webcam and driver have been tested.

## Supported source

- USB webcams on Windows computers and Raspberry Pi / Linux camera nodes.

## Relevant info

- Test the exact webcam, driver, and capture format before event use.
- Experimental means it is still under active development and should not be assumed event-ready until your own test passes.


Webcam

Use this page to prepare each camera family before the first event. Camera Server can handle many day-to-day settings later, but these body-side settings should be done once per camera.

## Before you start

- If camera bodies have been used on different installs, do a factory reset first so every unit starts from the same baseline.
- Connect cameras in the same physical order as the rig before you number them in Camera Server.
- Prefer wired connections for event rigs whenever that camera family supports them.

## Canon USB cameras

Apply these settings on each Canon body before connecting it to the rig:

1. Set the main dial to M (manual).
2. Leave the lens in AF so you can focus during setup with half-press or a back-button AF control on supported bodies.
3. On recent bodies, disable Retract lens on power off so a power cycle does not shift the focus point.
4. Enable a 6x4 grid overlay to help with pre-calibration and framing checks.
5. Set AF method to 1-point AF.
6. Avoid Servo focus on the event rig. Focus the shot, then leave the camera in a stable single-point focus mode.

## Sony USB cameras

Sony bodies need a few more one-time menu changes before they are ready for Camera Server:

1. Complete every first-boot prompt, including language, date and time, timezone, and the Imaging Edge link, so the camera will not stop for onboarding again later.
2. Set the main dial, or Shooting mode, to M (manual exposure).
3. Set Focus area to Center and keep AF w/shutter enabled.
4. Turn Control with Smartphone off.
5. Turn PC Remote on.
6. Turn Long Exposure NR, High ISO NR, SteadyShot, and DRO off.
7. Turn the camera grid overlay on to make pre-calibration easier.
8. Power the camera off and back on after saving the settings, especially if you use battery couplers.

## GoPro HERO11 to HERO13

GoPro setup starts with the rig architecture, because the connection path matters more than on USB mirrorless bodies:

1. Choose the connection architecture first: direct USB to a Windows host for smaller rigs, or Raspberry Pi clients over Ethernet for larger arrays.
2. Use the wired GoPro Labs workflow for stable event rigs. GoPro over Wi-Fi remains Experimental and should be treated as a test path, not the default production path.
3. Use high-quality powered USB hubs. On Pi-based rigs, group each set of cameras on a client node instead of trying to load one computer USB bus with the whole array.
4. Power cameras on one by one in the physical order of the rig so Camera Server can assign and remember the correct numbers.
5. After the cameras appear, set the trigger mode and the rest of the capture settings from the Xangle dashboard so the whole array stays consistent.
6. Before event use, run a full trigger, download, and playback test on the exact cabling and hub layout you plan to deploy.

## Android phones

Android phones join the rig through the Xangle Remote Camera app and the local network, just like other phone cameras:

1. Install and open the Xangle Remote Camera app on the phone, or complete the one-time USB provisioning flow if that is how you deploy the app to the device.
2. Keep the app in the foreground and grant Camera and Local Network permissions the first time it runs.
3. Put the phone on the same local network as the machine running Camera Server.
4. Wait for the phone to appear in the camera grid as a single camera, then open its tile and verify live view, photo capture, video capture, and lens selection.
5. Before the event starts, run a full trigger and download test on the exact phone model and Wi-Fi network you plan to use.

### Android operating notes

- Keep the phone awake and keep the app in the foreground. A locked or backgrounded phone is not a reliable camera node.
- Each phone appears as one camera. The selected lens is a setting on that camera, not a separate camera in the roster.
- If the phone is missing from the roster, confirm the app is open, the phone is on the same network, and Local Network permission was granted.
- If the phone connects but shows no live view, reopen the app and confirm Camera permission is still allowed.

## iPhone on Mac (Experimental)

iPhone support is Experimental. Setup currently requires help from the Xangle team because the iPhone app is not publicly distributed yet. Follow these steps the first time you connect an iPhone to Camera Server running on a Mac. Once the phone is discovered, it will reconnect automatically on the same network.

1. Make sure you have a Mac running Camera Server (XCS26 or later), an iPhone running iOS 17 or later, and both devices on the same Wi-Fi network or subnet.
2. Install Xangle Remote Camera on the iPhone before the event with help from the Xangle team. The app is not on the App Store yet, so self-service installation is not supported today.
3. Launch Camera Server on the Mac, open the Cameras module, and confirm the status bar shows the server is listening (default port 8680).
4. Open the Xangle Remote Camera app on the iPhone. The app advertises itself on the local network with Bonjour and shows the phone name, IP address, and connection state.
5. Wait a few seconds for Camera Server to discover the iPhone automatically. If it does not appear, verify both devices are on the same subnet and that UDP 5353 (mDNS) and TCP 50080 are not blocked.
6. Open the iPhone tile, test photo capture, test video recording, and confirm autofocus responds before the event starts.

### iPhone operating notes

- Keep the Xangle Remote Camera app in the foreground on the iPhone at all times during an event. iOS suspends background camera access.
- Disable Auto-Lock on the iPhone (Settings → Display & Brightness → Auto-Lock → Never) so the screen does not turn off mid-capture.
- If the phone disconnects, simply reopen the app. It will re-advertise and Camera Server will reconnect within seconds.
- For multi-phone rigs, each phone needs its own unique name (Settings → General → About → Name) so the grid can distinguish them.
- USB connection is not required. iPhones connect exclusively over Wi-Fi.
- If you are using a captive-portal event network, make sure the phone has completed the portal sign-in before launching the app.


Cameras initial configuration

Camera numbering controls trigger participation, lane order, and frame naming. Treat numbering as part of rig setup, not as an afterthought.

## How numbering works

- Each active camera should have one unique number. Number conflicts are resolved with Swap or Kick out.
- A camera with ? is detected but not in the numbered firing order.
- Setting a camera to 0 removes its number.
- Missing cameras stay in the roster as missing rows, which helps preserve slot identity by serial.

## First-time numbering flow

1. Connect and power cameras in the same physical order as the rig.
2. Wait until the full roster is visible in Cameras.
3. Use Re-number to auto-assign numbers from discovered order.
4. Open any camera row to fine-tune numbers manually where needed.
5. Run one full trigger and confirm numbering matches your expected physical positions.

## Manual assignment and conflict handling

- Click a number cell to open Set camera number.
- If the target number is already used, choose Swap to exchange slots or Kick out to unnumber the conflicting camera.
- Use Remove from numbering when you want a camera fully out of the active numbered roster.
- Use Idle when a camera should stay connected for live view and settings sync but never trigger.
- Use Name (serial bound) for physical body identity and Name (numbering bound) for role-based slot naming.

## Numbering maintenance tools

- Compact numbering re-packs numbered cameras into a clean 1..N sequence with no gaps.
- Import / Export lets you save and restore complete numbering states between rigs or machines.
- A backup is created automatically before re-number, import, and swap operations.
- Import from backup restores a previously saved numbering snapshot.
- Import from older XangleCS supports legacy order_current.json migration when moving from older installs.

## Limits and operator notes

- License limits still apply: cameras numbered above the active limit are over-limit and will not trigger.
- Local cameras only is a view filter. It hides remote rows but is not the normal tool for editing numbering.
- Reset clears roster state and assigned numbers. Use it intentionally, then re-number from scratch.
- Before event day, lock numbering and avoid unnecessary renumber passes after alignment is validated.


Numbering cameras

## What this is

The sacrifice camera is the camera that fires halfway through the exposure so the flash syncs on light instead of relying only on the mechanical shutter timing.

A flash trigger is mounted on top of the sacrifice camera. When that camera fires, the trigger sends one signal to all of your flashes at once. One flash trigger can drive one or multiple flashes.

## How to use it

1. Enable accuracy compensation for the group you want to shoot with flash.
2. Mount your flash trigger on the sacrifice camera.
3. Leave the sacrifice camera on the default last camera, or choose a different camera from the dropdown in the sacrifice panel.
4. Use Auto (half exposure) to start from the midpoint of the current shutter speed, then fine-tune with Shift by if needed.
5. Use Manual only when you want to enter a fixed millisecond delay yourself.

## Important

The image from the sacrifice camera is intentionally discarded. It is not downloaded and you will not see it in your dataset.

We have seen better results on Canon cameras, especially when using the popup flash, with a shift between -5 ms and -2 ms. Test to confirm what works best with your current configuration.


Sacrifice mode & flash

| Shortcut | Action |
| --- | --- |
| B (hold, then release) | Arm the trigger (warmup), then capture on release. |
| Ctrl + click trigger button | Auto-focus every lens once. |
| Ctrl + Shift + Y | Toggle two-click trigger mode on or off. |

The default trigger key is B. You can remap it from Button Mapping in the main menu. Gamepad B button mirrors the keyboard trigger by default.


Trigger

Use this page to check whether a camera body belongs on the event rig. If a model is not listed, connect it and run a full test capture before relying on it at a live event.

> **Important:** As much as we would love to test every camera, there are simply too many models on the market. Please test with your own equipment so you can confirm whether this software suits your requirements. What we know for sure: Canon cameras have been, by far, the most used and most tested bodies for multi-camera setups, both with and without our software. Compatibility can vary with camera firmware, USB mode, cable quality, hub chipset, power delivery, drivers, and network conditions. If you plan to use third-party batteries or battery couplers, review the camera manufacturer's warranty terms and power guidelines before deployment.

## Details

- Listed models should be able to connect, trigger, and send files back to Camera Server when the camera is set up correctly.
- Camera names vary by region. For Canon Rebel / Kiss bodies, the European number and Japanese Kiss name are shown on the same line when known.
- Sony support is newer than Canon and GoPro support. Test the exact Sony body before the event, especially if you need video recording or file download.
- GoPro support covers HERO11, HERO12, and HERO13. GoPro over Wi-Fi is Experimental; USB is preferred for event work.
- iPhone and Android phones connect over Wi-Fi and are well supported for live view, photo, and video capture with the Xangle remote camera app.
- Webcam support is Experimental. It is still under development, but it currently works well for capturing photos or videos after testing the exact webcam and driver.

## EOS R mirrorless

- Canon EOS R, RP, Ra, R1, R3, R5, R5 Mark II, R6, R6 Mark II, R6 Mark III, R7, R8, R10, R50, R50 V / R50V, R100

## EOS M mirrorless

- Canon EOS M50 / EOS Kiss M, M50 Mark II / EOS Kiss M2, M6 Mark II, M200

## EOS DSLR bodies

- Canon EOS-1D X Mark III, 1D X Mark II, 1D X, 1D C, 1D Mark IV, 1D Mark III, 1Ds Mark III, 5D Mark IV, 5D Mark III, 5D Mark II, 5DS, 5DS R, 6D Mark II, 6D, 7D Mark II, 7D, 90D, 80D, 77D / 9000D, 70D, 60D, 50D, 40D

## EOS Rebel / numbered / Kiss bodies

- Canon EOS 850D / Rebel T8i / Kiss X10i, 250D / Rebel SL3 / Kiss X10, 2000D / 1500D / Rebel T7 / Kiss X90, 4000D / 3000D / Rebel T100, 200D / Rebel SL2 / Kiss X9, 800D / Rebel T7i / Kiss X9i, 1300D / Rebel T6 / Kiss X80, 760D / Rebel T6s / EOS 8000D, 750D / Rebel T6i / Kiss X8i, 1200D / Rebel T5 / Kiss X70, 100D / Rebel SL1 / Kiss X7, 700D / Rebel T5i / Kiss X7i, 650D / Rebel T4i / Kiss X6i, 600D / Rebel T3i / Kiss X5, 1100D / Rebel T3 / Kiss X50, 550D / Rebel T2i / Kiss X4, 500D / Rebel T1i / Kiss X3, 1000D / Digital Rebel XS / Kiss F, 450D / Digital Rebel XSi / Kiss X2

## PowerShot models

- Canon PowerShot V10, ZOOM, G7 X Mark III, G5 X Mark II, SX70 HS

## Supported Sony models

- Sony RX0 II / DSC-RX0M2 (photo only, video capture is not supported on this body, see Additional notes)
- Sony RX1R III / DSC-RX1RM3
- Sony Alpha 1 / ILCE-1, Alpha 1 II / ILCE-1M2, Alpha 6700 / ILCE-6700, Alpha 7C / ILCE-7C, Alpha 7C II / ILCE-7CM2, Alpha 7CR / ILCE-7CR, Alpha 7 IV / ILCE-7M4, Alpha 7 V / ILCE-7M5, Alpha 7R IV / ILCE-7RM4, Alpha 7R IV A / ILCE-7RM4A, Alpha 7R V / ILCE-7RM5, Alpha 7S III / ILCE-7SM3, Alpha 9 II / ILCE-9M2, Alpha 9 III / ILCE-9M3
- ZV-E1, ZV-E10 II / ZV-E10M2, MPC-2610, PXW-Z200, PXW-Z300, PXW-Z380

## Supported GoPro models

- HERO11, HERO12, HERO13
- GoPro over Wi-Fi is Experimental. USB is the preferred path for event work.

## Android phones

- Android phones running the Xangle remote camera app on the same event Wi-Fi network.
- Use Android phones when a Wi-Fi camera is useful for lightweight photo or video capture. Test the exact phone, lens, and Wi-Fi network before the event starts.

## iPhone

iPhones run the Xangle Remote Camera app on the same event Wi-Fi network and support live view, photo, video, autofocus, lens selection, and exposure settings (ISO, shutter, white balance). The app requires iOS 17 or later and must stay in the foreground during an event.

- iPhone 12, 12 mini, 12 Pro, 12 Pro Max
- iPhone 13, 13 mini, 13 Pro, 13 Pro Max
- iPhone SE (3rd generation)
- iPhone 14, 14 Plus, 14 Pro, 14 Pro Max
- iPhone 15, 15 Plus, 15 Pro, 15 Pro Max
- iPhone 16, 16 Plus, 16 Pro, 16 Pro Max, 16e
- iPhone 17, 17 Pro, 17 Pro Max, iPhone Air
- Newer iPhones that ship after this list still work on iOS 17 or later; they appear under their hardware identifier until the model name is added.

## Webcams (Experimental)

- USB webcams on Windows computers and Raspberry Pi / Linux camera nodes.
- Webcam support is Experimental, but photo capture and video capture are usable today when the exact webcam and driver have been tested.

## Raspberry Pi (libcamera)

Raspberry Pi MIPI CSI cameras driven by Raspberry Pi's `libcamera` stack on a Raspberry Pi camera node. The supported sensor list mirrors what Raspberry Pi's own `libcamera` implementation recognizes.

- Official Raspberry Pi cameras: OV5647 (V1), IMX219 (V2), IMX708 (V3), IMX477 (HQ), IMX500 (AI), IMX296 (GS).
- Third-party sensors: IMX290, IMX327, IMX378, IMX519, OV9281.
- Autofocus controls are only available on sensors that have a focus lens, such as the IMX708 (Camera Module 3). Fixed-focus sensors expose the rest of the libcamera controls but hide AfMode.
- Test the exact sensor, Pi model, and libcamera build before event use. Behavior can vary with the sensor revision, the Pi's camera stack version, and the cable used.

## Feature support by camera type and connection

### Windows

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Main event-ready path for Canon rigs. |
| Sony USB cameras | USB | Yes | Yes | Yes | Yes | Yes | No | Test the exact body before the event. |
| GoPro HERO11-13 (USB) | USB | Yes | Yes | Yes | Yes | Yes | Yes | Preferred path for event work. |
| GoPro HERO11-13 (Wi-Fi, Experimental) | Wi-Fi | Yes | Yes | Yes | Yes | Yes | Yes | Experimental. Test on the real network before the event. |
| Android phones | Wi-Fi | Yes | Yes | Not yet | Yes | Yes | No | Use the Xangle remote camera app on the event Wi-Fi. |
| iPhone (iOS 17+) | - | No | No | No | No | No | No | Not supported on Windows. |
| USB webcams (Experimental) | USB | Yes | Yes | Yes | Basic controls | Yes | No | Experimental. Test the exact webcam and format. |

### Raspberry Pi

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Good for distributed rigs when Canon support is enabled on the Pi. |
| Raspberry Pi (libcamera) | MIPI CSI | Yes | Yes | Yes | Yes | Yes | Yes | Sensor list mirrors Raspberry Pi's libcamera support. Test the exact sensor and Pi model. |
| Sony USB cameras | - | No | No | No | No | No | No | Not wired yet. |
| GoPro HERO11-13 (USB) | USB | Not tested | Not tested | Not tested | Not tested | Not tested | Yes | Not tested yet on Raspberry Pi. |
| GoPro HERO11-13 (Wi-Fi, Experimental) | Wi-Fi | Not tested | Not tested | Not tested | Not tested | Not tested | Yes | Not tested yet on Raspberry Pi. |
| Android phones | Wi-Fi | Not tested | Not tested | Not tested | Not tested | Not tested | No | Not tested yet on Raspberry Pi. |
| iPhone (iOS 17+) | - | No | No | No | No | No | No | Not supported on Raspberry Pi. |
| USB webcams (Experimental) | USB | Not tested | Not tested | Not tested | Not tested | Not tested | No | Not tested yet on Raspberry Pi. |

### Mac

| Camera type | Connection | Photos | Video | Live view | Settings | Downloads | Storage | Operator note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Canon USB cameras | USB | Yes | Body-dependent | Yes | Yes | Yes | Yes | Supported on Mac. Test the exact body and tethering setup before event day. |
| Sony USB cameras | USB | Yes | Yes | Yes | Yes | Yes | No | Supported on Mac. Test the exact Sony body before the event. |
| GoPro HERO11-13 | USB / Wi-Fi | Yes | Yes | Yes | Yes | Yes | Yes | USB is preferred for event work. Wi-Fi path is Experimental and should be tested on the real network. |
| Android phones | - | No | No | No | No | No | No | Not supported for event capture. |
| iPhone (iOS 17+) | Wi-Fi | Yes | Yes | Yes | Yes | Yes | No | Supported on Mac. Keep the app in the foreground during capture. |
| USB webcams (Experimental) | USB | Yes | Yes | Yes | Basic controls | Yes | No | Experimental on Mac. Test the exact webcam and format before event use. |

## Additional notes

Model-specific limitations worth knowing before an event:

- Canon EOS R5 C: not supported.
- Sony RX0 II / DSC-RX0M2: video capture is not supported. The body can shoot and download photos, but recorded clips stay on the camera SD card and cannot be pulled back to Camera Server over USB. This is a limitation of the camera itself, not of Camera Server. For video, use a different supported body.


Supported cameras

- Take one synchronized picture with all cameras from Trigger; this single shot is what alignment and outputs build on.
- If timing looks off, re-check warmup and the sacrifice / flash slider before changing the rig.


Sync & timing

- Hold the trigger button to warm up the rig before firing.
- Ctrl-click the trigger to auto-focus every lens. You normally only need to do this once per setup.


Trigger basics

- On a boot-server setup, keep the boot subnet isolated with no router and no second DHCP server.
- Connect the computer's Ethernet only to the boot-server switch stack, and keep internet on Wi-Fi or a second NIC.


Boot server not responding

- Brand-new Pis default to SD-card boot. Boot once from a flashed card to set the EEPROM to try network boot first, then remove the card.
- Cardless clients must be Pi 4 or newer; network boot is not supported on Pi 3.


Cardless nodes won't register

- Standalone image: the complete XangleOS on a single microSD card, one card per Pi. This is required for older boards (Pi 3B / 3B+) and is recommended when capturing larger files such as video or burst sequences. Standalone Pis live on your normal routed LAN alongside your computer, router, and switches.
- Boot server image: turns one Pi into the central operating system for all of your Pis. Only the boot-server Pi needs a card; every other Pi boots from the network (PXE/NFS). This removes batch SD flashing, avoids corrupted-card issues, and makes system-wide updates instant. The boot server needs a Pi 4 or 5 with at least 4 GB of RAM, and cardless clients must be Pi 4 or newer, since network boot is not supported on Pi 3.


Choose your image

- The Pi and this computer must share a subnet. Each network adapter with a Broadcasting badge sends beacons to its subnet, and nodes there register automatically.
- After connecting, allow up to about 10 seconds (the beacon interval) for a node to receive a beacon and register, then click Refresh.
- If a node never appears, check the link lights on both switch ports and confirm the cable reaches the same switch. An adapter showing a 169.254.x.x address is connected but never got a DHCP lease.
- Use Find my Pis to actively probe the subnet for a live XangleOS agent when UDP broadcast is blocked by a switch or router. On a boot-server setup this probes the boot subnet and finds Pis even if beacons are blocked.


Confirm discovery

Boot-server setups only.

- A brand-new Pi defaults to SD-card boot order, so boot it once from a flashed card to configure its EEPROM to try network boot first.
- After that one-time boot, remove the card. The Pi will PXE-boot from the boot server automatically on every subsequent power-on.


First boot for cardless Pis

1. Download the desired image (.img.gz or .img) from xangleapps.com.
2. Install Rufus (free and portable, no installation required). balenaEtcher or the Raspberry Pi Imager also work.
3. Insert the card, then in Rufus pick it under Device, click SELECT, choose the image, leave the other settings at their defaults, and click START. This erases everything on the card.
4. Eject the card safely, insert it into the Pi, and power it on.


Flash a microSD card

- Confirm the Pi and this computer share a subnet, and that the adapter shows a Broadcasting badge.
- Check link lights on both switch ports and confirm the cable reaches the same switch.
- An adapter showing a 169.254.x.x address is connected but never got a DHCP lease.
- Use Find my Pis to actively probe the subnet when UDP broadcast is blocked.


Node never appears

- Camera Nodes carry remote capture adapters so cameras can sit far from the computer.
- Network Nodes is the inventory and host-operations view for every Pi the server can see.
- Devices covers connected browser stations (sharing, replay, kiosk) rather than capture hardware.


Camera, Network & Devices

- Standalone setup: one computer, one router, many switches, and many standalone Pis, all sharing the same normal LAN. This is the easiest layout to manage.
- Boot-server setup: one computer, many switches, one Pi boot server, and many cardless Pis on a dedicated, isolated Ethernet segment with no router and no other DHCP server on it. Keep internet on Wi-Fi or a second NIC, and connect the computer's Ethernet port only to the boot-server switch stack.


Plan the network

For rigs with 24 cameras or less, the preferred setup is USB-only on one computer. This keeps topology simple and works well when power and hub layout are controlled.

## When USB-only is the right choice

- Use this path for compact bullet-time and small scan rigs where all cameras can be cabled to one host reliably.
- Keep all capture cameras on wired USB. Avoid mixing test Wi-Fi cameras into the production rig.
- Use this mode when your trigger and transfer tests are consistently clean at full camera count.

## Hardware and wiring checklist

1. Use a stable Windows host with enough USB bandwidth for your camera count and media mode.
2. Use high-quality powered USB hubs. Do not rely on unpowered hubs for event rigs.
3. Distribute cameras across multiple hubs and ports instead of overloading one branch.
4. Use short, reliable USB cables and strain-relief them so they cannot be pulled during operation.
5. Label every cable and hub port to match physical camera position.

## Setup flow (USB-only)

1. Connect hubs first, then connect cameras in rig order.
2. Power cameras on in order and wait for full discovery in Cameras.
3. Run Re-number once all expected cameras are visible.
4. Manually adjust any slot mismatches from Set camera number.
5. Run one complete trigger and download cycle before alignment work.

## Stability practices before event day

- Do a full-duration soak test at production camera count, not a short bench check.
- After numbering and alignment validation, avoid moving hubs, cables, and USB port assignments.
- Keep one spare powered hub and known-good cable set on-site for fast recovery.
- If one camera branch becomes unstable, isolate that branch and retest trigger plus download before reopening to users.


24- cameras

For rigs above 24 cameras, use Raspberry Pi camera nodes to improve stability and throughput. Ethernet-distributed nodes are more reliable than pushing all cameras through one host USB stack.

XangleOS Raspberry Pi images (Standalone and Boot-server) can be downloaded from xangleapps.com.

## When to choose Raspberry Pi nodes

- Use Pi nodes when one computer starts to show USB saturation, unstable reconnects, or inconsistent trigger-to-download timing.
- Use Pi nodes when physical camera groups are far apart and easier to aggregate per zone, then uplink by Ethernet.
- Prefer wired Ethernet for event operation. Keep Wi-Fi for setup convenience only.

## Choose the deployment model

- Standalone image: each Pi uses its own microSD card. Best for smaller distributed rigs and straightforward field swaps.
- Boot-server image: one Pi hosts the boot environment and additional Pi clients boot over network with no SD cards. Best for large rigs that need centralized control and faster node replacement.

## Preparation checklist

1. Download the correct Pi image package from xangleapps.com.
2. Prepare quality power supplies for every Pi and powered USB hubs for camera groups.
3. Label each Pi, hub, Ethernet run, and camera branch before deployment.
4. Use a dedicated switch for camera-node traffic whenever possible.
5. Keep Camera Server and all Pi nodes on the same routed network segment during setup and validation.

## Standalone image workflow

1. Flash the Standalone image to one microSD per Pi.
2. Boot each Pi, connect Ethernet, then connect its assigned camera subset over USB.
3. Wait for nodes to appear in Camera Server Network Nodes, then verify each node camera count.
4. Power cameras on in rig order and run Re-number from the Cameras module once all expected cameras are present.
5. Run a full trigger and download test with all nodes online before event day.

## Boot-server workflow

1. Flash and boot the Boot-server Pi image on the designated host Pi.
2. Bring up client Pis on Ethernet with no SD card, then confirm they receive network boot from the host.
3. Connect cameras to each client Pi using powered hubs and stable cabling.
4. In Camera Server, confirm all nodes and expected camera totals before numbering.
5. After discovery stabilizes, run one full capture cycle to validate trigger, transfer, and consistency across all clients.

## Operational best practices

- Do not mix ad-hoc USB and node topology changes right before show time.
- Keep cabling and power topology fixed after alignment and numbering are validated.
- If a node drops, recover that branch first, then re-run a complete trigger and download validation pass.
- Keep one spare pre-imaged Pi and spare hub ready for rapid replacement.


24+ cameras

Large photogrammetry rigs (over 60 cameras).

1. Connect cameras in the correct order, then click the re-number action in the camera list.
2. Pre-align cameras toward the subject. Field method: use a plastic mannequin for repeatable setup.
3. Ctrl-click Trigger to auto-focus all lenses once. Textured clothes on the mannequin improve consistency.
4. Set camera layout to 3D.
5. Take one synchronized picture with all cameras.
6. Optional but recommended: from Library / Align, run RealityScan alignment and inspect camera detection in 3D right away so positioning can be reused later in processing.


3D scan

Small experiences (6 to 18 cameras).

1. Connect cameras in the correct order, then click the re-number action in the camera list.
2. Pre-align cameras to a center pole. Use a light stand with colored tape and the live-view grid for straight framing.
3. Ctrl-click the trigger button to auto-focus the lenses. You only need to do this once.
4. Set camera layout to Arc or 360, depending on your physical rig.
5. Place a person or object in the center of the frame, ideally wearing textured clothing, then take one synchronized picture with all cameras.
6. Open that dataset in Library, then go to Registration & Alignment.
7. Run registration with Cloud service, RealityScan or 2D markerless.
8. If the result is good, set that dataset as the reference from the dataset kebab menu in Library.
9. Configure Outputs and sharing for the deliverables guests will receive.


Bullet-time booth

| # | Question | Answer |
| --- | --- | --- |
| 4.1 | What camera models are compatible? | See the Supported Cameras page in this guide. |
| 4.2 | Can I mix camera models? | Yes. Settings and trigger delays will differ between models, and colour/brightness shifts may need post-correction. You cannot mix PiCam and other models on the same Pi. |
| 4.3 | Do I need SD cards in my cameras? | No in most cases, files transfer straight to the computer. Exceptions: video mode on Canon requires an SD card. |


4 — Camera

| # | Question | Answer |
| --- | --- | --- |
| 7.1 | What kind of computer is required? | Windows 10 or 11. For 12 cameras or fewer, a Surface Pro i7 works. For larger rigs, use a gaming laptop or desktop with a fast SSD and CPU. The software works on slower hardware but processing takes longer. |
| 7.2 | Do I need a GPU? | For fast alignment, an Nvidia GPU is a big bonus. It is also required to train splats using Postshot. |


7 — Computer

| # | Question | Answer |
| --- | --- | --- |
| 8.1 | Which wireless triggers work? | Pretty much any Bluetooth PowerPoint presenter or gamepad. You can also remap keys from Button Mapping. |


8 — Other gear

| # | Question | Answer |
| --- | --- | --- |
| 2.1 | How can I upgrade my license? | Monthly to yearly: upgrade within the first 10 days and the monthly payment is credited. Yearly: remaining time is credited toward the new license. Contract licenses can be upgraded any time. Downgrades are not available. |
| 2.2 | Can I use the software on two computers? | One computer at a time. Log out (top-right menu) before logging in elsewhere. If your machine crashes, the session token expires automatically after 24 hours, or we can reset it manually. |
| 2.3 | Can I split a 24-camera license into two 12-camera setups? | No. One license = one computer. You can add Raspberry Pi or Windows nodes to scale transfer speed, but everything runs under a single server. |
| 2.4 | Can I get a trial license? | Yes, fill out the form on the website. The trial is limited to 4 cameras for 7 days. |
| 2.5 | What are the trial limitations? | Full Pro features for evaluation only, not for production events. The daily trigger count is limited. |
| 2.6 | Can I use the software after my license expires? | No. A valid, active license is required at all times. |
| 2.7 | Single vs Contract license? | Single: 31 or 365 days, no auto-renewal. Contract: 12-month commitment with monthly billing, not cancellable mid-term. |
| 2.8 | How do I renew? | Single licenses do not auto-renew, you get a reminder two weeks before expiry. Purchase a new license using the same email address and it appears immediately in your account. |


2 — License & payments

| # | Question | Answer |
| --- | --- | --- |
| 6.1 | Why not plug every camera into one computer? | The bottleneck is the camera's slow USB transfer. Distributing cameras across Pis spreads that load, each Pi ships files back over Ethernet, which is far faster and more scalable than one USB bus. |
| 6.2 | How fast is the network? | Each Pi has Gigabit Ethernet. At scale, a 10 Gbps uplink between the switch and computer lets all Pis transfer concurrently. Our fastest rig: 44 Pis on a 48-port gigabit switch with a 10G uplink to the computer. |
| 6.3 | Boot-server + cardless, or standalone? | Standalone is simpler to start: flash a card and run. Boot-server is better long-term: one update point, no SD-card fleet to maintain (less corruption risk). |
| 6.4 | How do I flash a microSD card? | Download the image from xangleapps.com, write it with Rufus (free, portable), balenaEtcher, or Raspberry Pi Imager. See the Getting Started section for a full step-by-step. |
| 6.5 | How precise is triggering across hundreds of cameras? | The trigger signal reaches cameras within about 1 ms. Variation comes from camera shutter and processing latency, not the network. |
| 6.6 | Can I connect more than 4 cameras to one Pi? | Yes, but 4 on the Pi's 4 USB ports is the sweet spot. Beyond that, cameras contend for USB bandwidth. |
| 6.7 | Can I use GoPros with a Pi? | Yes, but through a powered USB hub, not directly into the Pi's USB ports. |
| 6.8 | Can I mix cardless and standalone Pis? | Yes. Both register the same way once they share a subnet with the server. |
| 6.9 | What cables should I use? | Cat6 handles gigabit Pi runs and 10G uplinks comfortably. |
| 6.10 | Can I power Pis over Ethernet (PoE)? | Some users do. We have not tested specific setups ourselves. Ensure the switch and PoE HATs can supply the required current. |
| 6.11 | Should I keep a backup boot server? | Yes. Keep it powered off and disconnected until needed, two live boot servers on the same network will fight over cardless Pis and break booting. |


6 — Network & nodes

| # | Question | Answer |
| --- | --- | --- |
| 3.1 | What is the best distance between cameras / subject? | It depends on the effect you want. Closer cameras = smoother result over a smaller arc. Wider spacing = stronger 3D effect but requires more space. Keep the subject close enough to preserve depth. |
| 3.2 | What lens or focal length should I use? | The kit 18–55 mm works great for most setups. The 24 mm pancake is popular for its compact look. In tight spaces, a 10–18 mm wide-angle helps. |
| 3.3 | Straight or curved bar? | Straight is preferred, the alignment module compensates the angle. Easier to set up and transport. Up to 12 cameras fit on a straight bar as long as they are close together. |


3 — Physical configuration

| # | Question | Answer |
| --- | --- | --- |
| 5.1 | Do I need Raspberry Pis? | No. All cameras can connect to one computer. Pis let you scale well past 24 cameras by distributing USB load across nodes. |
| 5.2 | Can I mix Pis and Windows clients? | Yes, but trigger timing differences may appear. |
| 5.3 | Can I mix PiCam and other cameras on the same Pi? | No. |
| 5.4 | USB hub vs Raspberry Pi architecture? | USB hub is simpler and requires less gear. Raspberry Pis scale better, each Pi pulls its cameras in parallel over Ethernet. See the benchmark page. |
| 5.5 | Which Pi models work? | 3B+, 4B, and 5. |
| 5.6 | Can I use a mini PC instead of a Pi? | Technically yes, but Pis are far easier to deploy at scale. A Windows node needs manual install, firewall config, and update management. A Pi only needs a flashed SD card. |


5 — Raspberry Pi

| # | Question | Answer |
| --- | --- | --- |
| 1.1 | Do I need an internet connection? | Only to validate your license, once at launch, and once every 24 hours. After that you can go offline. The server runs locally on your machine. |
| 1.2 | How often are new versions released? | At least one version every two months. We actively add features and improve performance. |
| 1.3 | Can I use a second monitor with the Basic version? | Yes. Basic and higher can open replay or sharing tiles on a connected second monitor from the dashboard monitor icon. Pro is required for browser pages and stations on separate devices. |
| 1.4 | Can I remove the Xangle logo? | With a Pro license you can replace the logo and app title shown in the header. Other branded elements (Windows taskbar title, footer credits) cannot be altered. Injecting substitute values in those areas violates the terms and conditions. |


1 — Software

Use this page when preparing a fresh machine or updating before an event. Xangle app installers can be downloaded from xangleapps.com.

## Fresh install

1. Download the latest Camera Server installer from xangleapps.com on the target machine.
2. Close any running Xangle apps before launching the installer.
3. Install with standard options unless your deployment process requires a custom location.
4. Launch Camera Server once after install so required local folders and defaults are created.
5. Open Getting started and run a full camera discovery and trigger test before event day.

## Update flow

1. Export or screenshot any settings you need to preserve before updating.
2. Close Camera Server and related helper apps.
3. Run the new installer from xangleapps.com and complete the upgrade.
4. Reopen Camera Server, verify license/session status, then reconnect cameras.
5. Run one full capture, download, and output test to validate the update on your real rig.

## Operator notes

- Do not update on show day unless you need a specific fix.
- For production rigs, keep a known-good installer package available so you can roll back quickly if needed.
- When you update one station in a multi-station setup, update the others to keep behavior consistent.


Software installation / update

| Term | Meaning |
| --- | --- |
| Capture | One firing of all cameras at the same moment, producing a single dataset. |
| Trigger | The action (or button) that starts a capture. |
| Camera | A connected camera body, Canon, Sony, GoPro, phone, or USB webcam. Each one is assigned a number. |
| Camera number | The position assigned to a camera. It controls ordering and how its frames are named. |
| Camera lane | The per-camera strip in the capture view that shows one camera's latest frame, number, and connection status. |
| Frame | A single image from one camera within a dataset. |
| Frames | The grid inspector page for reviewing individual frames across datasets and iterations. |
| Liveview | A full-screen live composite from the connected cameras. |
| Quickview | Fast single-image review of the latest capture or a chosen dataset. |
| Camera node | An adapter host (often a Raspberry Pi) that connects one or more cameras to the server. |
| Network node | A Raspberry Pi or Windows host running node services on the network. |


Capture & cameras

| Term | Meaning |
| --- | --- |
| Camera registration | Computing per-camera transforms from a capture using Cloud, RealityScan, or 2D markerless. Cloud and RealityScan recover 3D poses. 2D markerless computes 2D transforms for fixed-arc rigs. |
| Image alignment | Applying the camera registration to crop and warp images so subjects stay centered and stable across cameras. |
| Camera registration tokens | Monthly cloud usage credits for camera registration. One uploaded image costs one token, and tokens are consumed only on successful cloud completion. |
| Gaussian splat | A 3D scene trained from a dataset's aligned frames. Often shortened to "splat." |
| Queue | The background processing list, alignment, splats, and video renders run here without blocking the operator. |
| Output | A render produced from a dataset: video, image, or export, configured on the Output page. |


Processing & 3D

| Term | Meaning |
| --- | --- |
| Project | A real-world shoot or job (for example, one photo day or one event). You group its captures under a single project folder. |
| Project folder | The collection root on disk that holds many dataset folders, typically a NAS or drive folder you name for the project. Set it in Storage / Dataset folder settings. |
| Dataset | A single capture: all the camera frames produced by one trigger, stored together with their metadata (dataset.json). |
| Dataset folder | The folder on disk for one dataset. It contains that capture's frames and its dataset.json metadata file. |
| Iteration | Multiple trigger firings within a single capture, producing several frames per camera in one dataset. A 10-shot burst is 10 iterations. Step between iterations with PgUp / PgDn in the inspector. |
| Dataset reference | A dataset promoted to act as the active reference for processing tasks (image alignment, chromakey, mosaic, sequencer, and others), so its registration data can be reused across later captures. |
| Working folder | The app's own home directory (for example, ~/xangle/cameraserver). It stores configuration and app state, not your captures. Different from the project folder. |


Projects & datasets

| Term | Meaning |
| --- | --- |
| Share | Delivering a capture to a guest, by QR code, email, or direct download. |
| Kiosk | A locked-down sharing-station mode for guest self-service. |
| Devices | The connected guest browsers you can navigate, lock, or disconnect from the server. |


Sharing & delivery

| Term | Meaning |
| --- | --- |
| Dashboard | Your composable operator workspace, built from movable module tiles. |
| Module / Tile | A movable panel on the dashboard that exposes one page or function. |
| Quick Nav | The Ctrl+1–9 shortcuts that jump straight to your chosen pages. |
| Naming | The rules that decide how captured files and folders are named. Configured on the Naming page. |


Workspace & UI

Latest walkthrough videos for Camera Server. This playlist refreshes whenever you open the page.

```youtube-playlist
PLE_Si0u2I2JadNFlcAcRfjhXV3wEhfyyB
```


Videos playlist

These features from XCS16 are not implemented:

- Picam & Arducam support
- Older Sony cameras support (Sony doesn't support older models in their current official SDK)


What's missing?

The biggest reasons to move to the new version:

- Markerless camera alignment, with no calibration bar required.
- Automated Gaussian-splat processing.
- Offline QR code sharing.
- App customization: your logo, your colors.
- New modern Android implementation, now with WiFi support.
- Backstage camera that captures the behind-the-scenes, from the start of the countdown to after the files are ready.
- Multiple outputs from a single capture, for example a 16:9 video with an overlay and a 9:16 poster at the same time.
- No email or cloud setup. Sharing and delivery work out of the box, with no SMTP or cloud service to configure.
- Modular dashboard you compose from movable modules.
- Smarter triggering, with mirror lockup folded into warmup plus half-press for more accurate sync.
- Much faster overall.


Highlights of the new version

We're happy to present a fresh new version of our app, Xangle Camera Server. From now on, we'll refer to the older app as XCS16 (2016 is the year we started coding the previous version). Important to know:

- If you need to shoot in RAW, select RAW+JPG. We no longer extract JPGs from RAW files because those JPGs do not carry the EXIF data required for proper camera alignment. You can still use RAW only if you want to go fast and only need the files themselves.
- Assets / Collections is now simply Outputs. You can add as many outputs as you want from a single result. For example, you can export a 16:9 video with an overlay as well as a 9:16 poster.
- You no longer need to configure any SMTP or cloud service. We handle everything for you, so the app is ready to use right away.
- Camera calibration now lives in Registration & Alignment (from the Library) and no longer requires a calibration bar or calibration panel. Create one clean reference dataset for the rig, analyze it in Library, and promote it as the active reference. Future captures can reuse that reference until a camera is bumped, re-aimed, or moved, then you capture a fresh reference and set it as the new active one.
- Mirror lockup is now part of warmup. Hold the trigger button and the app will handle both MLU and half-press for more accurate triggering.
- Sacrifice mode has improved significantly. We have seen slightly better results by shifting the flash signal down by 1 or 2 ms, so it is worth trying the slider.
