melissalinkert
commented
11 months ago db85137 does switch the whole progress API to using chunk instead of tile. I think in this context chunk makes more sense and is more consistent with Zarr and OME-NGFF spec terminology. Happy to hear other thoughts though. I intentionally did not try to switch all use of tile in Converter to chunk, as that would be a large change outside the intended scope of this PR.
This should make it easier for a listener implementation to use a single progress bar for the whole conversion, instead of one progress bar per resolution (as discussed with @DavidStirling).
Updating the notifications in Converter requires pre-calculating tile and resolution counts before starting to write tiles, but that also means failing faster if the pixel type and downsampling (or other options) are incompatible.
raw2ometiff will need similar updates once we're happy with this, as it consumes the progress listener API and implementations here. Might be a case for a 0.8.0-rc1 that includes this, so we can more easily test with all of the downstream applications.