[Feature]: TIFF interface should take a list of files

[CodyCBakerPhD]

What would you like to see added to nwb-conversion-tools?

We've seen a couple of times now that people break up a single consecutive ophys recording into multiple TIFF files less than 2GB each (unsure why threshold of 2GB is important).

While we can certainly add each of these source files as a different series to the file (current behavior), it would be nice if the TiffImagingInterface could take a list of files intended to belong to the same consecutive series.

Is your feature request related to a problem?

No response

What solution would you like?

TiffImagingInterface should be altered to take file_paths: Union[FilePathType, List[FilePathType]] instead of just file_path: FilePathType

then it loops over the list and runs file operations to the same series (unsure if roiextractors.write_imaging would support this, however)

OR to maintain complete back-compatibility, can keep as file_path and just extend the annotation support to lists.

Do you have any interest in helping implement the feature?

Yes.

Code of Conduct

• I agree to follow this project's Code of Conduct
• Have you ensured this bug was not already reported?

[CodyCBakerPhD]

Depends on the MultiImagingExtractor that @weiglszonja is developing on roiextractors

[CodyCBakerPhD]

Also the 2GB file size and non-memory mappable nature is a direct result of an option in the ScanImage software. The memory map aspect can be resolved with the new ScanImageTiffExtractor (and soon, ScanImageTiffInterface, which has quite a bit of extra metadata from the normal TiffImagingInterface).

[h-mayorquin]

Now that catalystneuro/roiextractors#127 is merged how this would work out?
The idea would be to add a new interface that concatenates multiple TiffImagingExtractor objects?

[CodyCBakerPhD]

Yep. If a list of a single file path, then no need for MultiImaging under the hood. If more than one, splice them together with the MultiImaging so it behaves like a single ImagingExtractor.