AllenInstitute / ipfx

computes intrinsic cell features from intracellular electrophysiology data
https://ipfx.readthedocs.io/en/latest/
Other
27 stars 37 forks source link

Cell attached spontaneous firing feature extraction #541

Open ru57y34nn opened 2 years ago

ru57y34nn commented 2 years ago

Describe the use case that is addressed by this feature. The problem that this feature would solve.

IVSCC is patching in subcortical brain regions where cells are more likely to exhibit spontaneous firing. Spontaneous firing data is acquired by adapting the cell-attached/gigaohm seal (EXTPCllATT) stimulus set to include an additional 60 seconds at the end of the sweep. The two main advantages of amending the cell-attached sweep are:

(1) The physiological spontaneous firing behavior is maintained because cell-attached mode does not alter the internal ionic composition of the neuron.

(2) The probability of successfully acquiring the data before a spontaneous break-in is increased relative to acquiring the data in a separate sweep that comes after EXTPCllATT.

The ability to use EXTPCllATT for seal QC is maintained.

By enhancing IPFX to analyze the spontaneous firing behavior recorded in EXTPCllATT, spontaneous firing behavior can contribute to cell-type classification.

We expect the spontaneous firing rates of cells to be higher than normal at the beginning of a EXTPCllATT sweep because the potassium in the internal solution is discharged while approaching the cell with positive pressure on the pipette. After sealing onto the cell, the elevated external potassium will dissipate. The proposed analysis captures the spontaneous firing rate after the potassium concentration has stabilized.

Describe the solution you'd like What you want to happen.

Add spontaneous firing feature extraction to IPFX for the EXTPCllATT sweep. The first 300 ms of the sweep are unchanged and are still used to measure the value of the seal, but we would like to perform the following analysis steps on the last 60 seconds of the sweep:

• Filter the sweep (low pass filter) to improve spiking SNR • Remove exponential change in baseline current due to changing seal resistance (when present) • Perform spike detection (in voltage-clamp) • Measure the instantaneous spike rate throughout the sweep • Determine when or if steady-state firing is reached? o Is 60 seconds long enough? • Extract features from sweep o Steady-state firing rate (physiological spontaneous firing rate) o Change in Instantaneous firing rate over the duration of the sweep o Min and max instantaneous firing rates o Instantaneous rate vs. subsequent rate

Describe alternatives you've considered Any alternative solutions or features you've considered.

Additional context Add any other information about the feature request here.

Do you want to work on this issue? Are you willing and able to work on this feature? If so, let us know here (and see the guide). Thank you!

I am willing to work on this request along with others from the Ephys team.

tmchartrand commented 2 years ago

@ru57y34nn these ideas look great, and I'm sure we'll talk at some point soon about the logistics of integrating this, but figured I'd comment now with one point that might help us spec out that future work. You may have already thought through this, but to me the main question is which existing classes can be adapted to process this sweep, i.e. whether the functionality in spike_detector.py will work with the voltage-clamp cell-attached sweep (possibly with modified parameters).

If you get a chance, it might be worth playing around with that a bit, and seeing where it works/fails, and in particular trying the sequence of calls that the SpikeFeatureExtractor uses:

        putative_spikes = spkd.detect_putative_spikes(v, t, self.start, self.end,
                                                    dv_cutoff=self.dv_cutoff,
                                                    dvdt=dvdt)
        peaks = spkd.find_peak_indexes(v, t, putative_spikes, self.end)
        putative_spikes, peaks = spkd.filter_putative_spikes(v, t, putative_spikes, peaks,
                                                           self.min_height, self.min_peak,
                                                           dvdt=dvdt)
ru57y34nn commented 2 years ago

Thanks @tmchartrand, I will play around with the SpikeFeatureExtractor calls this week and see if I can get an idea of which existing classes and functions we can reuse for this purpose and what we might need to modify or write ourselves. @gouwens would you also mind taking a look at this issue whenever you get a chance and leave any suggestions or ideas that you might have as well?

gouwens commented 2 years ago

Hi @ru57y34nn,

Yes, I think there might be functions (or at least parts of functions) already in ipfx that could be useful for this. I think the way I have detected cell-attached spikes in the past is mostly by threshold-crossing (after some noise reduction, as you mentioned), since the cell-attached trace is kind of already the derivative of the voltage trace. There is low-pass filtering code in the calculate_dvdt() function that might be useful, and there is code in detect_putative_spike() for dv/dt threshold crossing detection.

I think the hard part will probably be automatically and robustly finding a suitable threshold for the spike-crossing, so we'll need a good set of sweeps from a variety of cells to test the methods on. If you have a set of specimen IDs for cells with those traces and want to post it here, I can try to take a look at them, too.

Once you have a set of spike times, you can use existing spike time analysis functions like get_isis() and adaptation_index() to look at the instantaneous frequency and see how it changes over time.

ru57y34nn commented 2 years ago

Thanks @gouwens for the suggestions, I will start playing around with these functions and I will also put together a set of specimen IDs that contain these cell attached traces and post them here as soon as I can.

ru57y34nn commented 2 years ago

@gouwens here is a set of cells (specimen IDs and storage directories included) that have the 60 second cell attached sweep. I have already done a little testing with the low pass filter code in calculate_dvdt(), which seems to work well so far, and I have just started looking into the spike detection and threshold crossing code, but I still have some more testing to do there. Once you have a chance to look at some of these traces maybe we can get together on a call to compare notes? Just let me know when you get a chance, thanks. 60sec_cellatt_cells.csv

gouwens commented 2 years ago

Sounds great - thanks! I will check it out and let you know.


From: Rusty Mann @.> Sent: Friday, January 28, 2022 12:36:15 PM To: AllenInstitute/ipfx @.> Cc: gouwens @.>; Mention @.> Subject: Re: [AllenInstitute/ipfx] Cell attached spontaneous firing feature extraction (Issue #541)

@gouwenshttps://github.com/gouwens here is a set of cells (specimen IDs and storage directories included) that have the 60 second cell attached sweep. I have already done a little testing with the low pass filter code in calculate_dvdt(), which seems to work well so far, and I have just started looking into the spike detection and threshold crossing code, but I still have some more testing to do there. Once you have a chance to look at some of these traces maybe we can get together on a call to compare notes? Just let me know when you get a chance, thanks. 60sec_cellatt_cells.csvhttps://github.com/AllenInstitute/ipfx/files/7961690/60sec_cellatt_cells.csv

— Reply to this email directly, view it on GitHubhttps://github.com/AllenInstitute/ipfx/issues/541#issuecomment-1024617033, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAR6KYZWNXW7FV75YQDPLKTUYL437ANCNFSM5KEXOYWA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.Message ID: @.***>