PHerc1203 physical-truth label grid is chunk-padded 34 voxels past the volume extent

[DarthCeltic]

The PHerc1203 physical-truth labels are [2016, 3456, 3456] on the lo volume's L1 grid, which is [9489, 3422, 3422] (from 20250820131727-9.362um-1.2m-113keV-masked.zarr, L0 [18977, 6844, 6844] at 9.362 µm).

3456 is ceil(3422 / 128) * 128 = 27 × 128, so the label array is chunk-padded 34 voxels past the volume it describes, in both x and y. In z it spans L1 3936..5952, well inside.

The store is sparse, so the padding reads as fill_value and can't be mistaken for material — no correctness problem. But read naively it looks like "no material" across the last 1% of every row and column, which is at the sheet edges, where an unexplained deficit is fairly believable and easy to chase for a while.

The transform I ended up with, in case it's worth putting in the README:

label(z, y, x) = (L0_z/2 - 3936, L0_y/2, L0_x/2)

valid only where y and x are below 3422.

[Jinhojeong]

I can confirm this from a full scan of the label volume, since I consume these labels downstream. Material voxels span x 462 to 2895, y 772 to 2645, z 39 to 1974, and the valid bit spans the same envelope to within three voxels. Nothing exists at or beyond 3422 in x or y, so your arithmetic holds exactly, and the pad band is silently zero rather than marked invalid, which is worth knowing because it means no bit distinguishes padding from unlabelled space. One practical addition, the labelled content ends more than 500 voxels before 3422 in both axes, so on this particular label set the edge-deficit misread cannot actually arise, the risk is generic to naive dense reads rather than realized here. Your coordinate transform matches what I derived independently and I would support putting it in the README. Checking your claim also led me to audit my own consumer of these labels and I found and corrected a read bug on my side, reported in issue 191.

[DarthCeltic]

Good calls on both points—that cuts straight to the actual issue.

The core problem is that the padding band is silently zero-filled in place of marked invalid, leaving no bit-level distinction between chunk padding and unannotated space. Without tracking y, x < 3422 explicitly, downstream code can't tell "outside the volume" from "inside, but empty."

Thanks for catching that on the edge deficit also. Since labeled content stops 500+ voxels short of 3422 across both axes, that misread doesn't actually trigger on this dataset. It's a latent hazard for dense reads generally rather than an active bug here, so my original framing overstated it.

README transform logic:

label(z, y, x) = (L0_z/2 - 3936, L0_y/2, L0_x/2)   # valid where y, x < 3422

Good to know it matches your independent derivation. Glad it turned up something useful on your end. I'm seriously hoping I'm not misreading things here. :: laugh ::