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

Feature request: Adding support for saving CNMFE results in Caiman #292

Open
EricThomson opened this issue Feb 22, 2024 · 0 comments
Open

Comments

@EricThomson
Copy link

Hi this is related to #287 , which was about saving CNMF results in Caiman.

I started on CNMFE this morning, and everything from that issue carries over. Things all work great, we have mapping from:

  • Neuropil -- estimates.C (denoised calcium traces)
  • Deconvolved - estimates.S (spike counts estimated from deconvolution algo)
  • DfOverF - estimates.F_dff (delta f over f)

As before, awesome it works great. The main concern is the naming as we already discussed, and it might be nice to have both denoised, and raw traces (C+YrA) instead of just denoised traces.

Also, with CNMFE, the model of background activity is different. In CNMF, it is just captured in low-rank spatial b (spatial) and f (temporal) components, and they are relatively simple (2p yippee). In CNMFE, we have the ring model, as discussed over at the other issue. Just to import from what I said there:

On the background model: things get more gnarly for the background model when we run CNMFE in Caiman, because then there is no b/f (they are None). Instead, we have the ring model, so the parameters are W and b0 (as I'm sure you know, in CNMFE there is a much more complicated background model, where each pixel has its own background fluctuations a certain distance in a ring from that pixel that are subtracted out -- this is captured in W that represents the ring model; b0 is a dc offset for each pixel).

So, if we wanted to save the output of the model, it would be good to save W and b0. The "convenient" thing is, checking for f and b is enough: if they are None, then you are running CNMFE and W/b0 will be defined (assuming you have run your estimator). So it isn't that much extra work. W is the same type as A (the spatial footprints) -- a compressed sparse column matrix.

The thing is, if we just ignored W and b0, handling #287 would be sufficient for handling CNMFE data -- the things that most people care about (calcium traces and such) are the same for CNMF/CNMFE. It tends to be the power users and developers that really want to see background (e.g., with neural model and background model you can calculate the residuals of the model, given the raw data).

Thanks for your time: these tools are really helpful! 🥇

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