Scroll 3 (PHerc0332) m7 surface predictions: ~70% of positive voxels are phantoms where the masked CT is 0

[spencerdavis-tx]

Artifact:
s3://vesuvius-challenge-open-data/PHerc0332/representations/predictions/surfaces/20251211183505-surface-20260413222639-surface-m7-L2-th0.2.zarr
(zarr v2, OME multiscale L0–L5, L0 shape [8398, 3941, 3941] on the CT-L2 / 9.596 µm grid, uint8 0/255, chunks 192³; the zarr's metadata.json dates the run 2026-05-13, model s3://scrollprize-reconstruction/models/m7_nnunet/).

Finding. A large majority of the positive voxels are not papyrus surface: they are solid prediction slabs sitting where the published SAM2-masked CT volume (PHerc0332/volumes/20251211183505-2.399um-0.2m-78keV-masked.zarr) reads exactly 0 — a halo ring around the scroll cross-section plus end caps. Presumably inference ran on (or was blended over) unmasked data, or the mask used at inference differs from the published masked volume; either way the published preds and the published masked CT disagree about where the scroll is.

Numbers (survey 2026-06-11, re-verified against the live S3 objects 2026-07-03 — unchanged; preds zarr LastModified 2026-05-13, masked CT 2026-03-03, no re-versioning):

• Global CT-supported share of positive voxels: 0.302 → ~70% phantom.
• Full-resolution axial planes z ∈ {2000, 4224, 6000} (preds-L0 grid): phantom fraction 0.681 / 0.672 / 0.646 (2026-07-03 re-check: 0.6810 / 0.6717 / 0.6459, positives 2,259,758 / 2,379,932 / 2,110,813 per plane).
• Interior blocks (well inside the scroll): phantom fraction ≤ 6.1e-05 — where CT exists, the predictions are excellent recto-face skins. The bug is only in the zero-CT zones.
• Cube-level (128³) support is strongly bimodal: at a 0.5 support threshold, ~10.9k cubes are ~all-phantom vs ~15.9k ~fully supported, only ~536 between — so cube-level filtering plus voxel-wise masking is cheap and clean.

Not scroll-specific — the whole 2026-04-13 batch appears affected. The same model-run ID
(20260413222639) stamps the published surface preds for PHerc1451, PHerc0814, and PHerc1299.
Spot-check on PHerc1451 (mid plane z=7493 of 20260319101107-surface-...m7-L2-th0.2.zarr vs its
published masked CT at L2, same grid 14986x5203x5203): phantom fraction 0.5994 — same solid
outer-halo morphology (radial profile is a monotone outer ring, no wrap-period banding). 0814/1299
not yet measured but presumably affected.

Why it matters downstream: vc_grow_seg_from_seed does not consult the CT. Seeded naively (its own random_seed mode, or any seed near the halo), it rides the phantom shells — an early trace of mine had 63% of its lattice at CT ≤ 5. Any CT-blind consumer of these preds (tracer, mesh extraction) will burn most of its compute on the halo.

Reproduction (~10 lines, anonymous S3):

import zarr, numpy as np
base = "s3://vesuvius-challenge-open-data/PHerc0332"
preds = zarr.open(f"{base}/representations/predictions/surfaces/"
                  "20251211183505-surface-20260413222639-surface-m7-L2-th0.2.zarr",
                  mode="r", storage_options={"anon": True})["0"]
ct    = zarr.open(f"{base}/volumes/20251211183505-2.399um-0.2m-78keV-masked.zarr",
                  mode="r", storage_options={"anon": True})["2"]
# preds L0 and CT L2 share the same [8398, 3941, 3941] grid (9.596 um)
z = 4224
p, c = np.asarray(preds[z]) > 0, np.asarray(ct[z])
print("phantom fraction:", (p & (c <= 5)).sum() / p.sum())   # ~0.67

Suggested fixes: AND the published preds with the published mask before upload (or re-publish a masked variant), and/or ship the phantom-fraction number in the zarr's metadata so consumers know to mask. The workaround I used — sparse chunk-wise supported = preds & (CT > 5), then regenerating normal grids from the supported volume — fixed every downstream consumer at once; code at https://github.com/spencerdavis-tx/vesuvius-automesh (vesuvius_automesh/build_supported_preds.py), plus an axial overlay figure there.

[bruniss]

yeah this is due to bad merging at the boundaries -- something we need to add a fix for in the inference/blend section.

[jrudolph]

Maybe we should just use volume value 0 as mask and mask that out after inference? Logically, it would be best to do it in the end but it would be expensive to reread all of the input volume, so maybe we could do it on the logits right after inference?