Consider a mode to split series into individual TIF files

[DavidStirling]

A recurring problem for some users has been that HCS datasets can produce huge OME-TIFF files which are tricky to work with.

It'd be nice to have the option to split an input zarr into a distinct .tif file per series. I could imagine that this could take the form of a --series argument that allows the user to specify which series to convert. How individual series should be specified is an open question (numerical index or path?).

An alternative might be a --split_series flag which would trigger individualised series export. That could involve spitting out TIF files with sequential names e.g. my_file_s{index}.ome.tif. It's perhaps a bit more messy but saves the user needing to re-run the application for every series in the zarr.

[joshmoore]

Would having --split activate full bfconvert-style output pattern parsing be an option?

[melissalinkert]

It's not not an option, but obviously more involved than what https://github.com/glencoesoftware/raw2ometiff/pull/80 does right now. If we have an immediate need for splitting individual channels, timepoints, etc. into separate files or embedding additional metadata into the file names, then I can work on that. Otherwise, I'd rather focus on what's in #80 for now so that @DavidStirling is unblocked.

For reference, bfconvert output patterns are documented here (between -crop and -compression): https://docs.openmicroscopy.org/bio-formats/6.9.1/users/comlinetools/conversion.html. Implementation is here: https://github.com/ome/bioformats/blob/develop/components/formats-api/src/loci/formats/FormatTools.java#L1109

[joshmoore]

then I can work on that. Otherwise, I'd rather focus on what's in #80 for now so that @DavidStirling is unblocked.

Definitely understood. Guess I'm most concerned about the API stability. I guess if/when we decided to add the bfconvert like behavior, --split could be deprecated.