Quick high level feedback - can't we fold ozx into the existing iohub infrastructure, maybe something like:

iohub convert -i dataset.zarr -o dataset.ozx   # Pack into a `ozx` Zip archive
iohub info dataset.ozx  --ozx                      # check RFC-9 properties
iohub info dataset.ozx                          # FOV summary (auto-detects .ozx)

@ieivanov

A single-layer namespace works, but specialized groups make the purpose more explicit, I think this should be it's own ozx group.

iohub convert has been for converting TIFFs off the microscope into an OME-Zarr. This functionality doesn't really align 1-1 with this, as we are just repackaging an existing OME-Zarr store (chunks, shards, metadata and all). We're overloading the convert verb with that.

We'll eventually need a CLI to unzip a.ozx, so convert would also have to handle the reverse direction.

iohub info --ozx would swap the output entirely (FOV summary -> RFC-9 archive properties). Options / flags should provide parameters to commands, rather than specifying actions themselves. A flag refines how a command runs, not which operation runs.

RFC-9 is still in review and the surface of things we may find useful can grow (verify, list-entries, etc.) keeping those under iohub ozx umbrella isolates the namespace and can allow for more drastic changes with less side effects with the current convert.

Re: #408 (comment)

I disagree with just about everything in that comment. It looks like Claude is overfitting to what you want to do rather than thinking through the problem.

I don't think the user should worry about compressed vs uncompressed zarr stores - that's something iohub should be able to figure out. If RFC-10 comes up with yet another format (we've been thru v2, v3, now ozx..) we wouldn't make to make yet another entry point.

It's true that iohub convert currently work only in the direction of tiff to zarr, but that doesn't need to be the case. The CLI takes an input and an output, iohub can figure out the internals. We could extend that CLI to do v2 to v3 conversion - that's currently only possible thru the API, conversion from zarr to ozx or from ozx back to unzipped zarr. That seems very clean to me, we can figure out the implementation.

Re: iohub info - why not just print both FOV information and RFC-9 properties in the same call if the input dataset is .ozx format? Is a CLI group or an entry point necessary? If the RFC-9 properties are optional, they can be folded in the existing --verbose flag.

@ieivanov

We could extend that CLI to do v2 to v3 conversion - that's currently only possible thru the API, conversion from zarr to ozx or from ozx back to unzipped zarr.

if the RFC-9 properties are optional, they can be folded in the existing --verbose flag.

Yeah these makes sense to me we can do that.