Universal reader output base classes

[JoOkuma]

Hi, this is a work in progress for the base classes so we can advance with the universal reader.

I'm happy to iterate and get feedback from every to have a friendly interface.

I think we could be more restrictive than ome-zarr in some aspects; this would reduce the number of edge cases we need to worry about when implementing our own pipelines (e.g. fixing the shape to 5 and 6)

[JoOkuma]

@ziw-liu I reviewed what you mentioned about the __contains__, __delitem__ and other dictionary related methods.

This might be a case where the ClearControl (maybe TIFF too) API differs from the NGFFNode, it behaves more like the ImageArray.

I need to think a bit more about this, from my understanding a zarr FOV is NGFFNode because the ngff spec is not very rigid (the arrays can have arbitrary names) and the multi-scales, right?

[ziw-liu]

@JoOkuma We don't need __setitem__ and __delitem__ since these are read-only.

Also just to clarify I was talking about BaseFOVCollection. So we can do bool("name" in SomeFOVCollection()).

For BaseFOV I think it might be ok to ignore pyramids for the time being. (In theory TIFFs can have pyramids too.)

[JoOkuma]

@JoOkuma We don't need __setitem__ and __delitem__ since these are read-only.

Also just to clarify I was talking about BaseFOVCollection. So we can do bool("name" in SomeFOVCollection()).

For BaseFOV I think it might be ok to ignore pyramids for the time being. (In theory TIFFs can have pyramids too.)

Got it, I updated it accordingly.

[ziw-liu]

Also we should figure out how the consequent PRs should merge. It's fine if this one merges into main but if we keep the refactoring of readers atomic and distributed, asynchronously merging into main will result in a broken default branch.

Maybe make a new target branch (e.g. uapi-readers) once this is merged?

[JoOkuma]

Also we should figure out how the consequent PRs should merge. It's fine if this one merges into main but if we keep the refactoring of readers atomic and distributed, asynchronously merging into main will result in a broken default branch.

Maybe make a new target branch (e.g. uapi-readers) once this is merged?

I like the idea of having a separate branch.

I'm happy to take a few days next week and be done with it. I'm free after next Wednesday, but I'll need help with tiff because I'm not super familiar with it.

[edyoshikun]

This all LGTM! Thank you guys. I like the BaseCollectionFOV as an iterable that we can use to access individual positions.

A couple of points just to make sure this will behave as intended.

• For this universal reader, we will call BaseFOV[0,0,0] this will return a (1,1,1,Z,Y,X) 5D array?

[ziw-liu]

• For this universal reader, we will call BaseFOV[0,0,0] this will return a (1,1,1,Z,Y,X) 5D array?

My understanding is that it will behave as normal array slicing does. So YX (2D) in this case.

Edit: assuming you meant BaseFOV[0,0,0] instead of BaseFOV[0,0]

[talonchandler]

Looks great to me! I'm excited.

Thanks for pushing on this @JoOkuma.

[JoOkuma]

@ziw-liu, I renamed files from database_base.py to fov.py.

[ziw-liu]

Looks good!

[JoOkuma]

Thanks y'all.