Avoid hard-coded field-of-view path "0"

[aeisenbarth]

Fixes #248

The current code assumes image paths under a well always match field of view indices, especially that "0" exists. However, the NGFF spec allows alphanumeric paths.

This change looks up the actual image path from the first well. This should not have a performance impact since the first well's .zattrs is read anyways. It is still assumed all wells have the same first image path (which the previous code did as well). In that case, an array of zeros is read (as previously).

[will-moore]

Looks good, and works for me. Is this still a [WIP]?
Don't know why the docs build failed, but it's not because of this PR

[aeisenbarth]

I still wanted to look into how to cover this by tests. Maybe by parametrizing test_multiwells_plate with fields = map(str, range(3)) and fields = ["img1", "img2", "img3"].

[aeisenbarth]

I added a test. Since failed image lookups fail gracefully and return zeros, I had to change the image values of the test arrays to something non-zero.

The alphanumeric test case failed on master and succeeds on this branch.

[codecov]

Codecov Report

Patch coverage is 33.33% of modified lines.

❗ Current head 4455b89 differs from pull request most recent head 1b4601d. Consider uploading reports for the commit 1b4601d to get more accurate results

Files Changed	Coverage
ome_zarr/reader.py	33.33%

📢 Thoughts on this report? Let us know!.

[will-moore]

Hi @aeisenbarth can you merge in origin/master which should fix the build failures above