Image reading entry point

[ziw-liu]

This PR removes ImageReader (previously WaveorderReader) as the extra abstraction layer, and replaces it with a top-level imread function that returns a instance of a children of ReaderBase. API of the reader object would stay the same, except for the simplification from what would previously be reader.reader.attr to reader.attr.

Start to address #40.

[AhmetCanSolak]

great starting point and it addresses certain aspects of #40 but this will not be enough to close it.

[ziw-liu]

great starting point and it addresses certain aspects of #40 but this will not be enough to close it.

Thanks! I removed #40 from the auto-closing list. This might actually help keep this PR smaller than a full-scale refactor.

[mattersoflight]

The imread interface is intuitive. I suggest testing this interface via convert CLI that converts some example datasets of each type into ome-zarr. I think you have come across all TIFF formats, but not PTI zarr format. You can find multiple example datasets here: https://zenodo.org/record/5951978#.Y_mKt7TMKrM.

I find that the current info CLI has some bugs. I reported in #21.

[ziw-liu]

I suggest testing this interface via convert CLI that converts some example datasets of each type into ome-zarr.

To keep PRs atomic, I suggest that we implement the convert feature and its CLI option in a separate PR focused on #41.

[mattersoflight]

To keep PRs atomic, I suggest that we implement the convert feature and its CLI option in a separate PR focused on #41.

👍🏼 the entry points can be tested and refined while working on #41.

[ziw-liu]

@mattersoflight I took a look at uPTI datasets. They seem to be exactly OME-Zarr stores except for extra calibration arrays in raw datasets (not in processed datasets). So if imread is called upon a uPTI store, it can load the positions as arrays with the generic v0.1 OME-Zarr reader. Dispatching to UPTIReader however is tricky, in that there is not a consistent pattern in file names or metadata to determine if a store is a uPTI dataset. Can you point me to the specification of this file format so I can learn more?

Edit: a work around is to dispatch to UPTIReader when data_type='upti' is specified in imread(). But this is more manual.
Edit: ⬆️ this is the current behavior. I had some confusion about what the UPTIReader aims to achieve: I thought it also handles Zarr, but it only handles raw-raw data in TIFF, not the '_raw' datasets in the Zenodo link.

[mattersoflight]

They seem to be exactly OME-Zarr stores except for extra calibration arrays in raw datasets (not in processed datasets). So if imread is called upon a uPTI store, it can load the positions as arrays with the generic v0.1 OME-Zarr reader.

That's awesome!

I had some confusion about what the UPTIReader aims to achieve: I thought it also handles Zarr, but it only handles raw-raw data in TIFF, not the '_raw' datasets in the Zenodo link.

Thanks for that clarification. I'd forgotten how the code evolved. The data acquired with PTI is indeed in TIFF format.

Examples: CompMicro/rawdata/hummingbird/LiHao/20210120_A549_RSV_20x and CompMicro/rawdata/hummingbird/LiHao/20210226_uPTI_20x_Zebrafish.

Please test if the current reader can convert this data or not. Great if that works. We can handle any fixes in a separate PR. We also need to update documentation and refactor code in waveOrder to depend on iohub to enable data i/o for PTI.

[ziw-liu]

Please test if the current reader can convert this data or not.

@mattersoflight Just a reminder that this PR does not feature a converter. That's to be added in #76.