You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Distribution: Native C++ binary via CMake, or Docker (image TBD)
Project description: "a faithful C++ implementation of the current Baysor algorithm with a more efficient runtime and broader modern I/O support"
Release notes for 0.8.2: "improves cross-platform builds, adds some optimizations for large runs (e.g. Xenium 5K)"
Why upgrade
Direct parquet support — the C++ port natively reads parquet (no Julia Parquet.jl Zstd issue). This would let us delete the PARQUET_TO_CSV step in BAYSOR_GENERATE_PREVIEW and BAYSOR_RUN_TRANSCRIPTS_PARQUET (tiled). That step OOMs on the Atera (Xenium WTA 18k-target) at default memory — see the Atera compatibility report (docs/2026-05-28_REVIEW_atera-on-spatialaxe-compatibility.md).
Performance — C++ rewrite is "much more efficient" per project description. Optimizations explicitly target Xenium 5K-panel scale, which is directly relevant to Atera ~18k-target workloads.
Direct experiment.xenium input — could simplify bundle-staging logic for image- and coordinate-mode subworkflows.
Algorithmic continuity — cpp port preserves the v0.7.1 algorithm, so segmentation behavior should match.
Migration plan
Identify or build official container for cpp-0.8.2 (binary build vs Docker)
Update containers in baysor/run, baysor/preview, baysor/segfree, baysor/preprocess, baysor/create_dataset
Audit CLI argument compatibility — cpp may differ from Julia (e.g., column flag names, --scale)
Drop or refactor PARQUET_TO_CSV calls in baysor_generate_preview and baysor_run_transcripts_parquet subworkflows
If experiment.xenium direct input works, simplify BAYSOR_PREPROCESS_TRANSCRIPTS accordingly
End-to-end tests on a Xenium v1 bundle (XOA 4.x) and Atera Cell Pellet
Risks
CLI compatibility: needs per-command verification
Output format compatibility: cpp may emit different polygon / transcript-assignment file structures; downstream XR import needs validation
Container ecosystem: no Wave container yet known — may need a request to Seqera or a custom build
Cross-links
Related (paired): Punkst / Ficture C++ migration — together these eliminate PARQUET_TO_CSV entirely from the pipeline.
Triggered by: Atera compatibility session 2026-05-28.
Current state
masterbranchbaysor/{preprocess, create_dataset, run, preview, segfree}image(cellpose → baysor),coordinate(proseg/segger → baysor),preview,segfreeProposed upgrade
cpp-0.8.2(C++ port) — released 2026-04-30cppbranch — https://github.com/kharchenkolab/Baysor/releases/tag/cpp-0.8.2Why upgrade
Parquet.jlZstd issue). This would let us delete thePARQUET_TO_CSVstep inBAYSOR_GENERATE_PREVIEWandBAYSOR_RUN_TRANSCRIPTS_PARQUET(tiled). That step OOMs on the Atera (Xenium WTA 18k-target) at default memory — see the Atera compatibility report (docs/2026-05-28_REVIEW_atera-on-spatialaxe-compatibility.md).experiment.xeniuminput — could simplify bundle-staging logic for image- and coordinate-mode subworkflows.Migration plan
cpp-0.8.2(binary build vs Docker)baysor/run,baysor/preview,baysor/segfree,baysor/preprocess,baysor/create_datasetPARQUET_TO_CSVcalls inbaysor_generate_previewandbaysor_run_transcripts_parquetsubworkflowsexperiment.xeniumdirect input works, simplifyBAYSOR_PREPROCESS_TRANSCRIPTSaccordinglyRisks
Cross-links
PARQUET_TO_CSVentirely from the pipeline.