Closed bendichter closed 2 years ago
An excellent request - very surprised this isn't already supported. I'll get on this today along with the other roiextractors improvements.
~100
Also, I'd vote for n_frames_stub=largest_axis_length+1
to avoid the NWBInspector check_data_orientation
from getting raised on stub files.
@bendichter Oh, I forgot - so, stubbing is something done at the tools
+DataInterface
level on NWBCT, it's not a native argument to extractor objects either here or on SpikeInterface.
For all of the extractors here, everything except the non-memmap TIFF should have fully lazy access, so a stub
option for read operations here would only be for that case (also not entirely sure how to go about it through the tifffile
library context used to call as_array
).
Is that what you wanted to try to get working to make testing faster? Or just the option on the NWBCT side?
Separate usage: Technically we could support the stub
option here for all of our static methods for writing back to proprietary formats, but NWB is usually what we care about most, and that's not handled here.
Ahhh but as I look into that it seems that what is needed at the roiextractors
level is either
a) SubImagingExtractor
+ SubSegmentationExtractor
OR the new SpikeInterface approach
b) .frame_slice()
method of the base class.
I prefer (b), how about you @bendichter?
Let's use the new method to keep up with the latest from SpikeInterface
A stub option should limit the conversion to the first ~100 frames so that conversions can be tested quickly without reading/writing all of the data.