search

catalystneuro / roiextractors

Python-based module for extracting from, converting between, and handling optical imaging data from several file formats. Inspired by SpikeInterface.
https://roiextractors.readthedocs.io/en/latest/index.html
BSD 3-Clause "New" or "Revised" License
11 stars 7 forks source link

draft of multi-tiff multi-page imaging extractor #323

Open bendichter opened 3 months ago

bendichter commented 3 months ago

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 commented 3 months ago

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

bendichter commented 3 months ago

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

bendichter commented 3 months ago

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

CodyCBakerPhD commented 3 months ago

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?

bendichter commented 3 months ago

Yeah I think these are both good ideas

bendichter commented 3 months ago

@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?

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

bendichter commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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