vc_grow_seg_from_seed silently deletes the grown surface and exits 0 when the volume is an s3:// path

[DarthCeltic]

Growing a segment straight from an s3:// volume produces no output, no error, and exit code 0.

vc_grow_seg_from_seed reads the voxel size at line 326:

float voxelsize = json::parse(std::ifstream(vol_path/"meta.json"))["voxelsize"];

The zarr data streams from S3 fine, but that's a plain ifstream against an s3:// path, so voxelsize doesn't get the real value. area_cm2 then computes to 0.000000, and at line 1371 that fails the min_area_cm check (default 0.3), which calls remove_all(seg_dir) and returns EXIT_SUCCESS:

double area_cm2 = (*surf->meta)["area_cm2"].get<double>();
if (area_cm2 < min_area_cm) {
    if (std::filesystem::exists(seg_dir)) {
        std::filesystem::remove_all(seg_dir);
    }
    return EXIT_SUCCESS;
}

The surface is deleted and the run reports success. It took me a while to work out that the grow had actually worked — 99 generations, about 15.6M vx² of surface, and an empty output directory.

Setting {"min_area_cm": 0.0} gets the mesh written, but the area recorded in its meta.json is still wrong for the same reason.

Same root cause shows up in a second tool with a different symptom: vc_render_tifxyz against s3://vesuvius-challenge-open-data/PHerc0009B/volumes/20250521125136-8.640um-1.2m-116keV-masked.zarr prints

Voxel size: 1.0 (no metadata found; override with --voxel-size)

and carries on with the wrong scale rather than deleting anything.

Reading that meta.json through the same S3-aware path the volume already uses would fix both. I haven't sent a patch — I don't know whether anything downstream relies on the current fallback behaviour.

[Bullo27]

Confirming both symptoms, with a version detail that should simplify triage — the two halves of this report have different current status:

The vc_grow_seg_from_seed half is already fixed on main. This was reported as #1226 (Jul 25): a wrong/missing remote voxel size makes area_cm2 compute to 0, which trips the min_area_cm check, deletes the surface and exits 0 — exactly what you hit. The Las-volumes rework (#1302/#1310, merged Aug 5) rebuilt loadRemoteVolumeMetadata so the scan.tomo.acquisition.detector.samplePixelSize fallback (mm→µm) always applies. Measured today on main (f74d09f) against your exact volume, no overrides:

https://…/PHerc0009B/volumes/20250521125136-8.640um-…-masked.zarr  →  voxelsize: 8.64
s3://vesuvius-challenge-open-data/PHerc0009B/volumes/20250521125136-…  →  voxelsize: 8.64

Both schemes discover the correct value, so a binary built from current main shouldn't reproduce the deletion. (A release from before Aug 5 does — the code quoted in the report matches an older snapshot; on today's main the tool takes volume->voxelSize() at vc_grow_seg_from_seed.cpp:365.)

The vc_render_tifxyz half is still live, as you observed. The renderer only ever reads a local meta.json and falls back to Voxel size: 1.0 for streamed volumes — remote discovery was never wired into it. PR #1228 proposed forwarding the volume's voxel size from VC3D for remote renders; it was closed unmerged a few days ago, so --voxel-size remains the workaround. Your report is a good argument for revisiting that gap, whichever way the maintainers prefer to fix it.

_{Verification runs done locally with AI assistance (Claude); the transcript lines are from actual runs.}

[DarthCeltic]

Thanks — that's the detail I got wrong, and it explains it.

I was working from a checkout of merge-ink-pipelines, not main, and I never diffed the two before filing. That branch doesn't carry the Las-volumes rework, so the code I quoted at line 326 is exactly the pre-Aug-5 snapshot you describe. On main it's volume->voxelSize() at line 365, as you say. My mistake, and an easy one to avoid — I should have checked upstream before reporting.

The render half I'll stand behind, since it reproduces against the current tool: streaming a remote volume gives Voxel size: 1.0 (no metadata found; override with --voxel-size), and the fallback silently changes scale rather than failing. Good to know #1228 exists and was closed unmerged; happy to leave this open as a pointer to that gap, or close it as a duplicate of whatever the maintainers prefer to track it under.

Two smaller things from the same session that do reproduce on main, filed separately as #1404 so as not to pile onto this one: --cache-gb defaults to 16 and stalls silently on a 15 GB Docker host with no log line, and the resume path treats a zero-byte TIFF from a killed render as complete.