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

Interpretation of spike "prob" #22

Open
kimtonyhyun opened this issue Oct 24, 2021 · 3 comments
Open

Interpretation of spike "prob" #22

kimtonyhyun opened this issue Oct 24, 2021 · 3 comments

Comments

@kimtonyhyun
Copy link

Hi again.

Since we last spoke, I have been applying CASCADE to my two-photon Ca2+ imaging datasets and generally have been very pleased with the transformation of Ca2+ fluorescence traces into inferred spike rate traces. CASCADE captures many of the intuitions that I have with regards to the dynamics of GECIs and how they relate to underlying electrical activity of the neuron.

This time, I wanted to ask about the interpretation of the spike_prob output of CASCADE. The FAQ of the "Calibrated_spike_inference_with_Cascade" demo script states:

The output spike_prob is the estimated probability of action potentials (spikes), at the same resolution as the original calcium recording. If you sum over the trace in time, you will get the estimated number of spikes. If you multiply the trace with the frame rate, you will get an estimate of the instantaneous spike rate. Spike probability and spike raes can therefore be converted by multiplication with the frame rate.

Thus, my initial interpretation was that the value of spike_prob for a frame was the "probability" that a spike had occurred within that frame. As a "probability", I expected that the value would be constrained to be between 0 and 1.

However, during my use of CASCADE on my data (technical details at the end of the post), I observed that it's possible for the spike_prob value to be greater than 1 for some frames. Here's an example:
image

So first, I wanted to ask if you thought my interpretation of spike_prob is wrong, and whether you thought that values of spike_prob that exceed 1 was due to an error in my use of the algorithm.

I then started thinking about the interpretation of spike_prob. The FAQ states that:

If you multiply the trace with the frame rate, you will get an estimate of the instantaneous spike rate. Spike probability and spike raes can therefore be converted by multiplication with the frame rate.

(By the way, typo on "rates".)

If spike_prob, as a probability, is constrained to be between 0 and 1, then this implies that the maximum spike rate that can be predicted by CASCADE is the imaging frame rate (since it would be frame rate multiplied by prob=1). This, however, didn't seem right to me, since a neuron could easily spike more rapidly than the imaging frame rate. For example, if one were imaging at 5 Hz, i.e. with 200 ms frame periods, a neuron can definitely spike more than once within that frame.

Thus, I started to wonder whether the spike_prob variable should be interpreted not as a "probability" that a spike occurred within that frame, but instead the expected number of spikes in that frame. This way, I think the output retains the stated properties of spike_prob (e.g. sum the trace in time to get total # of spikes; multiply by the frame rate to get the instantaneous spike rate), but without the intuition that the values should be constrained to lie between 0 and 1. I wonder what you think?

Here are some technical details on my use of CASCADE (i.e. in the image above):

  • Imaging medium spiny neurons in the striatum expressing jGCaMP7f;
  • Ca2+ movie was acquired at 30 Hz (using a standard 8 kHz resonant scanner);
  • I binned every pair of frames to obtain Ca2+ traces at 15 Hz (for SNR purposes and other technical reasons);
  • I used the "Global_EXC_15Hz_smoothing200ms" model.

I'd be happy to share the DFF traces with you if that would help the discussion.

Thanks again for sharing CASCADE!

@PTRRupprecht
Copy link
Member

Hi Tony,

Thanks a lot for your very clear report and your feedback! Your example recording looks really good to me, given that it comes probably from 2P GRIN lens imaging!

I think there is no error from your side, both in the application and in the interpretation of the algorithm.

Your intuition that the output of the algorithm should be more precisely interpreted as expected number of spikes is correct. It is, therefore, strictly speaking, wrong to use the term spike probability. I decided to use spike probability because I thought the difference between expected number of spikes and expected probability of a spike would not make a difference to most users ... but I can see how this can result in confusion.

To ensure backwards compatibility and consistency with the paper, I would prefer to leave spike probability, but I will add an explanation that reflects your comment. And I will also leave your issue un-closed for the moment, so it has more visibility for others who might run into the same confusion.

Let me know if you find other issues!

Best wishes,

Peter

P.S. Thanks for spotting the typo as well!

PTRRupprecht added a commit that referenced this issue Oct 24, 2021
Update Readme, according to issue #22
@kimtonyhyun
Copy link
Author

Hi Peter,

Thanks for the quick response! I get why you had originally chosen "spike probability", for simplicity. For future users, I think a FAQ entry like "Can the spike probability be greater than 1?" would probably be helpful. (And yep, the 2P recording was performed through a GRIN lens.)

-Tony

@PTRRupprecht
Copy link
Member

That's a good suggestion. I have added such an entry. I some point in the future I will go through the entire FAQ again and check whether it is still consistent.

Peter

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

2 participants