-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide more friendly memory error for TiffImagingExtractor
#352
Comments
Note that (2) still wouldn't be viable in this users case since it would trick them into thinking everything is working until they attempt to create a file (initialization of the interface will work quickly without error on NeuroConv, meaning the GUIDE will let them input metadata and all that) Unless you know of how to load only a partial amount of the tiff file as an array (corresponding to the range of the |
There is a lot of functionality to do this in the library: Sadly it is not very well documented. I am pretty sure we could work it out though if it needs be However, there was this concerning thing a while back that puts me pause in that direction Which prompted: |
Exactly, I think best long term solution is to refactor the base tiff library to use something that is more memory friendly from the start https://github.com/denisecailab/minian had some good examples of this as I recall |
Good point! |
This is related to
catalystneuro/neuroconv#995
Check out the lines:
roiextractors/src/roiextractors/extractors/tiffimagingextractors/tiffimagingextractor.py
Lines 59 to 65 in 7592bba
Sometimes this will fail because there is not enough memory.
Two options:
https://github.com/catalystneuro/neuroconv/blob/ef656a0f13607ec661b091b9569e326fc91af8db/src/neuroconv/tools/spikeinterface/spikeinterface.py#L520-L548
Where we provide a friendlier error message and the suggestion that is currently a warning.
get_video
gets called. This is likely to be a small call and the error and will avoid most problems.I suggest 1 because is easier but I think memmaps should not be dangling with the object so I think 2 is better long-term. We had some problems because of this in spikeinterface.
The text was updated successfully, but these errors were encountered: