suite2p motion correction failures due to low SNR

[samiamseid]

New suite2p motion correction implemented in the ophys pipeline has reduced the effectiveness of our motion correction QC plots, to the point where operators must watch the 2P movie itself to determine if residual motion is present.

We suspect these failures are due to low SNR, which results in plots that look like this:

We need a new metric that might be able to capture erroneously "motion corrected" frames

[DowntonCrabby]

@samiamseid can you provide a bit more context for this? Do you know how often it occurs and can you provide a non-exhaustive list of experiments that are impacted by this?

[samiamseid]

Here is an example of a session on MESO2 where this occurred: http://mouse-seeks/qc/1120472890

6 out of 8 experiment planes in that session have this noisy motion correction plot.

A reason i bring this issue up is that hopefully we can create a quantitative metric for catching when motion correction has failed in this way. Currently, the procedure requires an operator to manually check the motion correction physio movie and decide whether or not motion correction has failed.

I could search through a bunch of QC reports and create a list of examples of this happening, but i think the real problem here is that the motion correction section needs general improvements. We need to better be able to differentiate between sessions where the motion correction process has failed, and cases were the data is not good enough for motion correction. It would also be nice to make this a quantitative metric instead of a qualitative one.

[DowntonCrabby]

@samiamseid I agree with wanting to separate out raw data (SNR) issues from processing issues (motion correction process failure). But I think in order to disambiguate these two issues we need a list of experiments that are impacted. We could then dig into the failures and try to separate out those issues by doing things like looking at SNR thresholds or at least trying to train a classifier to detect when these issues occur.

Are these failures flagged or tagged in mouse-seeks in any specific way that would give us a list to start with? Even if we have to manually curate that list it might be a good starting point.

[samiamseid]

Here are the sessions currently QCed as failed from the xy_motion_plot "\allen\programs\braintv\workgroups\ophysdev\OPhysCore\operator_files\sam_seid\DataAnalysis\ophys_session_log_xymotionplot_fails.csv"

[DowntonCrabby]

related to #23

[alandegenhart]

I wonder if this should be rolled into a larger issue to review the motion correction. I believe we're using Suite2p for MC, and some of the more recent data coming off of the DeepScope has odd wrapping effects that I'm ~99% sure are due to MC. I believe this is due to how the computed offsets are applied (e.g., in the spatial or Fourier domain), but I'd have to look into it in more detail to confirm.

[matchings]

@alandegenhart actually i think that suite2p motion correction is the current default in the processing pipeline. i just checked the lims directory for one experiment that mouse-seeks says is from DeepScope, and the file names do indicate that suite2p was used (ex: 1131799880_suite2p_registration_summary.png).

Here's the directory i was looking at:

\allen\programs\mindscope\production\omfish\prod0\specimen_1124090831\ophys_session_1131498234\ophys_experiment_1131799880\processed

[matchings]

also, here is where the code to run suite2p motion correction lives: https://github.com/AllenInstitute/ophys_etl_pipelines/tree/main/src/ophys_etl/modules/suite2p_registration

[alandegenhart]

@matchings updated my above comment to correct my typo. I'll open a new issue specifically focused on the wrap-around issue.

[alandegenhart]

The wrapping bug has been migrated to a separate issue: #33

[saskiad]

Can someone point me to the documentation for the decision to change motion correction to suite2p?

[DowntonCrabby]

@saskiad I don't remember there being a specific documentation surrounding that decision, but I do remember lengthy email chains and meeting notes in our emails.

If that specific document exists perhaps @LINZYC would know where it might be? I know Sarah was the PM but Linzy might know where handed off documents live.

I have attached the last email I have about it from 1/26/21. Re Visual Behavior data schedule.txt

[ghost]

@saskiad I don't remember there being a specific documentation surrounding that decision, but I do remember lengthy email chains and meeting notes in our emails.

If that specific document exists perhaps @LINZYC would know where it might be? I know Sarah was the PM but Linzy might know where handed off documents live.

I have attached the last email I have about it from 1/26/21. Re Visual Behavior data schedule.txt

@DowntonCrabby and @saskiad technology decisions are way above my pay grade. I think Sarah N was managing this working group at the time the decision was made and I think team Pika had o lot of input here?

[DowntonCrabby]

11/1/21 qc ops meeting: @DowntonCrabby to look at the frequency and descriptive statistics of when this occurs & provide info to team Pika or technology point person.

[DowntonCrabby]

Ideas to potentially systematically test when the motion correction fails: collect chunks of 1000 frames at dimmer and dimmer laser settings to see when motion correction fails, test at different depths and for different cre lines

BUT we really need a signal to noise ratio metric for this to be effective.

Related to #8 (SNR metric needed)

[matchings]

Closing. There is now a controlled language tag for low SNR causing motion correction failure in mouse QC