Description
Is your feature request related to a problem? Please describe.
For very large whole slide images, even loading one image (all the channels) can cause memory errors. Here, the memory issues happen during preprocessing, which is a step we haven't optimized for memory (we have mainly been working on optimizing training by subsetting pixels).
Describe the solution you'd like
A quick solution is to first crop large images into smaller "fovs", and run those smaller images through Pixie normally. Since Pixie doesn't rely on spatial information, cropping the images first shouldn't make a difference. Once the pixel phenotype maps are generated, we can stitch these back together to the original size. We can have a utility notebook that users can run before and after Pixie to crop/decrop their images.
Describe alternatives you've considered
We have discussed additional solutions, such as reading in patches of images or reading in one channel at a time. These options will take longer to implement - we will continue discussing these alternatives.
Additional context
One consideration is the size of the crops. Perhaps we can just start with 1024 x 1024 crops as a default (and this can be a parameter that users can change). We will also need to think about the logic of re-stitching - we need some way of keeping track of where each crop came from to stitch them back together (maybe specifying "RxCx" in the filename? Or just number them like "crop1" through "cropx" and then keep track of the number of rows/columns somehow? Open to other suggestions).