The problem — A modern lattice or diSPIM light-sheet setup streams data faster than conventional tools can write or read it. Libtiff I/O, single-machine deconvolution, and tile-by-tile stitching are all serial bottlenecks that turn a weekend acquisition into a month of post-processing — if they complete at all. The experiment and the analysis are not decoupled; the analysis is the rate-limiting step.
What it is / how it works — PetaKit5D (Ruan et al., Nature Methods 2024) is a conductor–worker distributed framework that breaks the processing chain into parallel subtasks dispatched across CPU and GPU clusters. Its custom C++ I/O layer (Cpp-Tiff / Cpp-Zarr) is 23–28× faster than libtiff, fast enough to keep pace with full-rate camera streams. A fused deskew-plus-rotation operation reduces memory footprint by roughly 10× compared to sequential transforms. Deconvolution uses OTF-masked Wiener Richardson-Lucy (OMW), approximately 10× faster than standard RL, running in online (real-time) or batch mode. ZarrStitcher handles multi-tile fusion into OME-Zarr/NGFF chunks, more than 10× faster than tile-by-tile approaches.
Where it fits in the Fovea workflow — PetaKit5D lives at the ingest and preprocess stages of a light-sheet pipeline: it is what turns raw camera output into a chunked, multiscale OME-Zarr store that downstream tools — BigStitcher for registration, TrackMate or ultrack for tracking — can access lazily. Getting this step right is a prerequisite for everything that follows; a deconvolution artefact or stitching seam introduced here will silently corrupt all downstream features.
Where it breaks — PetaKit5D is MATLAB-centric; the Python wrappers (PyPetaKit5D) reduce friction but have less coverage. Deskew interpolation introduces artefacts when the skew angle exceeds ~2.0 in the stage-scanning geometry. And OMW deconvolution, like any deconvolution, can synthesise structure that was never physically present — particularly in low-SNR regions where the PSF model is approximate.