sfmTriangulation segfaults with dspsift

Meshroom 2025.1.0 — Bug Report: Two-Sides / 360° Object Reconstruction pipeline Date: 2026-08-25 Meshroom version: 2025.1.0 (2025/08/18, Linux tarball) Host: Linux Mint, kernel 6.14.0-37, 16 cores, 31 GB RAM, 2× NVIDIA (RTX 2080 8 GB, RTX 2070 SUPER 8 GB), driver 580.159.03

All issues below were hit while running the Photogrammetry Object Two Sides template (photogrammetryObjectTwoSides.mg) on a 232-image turntable capture (111 top / 121 bottom, 8-bit TIFF, 24 MP).

Bug 1 — GUI save produces duplicate node UIDs in two-CameraInit pipelines Severity: High (blocks compute)

Summary: Saving a project created from the Two Sides template via the GUI writes duplicate instance UIDs for the mirrored node pairs. Compute then aborts with a "duplicate nodes to process" error.

Repro: 1. Start Meshroom, open the "Photogrammetry Object Two Sides" template from the Home → Pipelines tab. 2. Set CameraInit_1 / CameraInit_2 folder inputs. 3. Save the project (the compute flow forces a save). 4. Re-open the saved .mg and run Compute All Nodes.

Actual: The saved .mg contains UIDs shared by pairs of nodes — e.g. CameraInit_1/CameraInit_2, FeatureExtraction_1/FeatureExtraction_2, FeatureExtraction_3/FeatureExtraction_4, ConvertSfMFormat_2/ConvertSfMFormat_3 (12 duplicated UIDs across 36 nodes). Compute fails:

cannot compute because there are some duplicate nodes to process. first match camerainit and cameraint2 ... Expected: Every node instance gets a unique UID on save; compute proceeds.

Notes: Editing the .mg to regenerate unique UIDs (sha1(nodeName)) and reloading resolves it. The bug is in the save path — a project file with no UIDs (fresh template) gets duplicated UIDs written on first GUI save.

Bug 2 — "Node UID differs from the expected one" upgrade dialog on every reload Severity: Medium (cosmetic but persistent)

Summary: After any GUI save, every subsequent project reload triggers the "Compatibility issues detected" dialog listing 7 nodes (Texturing_3, DepthMapFilter_3, DepthMap_3, PrepareDenseScene_3, SfMTriangulation_4, SfMMerge_1, SfMTriangulation_2) as "Node UID differs from the expected one", offering to upgrade. Clicking Yes regenerates the UIDs, but the next save/reload repeats the dialog. This is likely the same root cause as Bug 1 (UID generation inconsistent between save and load).

Repro: 1. Save any Two Sides project in the GUI. 2. File → Open the same file. 3. The upgrade dialog appears. Click Yes. 4. Save again, reload again — dialog returns.

Expected: A project saved by version X loads cleanly in version X.

Bug 3 — aliceVision_sfmTriangulation segfaults with dspsift features Severity: High (blocks the Two Sides pipeline)

Summary: SfMTriangulation_2 (top branch) crashes deterministically with returnCode: -11 (SIGSEGV) ~3 s after start, during/after "Loading features", when the features were extracted with the dspsift descriptor. The sibling node SfMTriangulation_3 (bottom branch) with identical settings succeeds, so the crash is input/data dependent.

Repro: 1. Run the Two Sides template end-to-end (default settings, dspsift). 2. SfMTriangulation_2 fails; log ends with:

Loading features 0% 10 20 30 40 50 60 70 80 90 100% ... Process was killed by signal: 11 status JSON: "status": "ERROR", "returnCode": -11, elapsedTime: ~3.4 s.

Workaround found: Switching describerTypes from dspsift to sift on all describer-carrying nodes (see Bug 4) eliminates the crash — the same dataset completes the whole pipeline with sift.

Expected: Either dspsift triangulation should work, or the node should fail cleanly with an error instead of segfaulting.

Bug 4 — Two Sides template hardcodes dspsift inconsistently Severity: Medium (template defect)

Summary: In photogrammetryObjectTwoSides.mg, describerTypes is linked (auto-propagating) on FeatureExtraction_1/2 → FeatureMatching_1/2 → StructureFromMotion_1/2, but hardcoded to ['dspsift'] on FeatureMatching_3/4/5, ConvertSfMFormat_2/3, SfMMerge_1, and SfMTriangulation_2/3/4. Changing the describer on the FeatureExtraction nodes therefore leaves the rest of the pipeline on dspsift, producing a feature/describer mismatch (masked-branch matchers read dspsift .desc files while extraction produced sift, and the triangulation requests dspsift). This inconsistency is also a plausible contributor to Bug 3.

Expected: All describerTypes should propagate via links, or be consistently set.

Bug 5 — meshroom_batch cannot drive the Two Sides template headless Severity: Medium (CLI defect)

Summary: meshroom_batch -p photogrammetryObjectTwoSides -i CameraInit_1: -i CameraInit_2: --compute yes fails immediately:

Nothing to compute for node CameraInit_1. The single-CameraInit templates (e.g. photogrammetryObjectTurntable) work fine with the same invocation style.

Expected: Multiple -i inputs should be applied to their named node instances and the pipeline should run (2023.3 changelog claims "meshroom_batch: support multiple init nodes").

Bug 6 — Nightly Linux build missing the AliceVision plugin Severity: High (broken asset)

Summary: The nightly Linux tarball (Meshroom-2026.08.20-8cc5e88-linux.tar.gz, sha256 7e3f8a299af676cce75707ff3c21cbbd5a7a351a86186bf552dce63660a47541) extracts without the AliceVision plugin: no pipeline templates (no .mg files anywhere), no aliceVision binaries. The launcher errors:

Pipeline templates folder '.../aliceVision/share/meshroom' does not exist. and bin/meshroom_info fails with ModuleNotFoundError: No module named 'meshroom'.

Expected: The nightly Linux asset should be complete (templates + plugin binaries), as the 2025.1.0 tarball is.

Environment context Pipeline: Photogrammetry Object Two Sides (both branches run, merge via SfMMerge from_landmarks) Inputs: 232 × 8-bit TIFF (6024×4024 source, shared-box cropped), EXIF intact (Sony ILCE-6500, focal 210 mm), turntable capture (flipped object → two sides) The single-sided "Photogrammetry Object Turntable" template runs the same dataset successfully end-to-end (SfM → depth maps → mesh → texture), which isolates these bugs to the Two Sides template/UID/triangulation paths.