PHercParis4 windings 128-129: both published tracings run through the fused outermost wrap, and the ink model finds no text there

[rodriguescarson]

In one sentence: both published tracings of PHercParis4 windings 128-129 sit on the fused outermost wrap of the scroll, and the team's own ink model finds no text on them while the adjacent w126-127 from the same runs reads fine.

I was trying to: I've been checking published surfaces against their own ink renders before spending any compute on them. Two stood out and I spent a few days on them, so here's what I found.

Using: the public bucket only. Segments 20260623171929-w128-129, 20260701183151-w128-129 and their w126-127 neighbours; each segment's own surface-volumes/*.zarr and ink-detection/downsampled/*-ds8.jpg; labelscope onsheet --surface-volume <zarr> (https://github.com/rodriguescarson/labelscope, MIT).

What happened: see below. Short version: no letterforms on either w128-129 render, a flat layer profile on their surface volumes, and cross-sections that show fused material and then the scan mask, not a separable sheet.

What I expected or needed: either w128-129 marked as not carrying a recoverable recto surface, or a cheap pre-flight check before an ink run so this gets caught in a minute on a CPU instead of after a GPU run.

Evidence / reproduction: figures and per-chunk data below; exact commands in https://github.com/rodriguescarson/labelscope/blob/main/findings/w128-129-evidence.md

• I personally encountered or reproduced this using the version and data stated above.

Details

What I noticed

The ink-detection renders published with the segments
20260623171929-w128-129 and 20260701183151-w128-129 are speckle with no
letterforms, while the adjacent w126-127 segments from the same two tracing
runs show columns of legible Greek from the same model on the same scan:

What the surface volumes say

Reading 200 random chunks of each segment's own surface-volumes/*.zarr and
taking the range of each chunk's 109-layer profile (a quick proxy for "is there
a sheet under this surface"), medians over two seeds:

| | w128-129 | w126-127 |
|,-|,-|,-|
| June tracing | 14.1 / 8.8 | 43.1 / 36.2 |
| July tracing | 17.1 / 15.1 | 28.1 / 28.1 |

Mann-Whitney one-sided p between 3e-9 and 0.02 in every case.

What the cross-sections show

Rendering the scan through the flattest and most structured block of each
surface (red line = traced surface, ±70 voxels along the normal):

• Flat blocks on w128-129 are homogeneous fused material with no layers within
  ±70 voxels, nothing for a tracer to follow.
• Structured blocks on w128-129 show papyrus on one side of the line, a dark
  band, and then the scan mask. In the June tracing the line sits in that
  dark band about 25 voxels outside the last papyrus.

So windings 128-129 appear to be the outermost wrap of the scroll, largely
fused into its crust, and both tracing series stop there because there is no
sheet beyond it.

Two questions

1. Is the terminal patch of a tracing run retained by policy, or should
   w128-129 be marked as not carrying a recoverable recto surface?
2. Is there interest in a pre-flight check on surface volumes before an ink
   run? The measurement above takes about a minute per segment on a CPU and
   would have flagged both of these. It is in labelscope onsheet ,surface-volume <zarr> (https://github.com/rodriguescarson/labelscope),
   but the statistic is simple enough to live anywhere.

Everything here reproduces from the public bucket; the exact commands and
per-chunk data are in
https://github.com/rodriguescarson/labelscope/blob/main/findings/w128-129-evidence.md

[pmh47]

The segmentation is not perfect, indeed. We aim to segment up to the outermost recto inclusive. Closing since this is not an "issue", though of course a better segmentation would be nice (and will arrive soon).