## SSD write bottleneck causing random processing slowdowns

In rare cases, dataset processing speeds in Xangle Camera Server can become random, inconsistent, and progressively worse over time. Although this can look like a software problem, an SSD that is becoming unstable during write operations may be the root cause.

Typical symptoms include:

- unpredictable processing performance
- gradual degradation over time
- 100% disk activity with very low throughput
- no obvious heavy process visible in Task Manager

### Quick SSD check

To determine whether the SSD is the bottleneck rather than Xangle Camera Server, duplicate a large file, preferably 5 GB or more, onto the same drive. If the copy speed is abnormally slow, or disk activity remains saturated after the copy completes, the SSD is likely responsible.

### Recommended actions

- Run the SSD manufacturer's diagnostics, including SMART checks.
- Install any available SSD firmware updates.
- Keep at least 15 to 20% free space on the drive.
- Update the NVMe or storage controller drivers.
- Perform a clean Windows reinstall if the system shows broader signs of instability.
- Replace the SSD if the problem persists after the other checks.

Back up important datasets before running diagnostics or replacing the drive.

## Norton 360 and distributed architectures

Norton 360 is known to cause serious problems, especially in distributed architectures that use Raspberry Pis or other networked nodes. Its behavior can change depending on the throttling settings applied from Xangle, which can make connection, transfer, or processing issues appear inconsistent.

If you experience unexplained problems with a distributed setup, temporarily disable Norton 360 and test the workflow again. If the issue disappears, add the Xangle application, its working directory, and the relevant node communication traffic to the appropriate Norton exclusions instead of re-enabling unrestricted scanning during an event.

## Do not use cloud-sync folders as working directories

Never place the Xangle working directory, including app settings and datasets, inside a cloud-sync folder such as OneDrive or Google Drive. Xangle continuously reads and writes settings, capture files, thumbnails, processing outputs, and other dataset files. Cloud-sync clients can lock files while synchronizing them, upload incomplete files, restore older versions, or change availability while Xangle is still using them.

These conflicts can cause missing files, slow or inconsistent processing, corrupted datasets, sync conflicts, and unreliable application behavior. Keep the active working directory on a local SSD or another directly attached drive with sufficient free space. Configure cloud storage as a separate backup or export destination after files are closed, rather than as the live location for app settings or datasets.


Known issues

This page records a 4D Gaussian Splatting pipeline built around a synchronized multi-camera capture. It is an experimental post-processing workflow rather than a built-in Camera Server process task. Tool versions, scripts, and model-training settings change quickly, so verify each external project's current instructions before starting.

## Capture and organize the source dataset

1. Use Camera Server Camera control to connect, synchronize, and trigger the cameras.
2. Capture a complete image sequence with consistent exposure, focus, and lighting.
3. Keep the original dataset intact and make a working copy for frame extraction and reconstruction.
4. Confirm that camera numbering, timestamps, filenames, and audio or trigger references are preserved.

The quality of the temporal result depends on consistent capture timing and camera registration. Fix missing or misnumbered source files before moving to training.

## Example pipeline

The legacy workflow used these stages:

1. **Camera control and trigger:** Xangle Camera Server.
2. **Sound synchronization and frame extraction:** [PeakAlign](https://github.com/xanglestudio/PeakAlign).
3. **Camera registration:** RealityScan or a compatible RealityCapture workflow.
4. **Sparse point-cloud generation per frame:** RealityScan driven by a custom script.
5. **Gaussian Splat training:** Postshot using a custom script and an MCMC-based training workflow.
6. **Floater removal:** [PointNuker](https://github.com/Dymensium/PointNuker).
7. **Compositing and review:** After Effects with a Gaussian Splat importer and a flicker-reduction tool where needed.

This list is a pipeline map, not a claim that each tool is required or supported by Camera Server. Keep the intermediate files for every stage so a failed training run does not require a new capture.

## Camera registration and frame preparation

Register the cameras using a clean reference dataset and the current RealityScan or RealityCapture workflow. Review the solved camera positions before generating per-frame point clouds.

Use PeakAlign or an equivalent tool to relate the sound or trigger event to the extracted image frames. Check the offset on a short test sequence before extracting the complete production range. Keep the source audio, frame numbering, and offset values together in the working project.

## Training and cleanup

Train the splat from the registered per-frame data using settings appropriate for the available GPU and the intended playback quality. Training time and memory use vary with camera count, frame count, resolution, and scene complexity.

After training:

- Review the motion for temporal drift and flicker.
- Remove floaters conservatively so valid moving details are not lost.
- Check the beginning, middle, and end of the sequence, not only a representative frame.
- Export an intermediate preview before committing to a long final render.

## Current limitations

The original article was marked as a work in progress. There is no universal Camera Server button that completes this pipeline. Custom scripts, RealityScan, Postshot, PointNuker, and compositing tools remain external dependencies with their own licensing, hardware, and version requirements.

Document the Camera Server build, camera layout, frame rate, audio offset, registration project, scripts, training settings, and cleanup decisions with each production. That record is more useful than copying a fixed benchmark from an older rig.


4D Gaussian Splatting processing

Use this workflow when you need a textured OBJ from a RAW photo set captured with Xangle Camera Server. Camera Server handles the capture and dataset organization; the reconstruction and export happen in an external photogrammetry application such as RealityCapture or RealityScan.

## Prepare the image set

1. Import the RAW files into Lightroom Classic, Capture One, or another RAW processor.
2. Apply consistent adjustments across the complete set:
   - Enable lens correction when appropriate.
   - Set one consistent white balance.
   - Adjust exposure only when necessary.
   - Remove chromatic aberration.
   - Avoid aggressive edits that differ from camera to camera.
3. Synchronize the adjustments across all images.
4. Export full-resolution JPEGs in sRGB. Use PNG only when the downstream workflow requires it. Keep the original dimensions and choose a quality setting that preserves the detail needed for reconstruction.
5. Place the exported images in a dedicated working folder. Keep the RAW originals and processed exports separate.

For a dataset captured in Camera Server, use the completed dataset folder as the source and make a separate post-processing export. Do not edit or rename the original capture files while reconstruction is in progress.

## Create the photogrammetry project

1. Open RealityCapture or RealityScan.
2. Create a new project and save it immediately in a working folder alongside, or beside, the processed image folder.
3. Add the exported images through the application's current image-import workflow.
4. Wait until all images are loaded and confirm that the expected camera count and image set are present.

Menu names vary by application version. Use the current equivalent of **Add Images**, **Align Images**, **Reconstruction**, **Texture**, and **Export Model** rather than relying on an old menu path.

## Align the cameras

1. Run image alignment.
2. Inspect the estimated camera positions in the 3D view.
3. Confirm that the sparse point cloud covers the subject and that the cameras form the expected rig arrangement.
4. If cameras fail to align, check for missing files, blurred frames, inconsistent exposure, reflections, or insufficient overlap. Remove only clearly unusable images and run alignment again.

Do not continue to a detailed reconstruction until the alignment is complete enough for the subject and the camera arrangement you need.

## Build and clean the mesh

1. Choose a reconstruction detail level that fits the available GPU memory and the final use of the model.
2. Generate the mesh.
3. Inspect it for holes, missing areas, floating geometry, floor or background surfaces, and other reconstruction artifacts.
4. Use the selection tools in the 3D view to remove unwanted geometry.
5. Simplify the mesh only when the target application needs a lower polygon count. Keep a high-detail project or export available for later reference.

A model intended for animation, clothing simulation, or real-time viewing usually needs a lighter, cleaner mesh than a model intended for archival geometry.

## Generate textures

1. Bake a texture only when the downstream workflow needs surface color or visual reference.
2. Choose a texture resolution and texture count that fit the GPU and the target application.
3. Generate the texture and inspect seams, missing areas, and color consistency.

Large textures increase memory use and export size. Use the highest resolution that the final workflow can actually display or edit.

## Export the OBJ

1. Use the current model-export workflow and choose Wavefront OBJ.
2. Export the mesh and texture or material files when textures were generated.
3. Save the export with its `.obj`, `.mtl`, and texture files together.
4. Preserve the project file and source images so the model can be rebuilt if settings or cleanup need to change.

## Verify the export

Open the OBJ in Blender, Cinema 4D, or the target 3D application and check:

- The mesh opens without missing parts.
- Textures and materials are found and mapped correctly.
- The orientation and scale are appropriate.
- Unwanted background geometry has been removed.
- The polygon count is practical for the next stage.

If the model must match real-world dimensions, define scale in the photogrammetry project using a known measurement before export. Record the measurement and units with the project.


Build an OBJ from RAW files in RealityCapture

- 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

This example shows how a full-body scan captured with a synchronized Xangle camera rig can become an animated character with simulated clothing. Camera Server produces the synchronized image dataset; Cinema 4D, Rokoko, AccuRig, iClone, Marvelous Designer, and the final renderer handle the rest of the workflow.

The exact camera count, scan rig, software versions, and menu names in the original example are historical. Use the rig and software available for the current production.

## Workflow overview

1. Capture a full-body scan with Camera Server.
2. Convert the source images and reconstruct an OBJ in RealityCapture or RealityScan.
3. Clean and scale the mesh in Cinema 4D or another 3D package.
4. Record motion with Rokoko or another motion-capture system.
5. Rig the mesh with AccuRig or an equivalent tool.
6. Retarget and clean the animation in iClone, Cinema 4D, or Blender.
7. Extract a garment from a second scan if needed.
8. Simulate the garment in Marvelous Designer or CLO3D.
9. Apply materials and lighting.
10. Composite and render the final animation.

## 1. Capture and reconstruct the body

Capture the subject with consistent lighting, exposure, focus, and pose. Keep the Camera Server dataset unchanged and create a working copy for RAW conversion and reconstruction.

Convert the source images to consistently processed JPEGs with Lightroom, Capture One, or an equivalent tool. Align the images in RealityCapture or RealityScan, generate a mesh, clean the background geometry, and export an OBJ with the required textures. See [Build an OBJ from RAW files in RealityCapture](/wayfinder/post-processing/building-obj-from-raw-files-realitycapture) for the detailed reconstruction path.

## 2. Clean the mesh in Cinema 4D

1. Import the OBJ and confirm its orientation, scale, materials, and texture paths.
2. Remove floor, background, and reconstruction artifacts.
3. Close holes and repair open edges that would interfere with rigging or cloth collision.
4. Retopologize when the scan topology is unsuitable for deformation.
5. Reduce the polygon count only as much as the animation and render require.
6. Set a meaningful real-world scale and place the model in a predictable scene orientation.

Keep a high-detail scan separate from the animation-ready version so later changes do not destroy the source geometry.

## 3. Record motion

1. Put on and calibrate the motion-capture suit or use another tracked motion source.
2. Record a short test performance first.
3. Review the skeleton and timing before recording the full movement.
4. Export the motion as FBX or BVH, depending on the target application.

The motion file and the character mesh must use compatible coordinate systems and frame rates. Write those settings down with the project.

## 4. Rig the avatar

1. Import the cleaned mesh into AccuRig or the rigging tool used by the production.
2. Place the joint markers on the anatomical landmarks.
3. Review the generated skeleton and skin weights.
4. Correct problem areas around shoulders, elbows, knees, hands, and hips.
5. Export a rigged FBX with a standard humanoid skeleton.

Test the rig with a simple pose before importing a long motion recording.

## 5. Retarget and clean the animation

Import the rigged character and motion file into iClone, Cinema 4D, Blender, or the chosen animation package. Retarget the motion and inspect:

- Foot sliding and contact
- Jitter in the hands or head
- Arm and body intersections
- Unnatural joint rotations
- Loops and transitions

Smooth or correct the animation, then export a cleaned version for clothing simulation.

## 6. Extract and simulate clothing

For a garment based on a second scan:

1. Import the scan of the subject wearing the garment.
2. Isolate the garment geometry.
3. Split it into a separate object.
4. Clean, repair, and simplify the garment mesh as needed.
5. Export it in the format required by Marvelous Designer or CLO3D.
6. Import the animated character and garment.
7. Match scale, orientation, and starting pose.
8. Set cloth weight, stiffness, collision, and simulation settings.
9. Run a short simulation and fix collisions before simulating the complete animation.

A clean, correctly scaled avatar and garment reduce simulation failures. Keep the original scan available for reference rather than using it directly as the simulation mesh.

## 7. Materials, lighting, and render

Bring the character and garment into Cinema 4D or the chosen render package. Apply scan textures and materials appropriate to the final look. Configure lighting, camera motion, and render settings for the intended output.

Export a short preview first. Review animation, cloth behavior, texture seams, and flicker before rendering the complete sequence. Use After Effects, DaVinci Resolve, or another compositor for grading and final assembly when needed.


Cinema 4D avatar workflow

Use this workflow to turn a photogrammetry capture into a correctly scaled OBJ avatar for Marvelous Designer or CLO3D. Camera Server supplies the synchronized image dataset. RealityCapture or RealityScan creates the mesh, and Blender is an optional cleanup and scale-check stage.

The source guide referred to a specific historical studio camera count and old menu paths. The important requirements are a clean, well-overlapped image set and a known real-world measurement, not a fixed camera count.

## Prepare the scan

1. Capture the subject in a simple pose with the arms slightly away from the body.
2. Keep lighting, exposure, focus, and subject position consistent across the dataset.
3. Export a working copy of the Camera Server dataset.
4. Convert RAW images to consistently processed JPEGs with Lightroom, Capture One, or another RAW processor.

Keep the original RAW files and the processed exports separate. Do not overwrite the captured dataset while preparing the photogrammetry input.

## Reconstruct the avatar

1. Open RealityCapture or RealityScan and create a project.
2. Add the processed image set.
3. Align the images and review the camera positions and sparse point cloud.
4. Build a mesh at a detail level appropriate for cleanup and clothing simulation.
5. Remove the floor, background, noise, and other unwanted geometry.
6. Simplify the mesh to a practical polygon count for the target application. The right count depends on the subject and simulation needs; do not treat an old fixed triangle range as universal.
7. Generate a texture only if it is useful as a visual reference. A texture is optional for a base avatar used primarily for garment fitting.

## Set real-world scale

Scale is essential because CLO3D and Marvelous Designer use real-world garment dimensions.

### Scale in RealityCapture or RealityScan

1. Complete the reconstruction and open the scale or ground-plane workflow in the current application.
2. Place control points on two locations with a known distance, such as the top of the head and the floor, or two measured body landmarks.
3. Enter the measured distance and its units.
4. Apply the scale and transformation.
5. Record the measurement and units with the project.

Use measurements taken from the subject or capture setup. A guessed height can produce a visually plausible model that still causes incorrect garment dimensions.

### Check or scale in Blender

If the photogrammetry project was not scaled:

1. Import the OBJ into Blender.
2. Open the Sidebar with `N` and use the Measure tool or a known reference object.
3. Scale the model until its dimensions match the recorded measurements.
4. Apply the scale with `Ctrl+A` and **Apply Scale**.
5. Set the origin to the geometry and verify the forward and up axes expected by the target application.
6. Export a new Wavefront OBJ with units and scale preserved.

The exact axis conversion depends on the target software and export version. Test the OBJ with a copy of the project before committing to a production workflow.

## Export the avatar

Export the cleaned, scaled mesh as Wavefront OBJ. Include the material and texture files only when they are needed for the intended use. Keep the `.obj`, `.mtl`, and texture files together in one folder.

Before import, verify:

- The mesh is at the intended centimeter scale.
- The pose is suitable for garment fitting.
- The origin and axes are predictable.
- There is no unwanted floor or background geometry.
- The polygon count is practical for simulation.

## Import into CLO3D or Marvelous Designer

Use the current application workflow to add the OBJ as an avatar or background OBJ, depending on whether garments must collide with it or only be aligned to it. Confirm the imported height and a second known measurement before creating patterns.

Use the avatar for:

- Garment draping and fit checks
- Pattern alignment
- Pose reference
- Custom mannequins

Run a short garment simulation first. Check collisions around the shoulders, arms, hips, and feet before increasing particle distance or simulating a longer animation.

## Practical scan tips

- Use a simple pose with a small gap between the arms and torso.
- Measure height, shoulder width, and another useful body dimension before reconstruction.
- Keep the scan texture separate from the simulation mesh when performance matters.
- Save the scale measurement, export settings, and software versions with the OBJ.
- If the avatar appears at the wrong size, fix units and scale before adjusting garment patterns.


Create custom avatars for Marvelous Designer and CLO3D

A factory reset returns the app to its shipped defaults. Choose the least destructive method that matches the problem. A reset can remove settings, datasets, generated assets, queue history, and other local files, so keep a backup before continuing.

These instructions apply to both **Virtual.ink** and **Xangle Camera Server**. Replace `<app>` below with `virtualink` or `cameraserver`.

## Method 1: Reset from the app

Use this method when the app launches and you can open **Troubleshooting** from the app menu.

1. Open **Troubleshooting**.
2. Choose **Reset all settings** to delete saved JSON settings in the active working folder while keeping datasets and assets.
3. Choose **Full wipe** only when you also want to remove the local datasets and asset files.
4. Confirm the action and restart the app if it does not reload automatically.

The reset restores the current shipped defaults. It does not delete files in an external backup destination. When the default working folder is active, the reset also removes its `locations.json`; when a custom working folder is active, the global `locations.json` remains in the default app root.

## Method 2: Create a new working folder

Use this method when you want a clean workspace but want to preserve the existing workspace for reference.

1. Open the app's working-folder or location settings.
2. Add or select a new folder as the active working folder.
3. Restart the app when prompted.

A new working folder is scaffolded with `config` and `datasets` subfolders. The app then reads settings from the new folder instead of the previous one. The old folder remains on disk, so it can be restored later by selecting it again.

Working-folder choices are recorded in the app's global locations file:

- Virtual.ink: `%USERPROFILE%\\xangle\\virtualink\\locations.json`
- Xangle Camera Server: `%USERPROFILE%\\xangle\\cameraserver\\locations.json`

The active folder can also be a custom path outside these default roots. The `locations.json` file stays in the default app root even when a custom working folder is active.

## Method 3: Rename the working folder in Windows Explorer

Use this method when the app does not launch or its settings UI is unavailable. Close the app completely first.

1. Close Virtual.ink or Xangle Camera Server.
2. Open the default app folder:
   - Virtual.ink: `%USERPROFILE%\\xangle\\virtualink`
   - Xangle Camera Server: `%USERPROFILE%\\xangle\\cameraserver`
3. Rename the folder to a backup name, such as `virtualink_backup` or `cameraserver_backup`.
4. Launch the app again.

The app creates a new default folder with a `config` directory and a `datasets` directory. Keep the renamed folder until you have confirmed that the app works and that you no longer need its settings or files.

If a custom working folder is active, use the path shown in the app's location settings instead of the default path. Renaming only the default root will not reset that custom folder.

## What is and is not reset

The working folder contains the active `config` and `datasets` data. Depending on the app and modules in use, it can also contain `assets`, `archives`, and `backup` directories.

- **Reset all settings** removes JSON settings files from the active working folder and preserves datasets and assets.
- **Full wipe** removes settings, datasets, and local asset contents.
- Renaming a working folder preserves everything in that backup folder until you delete it.
- `locations.json` is stored in the default app root and tracks known working folders and the active custom folder. If a custom working folder is active, reset its location list separately by removing the relevant entries from this file; if the default working folder is active, **Reset all settings** and **Full wipe** already remove the file.

Do not delete the default app folder while the app is running. If the app still does not start after a reset, keep the renamed backup and contact support with the application logs.


Factory reset

## Multiple flashes out of sync

- Use only one wireless trigger for all of your flashes. Multiple triggers can introduce timing differences between units.
- Some lower-end flashes cannot synchronize reliably. They may work when the subject is stationary, but action shots can produce double exposures when the subject moves. Avoid unreliable units such as the Godox MS300 for this type of setup.
- Wireless range can be a problem. If distance or interference is affecting synchronization, try using audio cables as a wired alternative.

## Flashes firing for no reason

- Check whether someone is accidentally triggering the flashes by taking photos with a smartphone. This can happen in busy environments.
- Change the channel on all flashes and on the remote trigger. A different channel can help avoid interference from nearby electronic devices.
- Make sure the cameras' built-in pop-up flashes are disabled.
- Deactivate or cover the infrared sensor on the flashes if it is responding to nearby infrared signals.
- Check the electrical system, including power connections, extension cables, and circuit stability.


Flash

Flickering is a change in brightness or color between consecutive cameras or frames. It can come from the light source, camera exposure behavior, optics, triggering, or post-processing. Diagnose the physical capture first, then use software correction only for residual variation.

## Common causes

- Fluorescent lights and other mains-powered sources that pulse with the electrical supply.
- LED or other constant lights using a PWM dimmer or a refresh rate that interacts with the camera shutter.
- Shutter-speed differences between cameras, especially in older or heavily used bodies.
- Sticky or slow aperture blades.
- Dust, fingerprints, or smudges on either side of a lens element.
- Flare from a light aimed toward the camera or entering the lens at an angle.
- Flash duration that is too short, inconsistent, or not synchronized across the rig.
- Exposure, ISO, white balance, or lighting settings that are not consistent across cameras.

## Diagnose the source

1. Capture a short test sequence with the same Camera Server trigger path and settings used for the event.
2. Compare brightness across cameras and across consecutive frames before processing or grading.
3. Identify whether the change follows a camera, a lens, a light, or a position in the rig.
4. Repeat the test with one variable changed at a time: light source, shutter speed, aperture, lens, or flash power.
5. Use an LED timer or another controlled reference when you need to distinguish trigger timing from exposure or lighting variation. See [Measure trigger synchronization with an LED timer](/wayfinder/tools/measuring-trigger-sync-led-timer).

If one camera is consistently brighter or darker, swap its lens or camera position with a known-good unit. If the problem follows the camera, inspect or service the camera. If it follows the lens, inspect the optics and aperture mechanism.

## Prefer a stable light source

For multi-camera or bullet-time capture, use a light source that remains stable throughout the exposure and across the complete capture sequence.

- Avoid fluorescent or visibly pulsing lights.
- Disable PWM dimming when the fixture supports a true constant-output mode, or test the fixture at the selected dimming level.
- Keep all cameras at the same white balance and exposure settings.
- Block stray light and avoid pointing bright fixtures directly into lenses.
- Test the complete lighting setup at the actual frame rate, shutter speed, and capture duration.

A light that looks steady to the eye can still vary enough to produce visible frame-to-frame changes. Check the captured images rather than relying on visual inspection of the room.

## When using flashes or strobes

Flash often produces more consistent illumination than ambient or dimmed continuous light because the flash pulse, rather than the camera shutter timing alone, freezes the subject's illumination.

- Use one reliable trigger path for all flash units.
- Confirm that every flash fires on every test capture and that wireless interference or range is not introducing missed pulses.
- Choose a flash duration long enough to cover the exposure and the timing spread of the rig. A very short pulse can make cameras with small timing differences record different brightness.
- Start with a conventional shutter setting such as 1/60 s when the camera and flash system support it, then verify exposure and motion blur on the actual rig. The correct value depends on the camera, flash, sync method, and ambient light.
- Test lower flash-power settings carefully. Some high-power strobes shorten their flash duration when power is reduced, which can reveal timing differences.
- Keep ambient light low and stable if the flash is intended to be the primary exposure source.

Do not assume that a flash firing sound proves that the light covered every camera exposure. Review the captured frames and repeat the test at the intended power level.

## When using constant light

With continuous light, the camera shutter is part of the timing system. Very fast shutter speeds can expose differences between camera bodies, especially older shutters, and can interact with LED refresh or PWM behavior.

- Start with a shutter speed that the complete camera set can achieve consistently, then increase it only if motion blur requires it.
- If flickering increases as the shutter gets faster, test a slower shutter and a brighter, stable light source.
- Keep aperture and ISO consistent, and confirm that every camera reaches the requested aperture.
- Check that the selected shutter speed is compatible with the light's refresh behavior and the local electrical frequency.

A slower shutter can reduce brightness variation but may increase motion blur. Choose the setting from a test sequence, not from a fixed value copied from another camera model or rig.

## Inspect lenses and camera hardware

- Clean both sides of every lens carefully and inspect for fingerprints, haze, or flare.
- Check the aperture at the selected setting. A sticky or slow diaphragm can leave one frame brighter than the next.
- Test suspect lenses at both wide and narrow apertures. A problem that becomes more visible at a narrow aperture points toward the aperture mechanism.
- Compare older cameras with a known-good body using the same lens and light.
- Replace or service equipment that produces repeatable brightness changes after the settings and light source have been ruled out.

## Correct residual flicker in post-processing

After the physical cause is addressed, a deflicker tool in Premiere Pro, After Effects, DaVinci Resolve, or another editor can reduce small remaining variations. Apply it to a copy of the processed media and check that it does not soften motion, distort edges, or remove intentional lighting changes.

Post-processing cannot recover a frame that missed the flash, contains motion blur from an incorrect shutter, or has a hardware exposure failure. Keep the original captures and document any correction applied to the final output.


Avoid flickering

- 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

Use a high-frequency LED timer to estimate the relative trigger timing of cameras in a multi-camera rig. Camera Server triggers the cameras; the timer provides a visible time reference that can be read from each captured image.

This is a measurement tool, not a Camera Server feature or a replacement for camera-node diagnostics. It measures relative timing in the images and does not by itself prove that every camera exposes at exactly the same instant.

## Why use an LED timer?

The timing differences in a synchronized rig can be shorter than one millisecond. Ordinary clocks and displays that show milliseconds often refresh at only 30 or 60 Hz, so their visible state is not precise enough for this test.

The custom timer used in the original guide has three rows of ten LEDs. The rows can be configured from 1 Hz to 10 kHz, with frequency and duty cycle adjusted using the controls below the display.

At a 1 kHz setting:

- The first row advances every 1 ms.
- The second row advances every 10 ms.
- The third row advances every 100 ms.

The timer can therefore encode a relative timestamp across the three rows when the cameras photograph it.

![LED timer showing frequency and duty-cycle controls](https://public.xangle3.com/doc/screenshots/2026-07-14/trigger-sync-timer-reading.png)

## Prepare the capture

1. Place the LED timer where every camera can see the same display and LED rows.
2. Make sure the timer is stable, bright enough to appear in every image, and not clipped by the lens framing.
3. Choose a timer frequency appropriate to the shutter speed and precision you need. Start with 1 kHz for a one-millisecond first-row increment.
4. Set each camera to the same exposure, aperture, ISO, focus, and image format used for the test.
5. Use an exposure no longer than one first-row increment. At 1 kHz, start around 1/1000 s and confirm the result in a test image. A longer exposure can illuminate several adjacent LEDs and make the column difficult to read.
6. Adjust ISO and aperture so the illuminated LED can be distinguished without losing the row or column information.
7. Trigger the cameras from Camera Server using the same trigger path and warmup configuration used in the rig.
8. Capture enough repeated test datasets to distinguish a repeatable offset from a single missed or poorly exposed frame.

Do not change exposure, timer frequency, or trigger settings halfway through a comparison set. Record the values with the dataset.

![LED timer displaying a three-row timing reference](https://public.xangle3.com/doc/screenshots/2026-07-14/trigger-sync-timer-overview.png)

## Read the timestamp

For each camera image, identify the illuminated LED in each row. Convert the three row readings to time using the timer frequency, then add the values together.

For example, at 1 kHz:

- A first-row position of 5 represents 5 ms.
- A second-row position of 3 represents 30 ms.
- A third-row position of 5 represents 500 ms.
- The relative timer reading is therefore 535 ms.

The exact first position and counting direction depend on the timer's labels. Use the same convention for every image in the comparison set and write the convention beside your measurements.

## Calculate the synchronization spread

1. Read the timer timestamp from each camera image.
2. Record the timestamp beside the camera number and capture repetition.
3. Find the earliest and latest timestamp in the same capture.
4. Subtract the earliest value from the latest value.
5. Repeat for several captures and compare the spreads.

The result is an estimate of the relative trigger or exposure spread visible in the images. It can reveal a camera that consistently fires later, but it cannot identify the cause by itself. A difference may come from trigger delivery, camera processing, shutter behavior, rolling shutter, exposure length, timer visibility, or image-reading error.

## Make the result repeatable

- Keep the timer and all cameras fixed between runs.
- Use the same lens, focus, exposure, and lighting conditions.
- Test the complete trigger path, including Raspberry Pi or Windows nodes if they are part of the production rig.
- Check that every camera captured the same timer state and that no image was delayed by a reconnect or transfer issue.
- Repeat the test after changing one variable, such as trigger warmup or camera settings.
- Save the original images and a table of readings with the test dataset.

Use the measurement to compare configurations, not as a universal benchmark. A rig that produces a small spread with one shutter speed or timer setting may behave differently with another camera mode or exposure duration.


Measure trigger synchronization with an LED timer

********* THE CONTENT OF THIS PAGE IS OUTDATED ***********

This guide covers the hardware and current Camera Server workflow for operating addressable NeoPixel LED strips from a Raspberry Pi with an XangleBoard. Treat the electrical ratings of the strip, board, and power supply as a separate hardware responsibility from Camera Server configuration.

## Before you start

You need:

- A Raspberry Pi supported by the current XangleOS image and Camera Server network-node workflow.
- One XangleBoard per Raspberry Pi that drives a strip.
- A compatible addressable NeoPixel strip, such as a 5 V strip that accepts a single data signal.
- A suitable 5 V power supply sized for the strip's maximum pixel count and brightness.
- A separate USB-C or other supported power supply for the Raspberry Pi.
- A wired Ethernet connection or a reliable network path between the Pi and the Camera Server computer.

Do not use the old XCS16 version numbers as compatibility requirements. Check the current Camera Server release notes and the Network Nodes view for the supported Pi image and node versions before preparing a production rig.

## Hardware installation

1. Power off the Raspberry Pi and disconnect its power supply.
2. Install the XangleBoard on the Pi's GPIO header. Make sure the header is aligned correctly and fully seated.
3. Connect the strip to the board's output terminals. Match the board labels to the strip:
   - `GND` to `GND`
   - `DOUT` to the strip's data input, usually marked `DIN`
   - `5VDC` to the strip's positive 5 V input
4. If the strip provides a ground connection beside the data input, connect that ground as well. The wiring reference below shows the signal order and optional ground connection.
5. Connect the strip power cable to the correctly rated 5 V power supply. The LED power supply powers the strip, not the Raspberry Pi.
6. Power the Raspberry Pi from its own supported power supply.
7. Before connecting a long strip or turning on the full installation, verify polarity, the data direction, the voltage, and the power-supply rating.

![NeoPixel strip wiring reference](https://public.xangle3.com/doc/screenshots/2026-07-14/neopixels-led-strip-wiring.png)

The first pixel is directional. Connect the board's data output to the strip end marked `DIN`, `IN`, or with an arrow pointing toward the pixels. Connecting to `DOUT` can leave the strip dark even when the Pi and power supply are working.

## Power and pixel limits

The maximum number of pixels depends on the strip, brightness, animation, wiring length, injection points, and power supply. Do not select a pixel count from an old shopping link or assume that one board can safely power any strip length.

- Size the 5 V supply for the strip's actual maximum current, with headroom.
- Use an appropriate fuse, distribution wiring, and power injection for longer strips.
- Keep the high-current LED power path separate from the Pi's power path.
- Never exceed the voltage specified by the strip.
- Start with a short test section and low brightness before connecting the complete installation.
- If pixels become dim, change color, flicker, or reset when the animation gets brighter, stop and investigate voltage drop or insufficient power before continuing.

The Pi can be installed near cameras or other rig hardware, but the LED supply must still be sized and wired for the strip. A shared Pi location does not make the LED power connection interchangeable with the Pi power connection.

## Add the Pi in Camera Server

1. Launch the current Camera Server build.
2. Open the app's Network Nodes or node-management view and confirm that the Raspberry Pi is discovered.
3. Verify the node identity and connection state before assigning it to a production group.
4. Create or select the group that should control the light hardware, then assign the Pi to that group.
5. Open the lighting controls exposed by the current build for that group. Do not use the legacy `http://localhost:8091/lights` route as a required setup step.
6. Enter the number of active pixels and save the configuration.
7. Start with a simple color or pattern and confirm that the strip responds.

If the Pi does not appear, first check its power, Ethernet link, IP address, node image, and network visibility. A missing node is a discovery or network problem, not a strip pixel-count problem.

## Configure patterns and capture behavior

Use the current lighting controls to create and save presets for the colors or patterns needed by the event. Keep a simple static preset available as a fallback.

Before enabling lighting changes during capture:

- Test the master light state from the operator controls.
- Test each preset with the complete strip connected.
- Confirm which group and node receive the command.
- Trigger a test capture and verify the light change occurs at the intended point in the sequence.
- Use the current trigger warmup or delay setting only when the hardware needs time to settle. Measure the required delay on the actual rig instead of copying a value from the old guide.
- Confirm the lights return to the intended state after a capture, error, app restart, or node reconnect.

Keep lighting control independent from camera triggering until both systems have passed separate tests. This makes it easier to tell whether a failed capture comes from the cameras, the network node, or the LED hardware.

## Troubleshooting

### The Pi is not discovered

Confirm that the Pi and Camera Server computer are on the same reachable network, that the Pi is powered, and that the Ethernet link is active. Restart the node only after checking the cable, switch port, and node identity. If other nodes are visible but this Pi is not, compare its image, network configuration, and power supply with a working node.

### The strip stays dark

Check that the strip receives 5 V power, the grounds are connected, and the board data output goes to the strip's data input. Confirm the strip direction, pixel count, and selected group. Test a short section at low brightness to separate a wiring problem from a configuration problem.

### The first pixels work but later pixels fail

Check voltage drop, power injection, cable size, connector quality, and the supply's current capacity. Reduce brightness and test again. A longer strip may need power injected at more than one point and may need to be divided across multiple power circuits.

### The strip flickers or resets

Inspect the ground and data connections, shorten the data cable where possible, and verify that the LED power supply is not sagging under load. Do not solve repeated resets by increasing the configured pixel count beyond the physical strip.

### A preset changes at the wrong time

Confirm the active group, preset assignment, and trigger warmup or delay settings. Test the preset manually first, then test it with one controlled capture before adding it to a full event sequence.


NeoPixels LED strips

Every capture passes through several stages before the result is ready: files are transferred from the cameras or nodes, datasets are prepared, processing tasks run, outputs are rendered, and the result is written for review or delivery. Optimize the slowest stage instead of changing several settings at once.

## 1. Direct camera and USB hub architecture

For a rig with several cameras connected to one Windows computer:

### Hardware

- Use a fast computer with a modern multi-core processor and a fast local SSD.
- Connect the computer to a high-quality USB-C or USB 3 controller or hub.
- Avoid chaining USB hubs. Keep the topology simple and distribute cameras across independent controllers when the rig is large.
- Use short, reliable USB cables and test every hub port under a real capture load.
- Keep the active working directory on a local SSD. Do not place it inside OneDrive, Google Drive, or another cloud-sync folder.

### Camera and output settings

- Use the smallest camera resolution that meets the final output requirement. Larger files increase transfer time, storage use, processing time, and output time.
- Configure only the processing tasks and output formats that the event actually needs. Disable unnecessary renders, previews, or delivery outputs while testing throughput.
- Start with a moderate output quality and a fast codec preset, then increase quality only when the visual result requires it.
- Test the complete path with a representative dataset. A small single-camera test does not reveal the transfer and processing limits of a full rig.

## 2. Raspberry Pi architecture

Raspberry Pi camera nodes can distribute capture and transfer work across the network. This can improve triggering and throughput, especially when a Windows computer would otherwise handle too many camera connections through USB.

- Use a Gigabit Ethernet switch for the nodes and the Camera Server computer.
- Avoid daisy-chaining switches. Use a simple star topology where possible.
- Confirm that the computer and each node negotiate a 1000 Mbps link, not 100 Mbps.
- Use reliable Ethernet cables and dedicated network infrastructure for the rig instead of sharing a congested event or office network.
- Add nodes when the measured transfer or capture workload requires it. More nodes also mean more power, cabling, and network dependencies, so test the complete system after each change.
- For RAW or high-resolution workflows, expect file transfer and storage to become the limiting stages even when triggering remains responsive.

## 3. Find the slow stage

Measure the same representative capture several times and identify where the delay appears:

1. **Capture and transfer:** cameras or nodes take too long to finish sending files.
2. **Dataset preparation:** files arrive, but analysis or organization is slow.
3. **Processing:** an enabled process task consumes most of the time.
4. **Rendering and output:** resizing, codec work, watermarking, or other output tasks are slow.
5. **Storage or delivery:** the destination drive, network, or backup path has low throughput.

Watch CPU, memory, GPU, disk activity, disk throughput, and network throughput while the job runs. High disk activity with very low throughput points to a storage bottleneck, not necessarily a CPU problem. Check [Known issues](/wayfinder/troubleshooting/progressive-system-degradation) for the SSD write-bottleneck symptoms.

Change one variable at a time, record the result, and keep the settings that improve the full event workflow rather than only one isolated stage. Always run a complete multi-camera test before relying on a faster configuration at an event.


Optimization

- 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.


Xangle Sharing Server

Troubleshooting

Known issues

SSD write bottleneck causing random processing slowdowns

Quick SSD check

Recommended actions

Norton 360 and distributed architectures

Do not use cloud-sync folders as working directories