Skip to content

Conversation

@alejoe91
Copy link
Member

@samuelgarcia let's discuss!

@alejoe91 alejoe91 added the preprocessing Related to preprocessing module label Nov 25, 2025
@yger
Copy link
Collaborator

yger commented Nov 25, 2025

I think this is a great feature, but I already told @samuelgarcia that maybe we should at very least warn (prevent ?) users that will use very low frequencies for filters, trying to get LFP and/or low pass versions of the data. If the automatic margin starts to be really large (maybe larger than the default chunk size of 1s), then we should warn users that they are doing something clearly suboptimal.

@alejoe91
Copy link
Member Author

I think this is a great feature, but I already told @samuelgarcia that maybe we should at very least warn (prevent ?) users that will use very low frequencies for filters, trying to get LFP and/or low pass versions of the data. If the automatic margin starts to be really large (maybe larger than the default chunk size of 1s), then we should warn users that they are doing something clearly suboptimal.

Sub-optimal but somehow needed! Maybe we can warn if the margin is greater than the max_margin_s (default 5 s). What do you think?

@yger
Copy link
Collaborator

yger commented Nov 25, 2025

Yes, I've read the PR, and indeed, at least a warning that the theoretical margin should be XX, and that it has be clipped to max_margin_s. The thing is that if users really want to do that, then the warning message could also advise them to increase chunk_duration in the default_job_kwargs, to reduce IO overloads

@samuelgarcia samuelgarcia added this to the 0.104.0 milestone Dec 4, 2025
@samuelgarcia
Copy link
Member

We democratically decided to remove the max_margin kwargs and instead make a mechanism that raise an error if the end-user try to filter in LFP band and then point to a link to a clear and didactic and really exemplar tutorial about chunking and its bad effect on low freqs.

@alejoe91
Copy link
Member Author

alejoe91 commented Dec 5, 2025

This is ready for final review. here's a new doc page explaining the issue: https://spikeinterface--4227.org.readthedocs.build/en/4227/how_to/extract_lfps.html

# when not done carefully, especially when data is processed in chunks (for memory efficiency).
#
# This tutorial demonstrates:
# 1. How to generate simulated LFP data
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need a space to render this as a list

Suggested change
# 1. How to generate simulated LFP data
# 1. How to generate simulated LFP data

# **Why does this fail?**
#
# The error occurs because by default in SpikeInterface when highpass filtering below 100 Hz.
# Filters with very low cutoff frequencies have long impulse responses, which require larger margins to avoid edge artifacts between chunks.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to explain what a margin and a chunk is more clearly before this?
If I were writing it, I'd have a first section called "1. Chunks and margins" and explain what chunking is, why we do it, and what a margin is. Or put in more explanation here.

Copy link
Member

@chrishalcrow chrishalcrow Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I've read more now... so I would put Section 3 earlier in the tutorial. And put in a longer description of a chunk and margin.

ax.legend()

# %% [markdown]
# For smaller chunk sizes, these artifact will happen more often. In addition, the margin "overhead" will make processing slower.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comes straight after the plot. Can you explain what we see in the plot. Something like:

From the plot, we can see that there is a very small error when the margin size is large (green), a larger error when the margin is smaller (organge) and a large error when the margin is small (blue). So we need large margins (compared to the chunk size) if we want accurate filtered.

For smaller...

continue
diff = recording_optimal - recording_chunk
traces_diff = diff.get_traces(start_frame=start_frame, end_frame=end_frame)
ax.plot(traces_diff, label=recording_key)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make the axes in seconds, please? Then it's much easier to see where 30s is.

sw.plot_traces(recording_filt, time_range=[20, 21])

# %% [markdown]
# A warning tells us that what we are doing is not optimized, since in order to get the requested traces the marging "overhead" is very large.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# A warning tells us that what we are doing is not optimized, since in order to get the requested traces the marging "overhead" is very large.
# A warning tells us that what we are doing is not optimized, since in order to get the requested traces the margin-ing "overhead" is very large.

? or just "margin"

@chrishalcrow
Copy link
Member

Hello, amazing!

You could set this doc up as a jupyter notebook that gets run in the CI (e.g. https://github.com/SpikeInterface/spikeinterface/tree/main/examples/tutorials/forhowto)

Then we don't have to do all the .py -> .rst conversion annoying stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

preprocessing Related to preprocessing module

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants