Draco decoding error for some mesh chunks

[philippotto]

Context

Precomputed meshes (computed on mapping 0) with some other mapping (maybe this is unrelated to the mapping)

See #7001 (comment) where this was protocolled first, but it's independent of that PR.

Expected Behavior

all chunks should be decoded with no error.

Current Behavior

some chunks cannot be decoded by the draco library on the front-end.

Steps to Reproduce the bug

Generic:

1. open l4dense_motta_et_al_dev_v2 in view mode (on a dev instance)
2. enable mapping 80
3. load a precomputed mesh for the segment at 2905, 4566, 1786 (should be id 355)
4. inspect the console which logs an error for one chunk

Tailored repro:
Also see this dev instance where only the problematic chunk is fetched:

• visit https://provokemeshdecodingerror.webknossos.xyz/datasets/sample_organization/l4dense_motta_et_al_dev_v2/view#2816,4353,1792,0,1.3
• enable mapping 80
• load a mesh (will only load one chunk for segment 355)

---

I suspect that this is a back-end problem as I couldn't find anything unusual in the front-end (and we simply hand the buffer to the draco decoder). The requested and received byte sizes match, but I don't have more insights unfortunately. The draco buffer seems to be recognized as such (otherwise, another error would be thrown earlier), but the format seems to be off.

One thing I noticed is that the failing chunk might be empty anyway (I didn't see obvious holes in the mesh, at least).

[fm3]

Might be worth comparing this with the export mesh task from voxelytics (and see whether they use the same byte range and read the same byte content from it before passing it to the decoder)

[daniel-wer]

I had a look at this issue, but didn't make much progress so far. Since this is an oversegmentation mesh file, it would be very helpful to get to know the segment ID of the respective undecodable mesh. @fm3 Do you think you could find that out in the backend using the test branch Philipp prepared? Once we know the segment ID, I could check whether the export mesh task is able to export/decode the respective mesh.

[fm3]

The undecodable chunk at byteOffset: 3920109208, byteSize: 1818, position: [1024, 5120, 1024] belongs to segment 4125772.

The segment has three chunks (as listed by the backend):

MeshChunk(
    Vec3Float(1024.0,5120.0,1024.0),
    3920109208,
    1818
),
MeshChunk(
    Vec3Float(2048.0,4096.0,1024.0),
    3920111026,
    1754
),
MeshChunk(
    Vec3Float(2048.0,5120.0,1024.0),
    3920112780,
    9736
)

[fm3]

I am in fact getting

$ python voxelytics/connect/tools/export_meshes.py --meshfile meshfile_dir --lod 0 --output_dir mesh_export --meshfile_format v3_neuroglancer --segment_ids 4125772
2023-07-05 09:49:21 PID=20748 CRITICAL root Exiting due to error:
Traceback (most recent call last):
  File "voxelytics/connect/tools/export_meshes.py", line 121, in <module>
    export_meshes_by_ids_v3(
  File "voxelytics/voxelytics/connect/tools/export_meshes.py", line 76, in export_meshes_by_ids_v3
    mesh = meshfile.get_stl_for_segment(np.uint64(segment_id), lod)
  File "voxelytics/connect/artifacts/meshfile_artifact.py", line 470, in get_stl_for_segment
    for mesh, bounding_box in self.get_mesh_chunks_with_bounding_box(
  File "voxelytics/connect/artifacts/meshfile_artifact.py", line 458, in get_mesh_chunks_with_bounding_box
    draco_mesh = DracoPy.decode(
  File "src/DracoPy.pyx", line 231, in DracoPy.decode
  File "src/DracoPy.pyx", line 216, in DracoPy.raise_decoding_error
DracoPy.FileTypeException: Input mesh is not draco encoded

It works with other segment ids.

So I would conclude that this is not a webknossos problem.

[daniel-wer]

Recomputing the mesh file with the newest version of Voxelytics fixed the issue. Since there were quite a few mesh related fixes since October 2022 (computation date of the erroneous mesh file) it's likely that this was caused by a bug in Voxelytics that has been fixed in the mean time.

I replaced the mesh file with the new working version and the full agglomerate 355 mesh can be loaded without any errors, now: link