You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
Appreciate your time & comments.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: