Browser and hardware#

The browser app runs the whole pipeline on WebGPU with the decoders and a few CPU stages in WebAssembly. That buys you a real application with nothing to install, and it costs you a dependency on a browser feature that is not yet universal.

Browser support#

The app checks for an adapter at startup and tells you what it found. If it lands on a software adapter — SwiftShader, typically — it warns you: that path works but is slow and caps buffers at a gigabyte, so large frames will be refused.

Chrome on Linux#

Stock Chrome on Linux finds no WebGPU adapter. The chrome://flags pair (#enable-unsafe-webgpu and #enable-vulkan) only gets you the software adapter. Leave those flags at Default and launch Chrome with switches instead:

google-chrome --user-data-dir=~/.config/lapstack-chrome \
  --enable-unsafe-webgpu \
  --enable-features=Vulkan,VulkanFromANGLE,DefaultANGLEVulkan \
  --ozone-platform=x11

Three things about that command are deliberate:

• A separate profile (--user-data-dir). Chrome ignores switches when a window with the same profile is already open, so without this your existing session silently wins and nothing changes. It also leaves your normal Chrome untouched.
• VulkanFromANGLE,DefaultANGLEVulkan is what selects the hardware adapter. The flags page's "ANGLE graphics backend = Vulkan" (--use-angle=vulkan) exposes an adapter too, but on NVIDIA under Wayland it makes Chrome's accelerated 2D canvas paint black and the app shows nothing. Leave that one at Default.
• --ozone-platform=x11 forces the X11 backend through XWayland. Chrome's native Wayland backend refuses to present with Vulkan enabled and the window stays black.

GPU memory, and what limits stack size#

Every full-resolution plane is one WebGPU storage buffer. A frame needs

3 × width × height × 4 bytes

per buffer — about 550 MB at 45 megapixels — and that must fit inside the adapter's maxBufferSize and maxStorageBufferBindingSize. In total a 45-megapixel run wants around 3.5 GB of GPU memory.

The app reports the adapter's limits and refuses frames that will not fit, rather than failing halfway through a run.

Stack length costs almost nothing. Frames stream through the alignment and fusion one at a time, so the number of frames does not drive memory. What each frame leaves behind is its focus slice for the depth pass — about 5.7 MB at 45 MP on the default working grid. A hundred frames is therefore about 570 MB of slices, not a hundred frames of pixels.

What does grow is kept results (a 45-megapixel sixteen-bit image is 270 MB each, bounded by results kept MB in the panel) and the undo history while retouching, capped at about 600 MB of patches.

If a stack is too large for your GPU, turn on draft in the parameter panel. Every frame is block-averaged as it is decoded, so the entire run happens at a fraction of the size — a real result, just smaller, and a good way to check settings before committing.

Native requirements#

The command-line tool has no GPU requirement at all.

• CPU. Everything is multithreaded; more cores is straightforwardly faster. A 25-frame 45-megapixel run takes about 26 seconds on a 128-thread host.
• Memory. Around 8–12 GB of peak resident memory for 45-megapixel stacks, roughly flat in the number of frames because frames stream. Before streaming, a 25-frame run peaked at 31 GB and 100 frames did not fit at all.
• CUDA (optional). An NVIDIA GPU with the driver's libcuda, plus libnvrtc from the toolkit. A binary built with the gpu feature still runs on a machine without CUDA; only --gpu and --gpu-align fail, with a message. See GPU acceleration.

File access#

Choosing a folder to save into — and reopening a project's frames from the folder they live in — uses the File System Access API, which Chrome and Edge have and other browsers do not. Everywhere else, saved files come out as ordinary downloads, and a browser may ask permission when a batch saves several at once. Nothing else about the app depends on it.