`igneous mesh forge` overwrites in-place (and corrupts) input OME-Zarr metadata

[LucaMarconato]

This bug is closely related to #196, but I report it in a separate issue because I will give more detailed instructions on how to reproduce and also I will reference it in a different repo.

Expected behavior

Running igneous mesh forge on some labels OME-Zarr data should create a new mesh folder and in doing so it should not modify the input data.

Observed behavior

Some of the metadata of the input data is silently modified in-place, and in doing so it gets corrupted

To reproduce

Preparation

1. Download the dataset described here.
2. cd 20200812-CardiomyocyteDifferentiation14-Cycle1.zarr/B/03/0/labels/nuclei
3. run cat 0/.zarray, you should see this:

The bug

4. Now run igneous mesh forge . --queue my-queue && igneous execute -x -n 8 my-queue . This will fail as previously described in the related issue that I mentioned earlier Unable to run igneous mesh forge on OME-Zarr (v0.4) labels #196
5. Run cat 0/.zarray, now you will see the following, which shows that the input data has been modified in-place. In particular the chunks list now has different values! This corrupts the OME-Zarr dataset and leads to problem with parsing (I will give more details on this in a separate issue, but here the solution is to keep the input metadata untouched).

[LucaMarconato]

After digging into this I found that this line is the culprit

igneous/igneous/task_creation/mesh.py

Line 181 in 9b0a189

vol.commit_info()

[william-silversmith]

In order for Neuroglancer to know how to attach meshes to a segmentation layer, it adds "mesh": $mesh_directory to the info file. Then Neuroglancer knows where to find the mesh aspect. However, as there was no concrete specification or intention to allow meshing for zarr, this the behavior is undefined and untested at this time.

I believe Neuroglancer has enabled adding mesh layers independently of an image layer, so that is one possible way to handle zarr volumes gracefully.

[LucaMarconato]

Thanks for the details. Let me see if I understood correctly: when the backend is Zarr, the equivalent of the info file of the neuroglancer precomputed format is now the combination of some .zattrs and .zarray metadata files. Igneous will write the "mesh": $mesh_directory information in these files.

If that's the case, I think this is a good approach. If the neuroglancer precomputed format becomes part of the NGFF specs, then one can always update the location of where these metadata is stored.

[LucaMarconato]

I think the problem here is that while updating the mesh metadata, some other metadata (the one contained in .zarray) is overwritten. In particular vol.commit_info() ends up writing the default values that is computed from this code from cloudvolume (which are incorrect): https://github.com/seung-lab/cloud-volume/blob/74b3496d0d3a906cde6cac1d39fc3928360cfa93/cloudvolume/datasource/zarr/metadata.py#L342.

Addressing this should fix this bug as the rest of the metadata in .zarray seems not to be changing.

[william-silversmith]

Yea, the zarr2 implementation I have there is strictly for 5D arrays. In the new zarr3 implementation, it should be slightly more flexible (supporting variable sizes up to 5D).

[LucaMarconato]

Thanks for the update! I had missed your PR for zarr3, I will check it out 🚀