Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update reader.py to v0.3 #89

Merged
merged 32 commits into from
Aug 25, 2021
Merged

Update reader.py to v0.3 #89

merged 32 commits into from
Aug 25, 2021

Conversation

constantinpape
Copy link
Contributor

Changes for upcoming multiscale spec v0.3

@constantinpape constantinpape marked this pull request as draft June 11, 2021 21:28
@constantinpape
Copy link
Contributor Author

constantinpape commented Jun 14, 2021

I have also removed the cv2 dependency here now, see discussion in #90.
However, I think it makes sense to wait with this PR on #80 and include these changes (and also wait on #91).
@joshmoore do you have an ETA on #80?

Edit: We should also add a test for the nearest neighbor downscaling here.

@joshmoore
Copy link
Member

re: 36e37cf cc: @will-moore and @erindiel

@joshmoore
Copy link
Member

do you have an ETA on #80?

@constantinpape : I'll re-check it now, but I assume it can go in. It may not be 100%, but having a third class to compare to may actually help get the API right.

@constantinpape
Copy link
Contributor Author

@constantinpape : I'll re-check it now, but I assume it can go in. It may not be 100%, but having a third class to compare to may actually help get the API right.

Ok. I think it's best if you just merge #80 when you think it should work.
I will then adapt this PR to the changes and we can discuss any potential issues and potentially do changes here.

@joshmoore joshmoore mentioned this pull request Jun 14, 2021
3 tasks
@codecov
Copy link

codecov bot commented Jul 7, 2021

Codecov Report

Merging #89 (93d0964) into master (a67ed4f) will increase coverage by 0.93%.
The diff coverage is 94.44%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #89      +/-   ##
==========================================
+ Coverage   69.37%   70.30%   +0.93%     
==========================================
  Files          11       11              
  Lines        1035     1044       +9     
==========================================
+ Hits          718      734      +16     
+ Misses        317      310       -7     
Impacted Files Coverage Δ
ome_zarr/reader.py 58.43% <85.71%> (+0.27%) ⬆️
ome_zarr/format.py 94.52% <100.00%> (+0.40%) ⬆️
ome_zarr/io.py 83.03% <100.00%> (+0.89%) ⬆️
ome_zarr/scale.py 60.57% <100.00%> (+6.29%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a67ed4f...93d0964. Read the comment docs.

@constantinpape
Copy link
Contributor Author

constantinpape commented Jul 7, 2021

@joshmoore I finally have some time again to look into this.
The following things are left to do for this PR:

  • Fix the precommit; I had a quick look, but I don't know what's going wrong there.
  • Add tests for older format versions (multiscales 0.1, 0.2), add roundtrip tests that make sure that the data written is read back correctly
  • Fix issues for 0.1 (0.2?); I can see that it does not work properly when checking visually with Enable opening spec v3 napari-ome-zarr#8. Might be related to issues with nested vs. flat directory store.
  • Update write_multiscales and Scaler to work for <5d.
  • Investigate issues with ome-zarr info / ome-zarr download. The tests seem to pass, BUT when I try it with this PR I get 404s for https://s3.embassy.ebi.ac.uk/idr/zarr/v0.1/6001240.zarr/, whereas this works on main.

dsize=(sizeY // self.downscale, sizeX // self.downscale),
interpolation=cv2.INTER_NEAREST,
)
output_shape=(sizeY // self.downscale, sizeX // self.downscale),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@will-moore : can you check that this matches your cv2 use cases?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I will double check this and see if we can cover it by some test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added tests for the scaler in e07194d. Judging from the results the current implementation is correct.

@will-moore
Copy link
Member

@constantinpape with ome/napari-ome-zarr#9 I can use this PR to open v0.3 images in napari (tested with 1 image), but this expects the axes in the metadata, so it needs a small addition to your PR:

e.g. this works:

diff --git a/ome_zarr/reader.py b/ome_zarr/reader.py
index 0d4019d..d9f5043 100644
--- a/ome_zarr/reader.py
+++ b/ome_zarr/reader.py
@@ -273,6 +273,7 @@ class Multiscales(Spec):
             axes = tuple(multiscales[0].get("axes", ["t", "c", "z", "y", "x"]))
             if len(set(axes) - axes_values) > 0:
                 raise RuntimeError(f"Invalid axes names: {set(axes) - axes_values}")
+            node.metadata['axes'] = axes
             datasets = [d["path"] for d in datasets]
             self.datasets: List[str] = datasets
             LOGGER.info("datasets %s", datasets)

@joshmoore
Copy link
Member

joshmoore commented Aug 6, 2021

Hi @constantinpape, do you have a feeling when you want to try to get back to this PR? We have a hand-full that are all interlinked (below) and can start getting pre- versions ready, but just want to time things right.

cc: @manzt

@constantinpape
Copy link
Contributor Author

Hi @joshmoore,
yes I will try to get back to this next week.
The last weeks were more busy with modelzoo related things than expected so I didn't have time for this; but I should be free to work on ome.zarr related things on Monday.

Co-authored-by: Will Moore <[email protected]>
@constantinpape
Copy link
Contributor Author

I found another issue with the CLI: files in format v0.3 are downloaded with flat instead of nested chunks:

$ ome_zarr download https://minio-dev.openmicroscopy.org/idr/v0.3/idr0077-valuchova-flowerlightsheet/9836842.zarr
downloading...
   9836842.zarr
to .
[########################################] | 100% Completed |  0.3s
[########################################] | 100% Completed |  0.2s
[########################################] | 100% Completed |  0.2s
[########################################] | 100% Completed |  0.6s
[########################################] | 100% Completed |  0.9s
[########################################] | 100% Completed |  1.8s
$ ls 9836842.zarr/0/
0.0.0  1.0.0  2.0.0  3.0.0

@constantinpape
Copy link
Contributor Author

@will-moore @joshmoore I found the issue with ome_zarr info; it was just a typo.

The problem with ome_zarr download seems to come when the zarr arrays are serialized with data.to_zarr here. So this looks like a dask or zarr-python issue, which might be solved when the issues with the zarr dimension-separator are fixed.

I think this PR is good to be merged, pending minor TODOs:

  • Mark failing tests as expected failures
  • Can I ignore the pre-commit failures? If not I would need some help in fixing this as I don't understand what's going on there.

Let me know what you think.

@joshmoore
Copy link
Member

👍

So this looks like a dask or zarr-python issue, which might be solved when the issues with the zarr dimension-separator are fixed.

Possibly, but a heads up that I ran into something similar with trying to use zarr.convenience methods for converting from flat to nested (for example). Some internal methods don't go through the store themselves and instead copy internals directly leading to possible issues.

  • Can I ignore the pre-commit failures?

Sure. I can fix those.

  • Mark failing tests as expected failures

👍 If you can get a state that's green as you expect things to work, then we can deal with everything else downstream.

@constantinpape
Copy link
Contributor Author

+1 If you can get a state that's green as you expect things to work, then we can deal with everything else downstream.

Ok, it's almost there; the only thing that's sometimes failing is the test for ome_zarr info, I assume due to too many requests with all the separate test runs. I would suggest to ignore this, as we can decrease the number of test runs significantly once vispy (and in consequence PyQT / PySide) is removed from the dependencies.

@constantinpape
Copy link
Contributor Author

All green except the pre-commit :).

tests/test_cli.py Outdated Show resolved Hide resolved
@constantinpape
Copy link
Contributor Author

This looks good now! @joshmoore do you want to draft releases here and in napari-ome-zarr before we merge this one?

@constantinpape
Copy link
Contributor Author

Just fyi, I am on vacations for the next two weeks, feel free to merge whenever this fits or change things if necessary. And looking forward to working v0.3 python libraries when I am back ;).

With the 2.9 series of zarr-python, both dimension
separators should now be functional. This will let
us remove the spec restriction in future versions.
@joshmoore
Copy link
Member

Pushed a commit to test zarr 2.9.x. Otherwise, I think this is ready to go but just in case there are any last thoughts, now is the time.

@joshmoore
Copy link
Member

Moving forward with 0.0.22.

@joshmoore joshmoore merged commit 62b49da into ome:master Aug 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants