draft of multi-tiff multi-page imaging extractor

[bendichter]

This could be used on its own or used as a base type for more specialized extractors.

Depends on https://gin.g-node.org/CatalystNeuro/ophys_testing_data/pulls/21

[bendichter]

I see it might be been simpler to use a MultiImagingExtractor. I'll look at that now

[bendichter]

@CodyCBakerPhD I'm not sure what's going on here. This code runs perfectly well when I run it locally.

[bendichter]

Oh, right, because the test data hasn't been merged yet, so there are no extractors. I'll add a check for that.

[CodyCBakerPhD]

Here's what I propose for this approach:

i) A class called TiffFolderImagingExtractor: DirectoryPath that is the convenient approach for being friendly in handling a folder_path plus a parsing rule - basically what you have here - which I really like and think is the easier but more implicit approach, but is only guaranteed to work in situations we have tests for (which can rely a lot on users having really well organized and regular conventions)

ii) A class called MultiTiffMultiPageImagingExtractor that explicitly takes a file_paths: list[FilePath], and would have mainly programmatic usage (the user would use Python iteration to explicitly put together their list of files - such as a case where image contents are split across multiple subfolders). This could then be used as a fallback in any case where (i) might not work

I think each could have its own interface on NeuroConv, but GUIDE would only support (i)

While (ii) is technically possible in ROIExtractors out of the box by just making a list of TiffImagingExtractors and putting them in a MultiImagingExtractor, having a dedicated extractor could still be more convenient or findable

@bendichter WDYT?

[CodyCBakerPhD]

Some extra tests for this, at a minimum, should include cases of (a) multiple cameras/microscopes (the specifier for each device being something in the file name), and (b) multiple optic channels for a single one of those devices (the channel name/ID also being a part of the filename)

Not that I'm not saying the TiffFolderImagingExtractor should by default support multiple optic channels, or auto-detection of channel IDs from this pattern (that is a more complicated feature that could be done in a follow-up, or not at all); I just want to make sure that a single instance made from a pattern specification that restricts to only one channel from a folder that contains several correctly identifies list of files only for that channel

[bendichter]

Yeah I think these are both good ideas

[bendichter]

@CodyCBakerPhD the thing is I also want to create an extractor that handles a bunch of TIFF files that are not multi-page. What do you think of this naming scheme?

• one multi-page TIFF file: TiffImagingExtractor(sampling_rate=sampling_rate) (already exists)
• many 1-page TIFF files: MultiTiffImagingExtractor(file_paths=[...], sampling_rate=sampling_rate)
• several multi-page TIFF files: MultiTiffImagingExtractor(file_paths=[...], multi_page=True, sampling_rate=sampling_rate)

Then you could have FolderTiffImagingExtractor(folder_path, pattern, sampling_rate, multi_page) where FolderTiffImagingExtractor wraps MultiTiffImagingExtractor

[bendichter]

I think that would be the mosts straightforward syntax for the user. The issue is I don't really want to inherit from MultiImagingInterface for the "many 1-page TIFF files" case.

[CodyCBakerPhD]

Sounds good to me

Quick question - can the detail about a file being multi-page be autodetected or is it really something that needs to be known prior to reading the file?

[bendichter]

@CodyCBakerPhD I suppose you are right, we could auto-detect multi-page. I'll put together a draft of that. We might need to use __new__ for this