add compressor option to write image

[satra]

this proposes a change to the write_image api to allow compressors. this is now more general to pass any options to the create dataset function and should handle multilevel options.

closes #160

• Write some tests

[codecov]

Codecov Report

Merging #161 (0d9e868) into master (3e3327c) will increase coverage by 0.46%.
The diff coverage is 90.00%.

@@            Coverage Diff             @@
##           master     #161      +/-   ##
==========================================
+ Coverage   83.53%   83.99%   +0.46%     
==========================================
  Files          12       12              
  Lines        1354     1362       +8     
==========================================
+ Hits         1131     1144      +13     
+ Misses        223      218       -5     

Impacted Files	Coverage Δ
ome_zarr/writer.py	98.17% <90.00%> (+1.85%)	⬆️
ome_zarr/format.py	98.17% <0.00%> (+1.35%)	⬆️

---

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 3e3327c...0d9e868. Read the comment docs.

[joshmoore]

Thanks for this, @satra. Could you sign and return the OME CLA as described in https://ome-contributing.readthedocs.io/en/latest/cla.html?

[joshmoore]

Implementation seems simple enough, though we should probably get it integrated into a test.

As a side note, I do remember, however, not being completely happy with the chunks argument since conceivably one might want different settings per pyramid level. The same might apply here.

I don't know if you, @satra, or anyone else at this point has a clear alternative that would keep this method cleaner. Options that come to mind include:

• passing all arguments as key words similar to fsspec's storage_options
• and/or passing a callback function which review is given the path, the dataset, as well as the resolution level

Happy to keep pondering those after this PR though.

[sbesson]

Brainstorming on the API questions raised in #161 (review), a solution along the lines of storage_options feels appealing to me as this would allow any of the options available in create_dataset to be specified via this library.

Do we expect the dataset level to be the finer level of granularity for these storage options? In this case, I assume an option would be either to support a simple dictionary (and use it for each dataset) or a list of dictionaries of size matching the size of pyramid which would allowing to specify options at the individual dataset level.

[satra]

@sbesson - updated this to use storage_options.

[sbesson]

Thanks @satra. We are making progress towards ome-zarr 0.3.0 which should include OME-NGFF 0.4 support. It would be great to make this new storage options available at the same time.

At minimum, could a unit test be added that covers the compression scenario? As a bonus, it looks like your storage_options also cover the per-resolution chunks feature mentioned in #161 (review). I suspect we will want some tests covering this scenario but this can happen as a follow-up PR depending on time.
Also could you return the CLA as mentioned in #161 (comment).

[sbesson]

This raises the question of whether we would like to deprecate the explicit chunks argument and only rely on the storage_options dictionary moving forward.

[satra]

if it's deprecated, i would suggest giving it a couple of cycles and perhaps add a deprecation warning with the next release. but leave this up to you.

[sbesson]

Fair enough, we can gain knowledge about the storage_options in the upcoming 0.3.x and schedule the deprecation of chunks for 0.4. I'll create an issue

[sbesson]

Thanks for the test @satra. All looks good from my side. Merging and we will aim to get this as a public release in the upcoming days

[sbesson]

Fair enough, we can gain knowledge about the storage_options in the upcoming 0.3.x and schedule the deprecation of chunks for 0.4. I'll create an issue