Skip to content
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

1P motion correction parameters #1418

Open
melkalliny opened this issue Oct 31, 2024 · 0 comments
Open

1P motion correction parameters #1418

melkalliny opened this issue Oct 31, 2024 · 0 comments

Comments

@melkalliny
Copy link

melkalliny commented Oct 31, 2024

Your setup:

  1. Operating System (Linux, MacOS, Windows): Windows 10
  2. Hardware type (x86, ARM..) and RAM: x64, 48GB RAM
  3. Python Version (e.g. 3.9): 3.10
  4. Caiman version (e.g. 1.9.12): 1.9.15
  5. Which demo exhibits the problem (if applicable): Modified version of demo_motion_correction
  6. 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.
Screenshot 2024-10-31 162838

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant