Computational toolbox for large scale Calcium Imaging Analysis, including movie handling, motion correction, source extraction, spike deconvolution and result visualization.
Operating System (Linux, MacOS, Windows): Windows 10
Hardware type (x86, ARM..) and RAM: x64, 48GB RAM
Python Version (e.g. 3.9): 3.10
Caiman version (e.g. 1.9.12): 1.9.15
Which demo exhibits the problem (if applicable): Modified version of demo_motion_correction
How you installed Caiman (pure conda, conda + compile, colab, ..): pure conda
I've motion corrected and processed many 1P recordings successfully but am having difficulty with sessions coming out of our latest experiment (2 short examples w/ plenty of motion, cropped prior to motion correction: https://drive.google.com/drive/folders/1VOEStOvNxZc41GdYHB0CE1Wz7ZLTLNjx?usp=sharing). I've tried a wide range of gSig_filt, strides, and overlaps, but here is an example set of parameters we've used for example1.
motion correction parameters:
motion_correct = True # flag for performing motion correction
pw_rigid = False # flag for performing piecewise-rigid motion correction (otherwise just rigid)
gSig_filt = (7,7) # size of high pass spatial filtering, used in 1p data
max_shifts = (24, 24) # maximum allowed rigid shift
strides = (32, 32) # start a new patch for pw-rigid motion correction every x pixels
overlaps = (16, 16) # overlap between pathes (size of patch strides+overlaps)
max_deviation_rigid = 3 # maximum deviation allowed for patch with respect to rigid shifts
border_nan = 'copy' # replicate values along the boundaries
There is rigid motion being picked up (this is for example1; for example2 it picks up less) - but performance still isn't good.
For this experiment, we did switch to an HFYU encoder when saving data, due to Bonsai not supporting video saving in FFV1. I don't think that should be an issue since it's also lossless and I've tried motion correcting the same videos after reencoding to FFV1 w/ no difference. But just in case you think it could have an impact, example1 is from a reencoded FFV1 video and example2 from an HFYU video.
Finally, PW-rigid is perhaps adding some slight improvement, but ultimately, the motion still ends up substantially uncorrected.
Your setup:
I've motion corrected and processed many 1P recordings successfully but am having difficulty with sessions coming out of our latest experiment (2 short examples w/ plenty of motion, cropped prior to motion correction: https://drive.google.com/drive/folders/1VOEStOvNxZc41GdYHB0CE1Wz7ZLTLNjx?usp=sharing). I've tried a wide range of gSig_filt, strides, and overlaps, but here is an example set of parameters we've used for example1.
motion correction parameters: motion_correct = True # flag for performing motion correction pw_rigid = False # flag for performing piecewise-rigid motion correction (otherwise just rigid) gSig_filt = (7,7) # size of high pass spatial filtering, used in 1p data max_shifts = (24, 24) # maximum allowed rigid shift strides = (32, 32) # start a new patch for pw-rigid motion correction every x pixels overlaps = (16, 16) # overlap between pathes (size of patch strides+overlaps) max_deviation_rigid = 3 # maximum deviation allowed for patch with respect to rigid shifts border_nan = 'copy' # replicate values along the boundaries
There is rigid motion being picked up (this is for example1; for example2 it picks up less) - but performance still isn't good.
For this experiment, we did switch to an HFYU encoder when saving data, due to Bonsai not supporting video saving in FFV1. I don't think that should be an issue since it's also lossless and I've tried motion correcting the same videos after reencoding to FFV1 w/ no difference. But just in case you think it could have an impact, example1 is from a reencoded FFV1 video and example2 from an HFYU video.
Finally, PW-rigid is perhaps adding some slight improvement, but ultimately, the motion still ends up substantially uncorrected.
Appreciate your time & comments.