[ENH]: Add TemporalSlicer

[synchon]

Are you requiring a new dataset or marker?

• I understand this is not a marker or dataset request

Which feature do you want to include?

To have the option to define which segment of the time series to use for extracting connectomes (define start and end point). For example, cut a 20-minute sequence after 10 minutes and extract connectomes from only the second part.

Use-Case: We have a 24 minute sequence with a task and a control task performed sequentially and want to analyze them separately.

How do you imagine this integrated in junifer?

Cut the time series before calculating the connectomes.

Do you have a sample code that implements this outside of junifer?

Anything else to say?

@kaurao

[synchon]

@jkroell Hi! Thanks for the feature request. Not sure I understand it correctly, do you want an option to perform temporal slicing at the marker level or do you want a preprocessor?

[kaurao]

I think this can be implemented at different levels, either in preprocessing or in the marker. I guess making it part of preprocessing with make it more general and applicable across different markers?

[synchon]

@kaurao Ok then we go with a new preprocessor.

[codecov]

Codecov Report

Attention: Patch coverage is 98.41270% with 1 line in your changes missing coverage. Please review.

Project coverage is 91.09%. Comparing base (b9013e7) to head (57acd73).
Report is 21 commits behind head on main.

Files with missing lines	Patch %	Lines
junifer/preprocess/_temporal_slicer.py	98.41%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #443      +/-   ##
==========================================
+ Coverage   86.13%   91.09%   +4.96%     
==========================================
  Files         133      134       +1     
  Lines        5617     5422     -195     
  Branches      950      903      -47     
==========================================
+ Hits         4838     4939     +101     
+ Misses        600      309     -291     
+ Partials      179      174       -5     

Flag	Coverage Δ
docs	100.00% <ø> (ø)
junifer	91.09% <98.41%> (+4.96%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
junifer/pipeline/pipeline_component_registry.py	94.64% <ø> (ø)
junifer/preprocess/_temporal_slicer.py	98.41% <98.41%> (ø)

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[synchon]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

[fraimondo]

@synchon @kaurao @jkroell Does it make sense to add the positibility to specify intervals in several ways?

• [tstart, tend]
• [tstart, tstart+len]

Ej:

• 10 minutes starting at 0: tstart=0, len=10*60
• from minute 10 to minute 20: tstart=10*60, tend=20*60

[fraimondo]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

[synchon]

Adding a len doesn't make sense to me as you can calculate that and be sure of your tend depending on t_r. But maybe, as an end-user, Jean's thoughts might differ.

[fraimondo]

Adding a len doesn't make sense to me as you can calculate that and be sure of your tend depending on t_r. But maybe, as an end-user, Jean's thoughts might differ.

Why can't we support both?

It's easier to copy/paste a yaml and then change the tstart if you want to analyse 10 minutes from T0 and 10 minutes from T1, where T1 is a number that we know from the acquisition.

[synchon]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

Making them floats is a good idea to be more precise with slicing. I anyway do an int conversion to take care of that, most you get is an IndexError.

[synchon]

Adding a len doesn't make sense to me as you can calculate that and be sure of your tend depending on t_r. But maybe, as an end-user, Jean's thoughts might differ.

Why can't we support both?

It's easier to copy/paste a yaml and then change the tstart if you want to analyse 10 minutes from T0 and 10 minutes from T1, where T1 is a number that we know from the acquisition.

Of course we can, not a problem. Just wanted to make sure there's a proper use case.

[synchon]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

Making them floats is a good idea to be more precise with slicing. I anyway do an int conversion to take care of that, most you get is an IndexError.

This is taken care of now.

[fraimondo]

Adding a len doesn't make sense to me as you can calculate that and be sure of your tend depending on t_r. But maybe, as an end-user, Jean's thoughts might differ.

Why can't we support both?
It's easier to copy/paste a yaml and then change the tstart if you want to analyse 10 minutes from T0 and 10 minutes from T1, where T1 is a number that we know from the acquisition.

Of course we can, not a problem. Just wanted to make sure there's a proper use case.

If we can do the math for the user, better.

I had this use case recently because someone merged resting with a task so I had to discard some volumes at the begining. Which also makes me think that in that case I needed:

• tend=None and len=None should mean until the end of the recording.

Another possible use case:

• tend<0 could also mean stop end tend seconds from the end. Basically, crop tend seconds from the end.

[github-actions]

PR Preview Action v1.6.0
🚀 View preview at https://juaml.github.io/junifer/pr-preview/pr-443/
Built to branch gh-pages at 2025-04-08 14:49 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[jkroell]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

Making them floats is a good idea to be more precise with slicing. I anyway do an int conversion to take care of that, most you get is an IndexError.

This is taken care of now.

I like the interface! Would it be an option to automatically get the TR, or do you think the user should set that himself?

[fraimondo]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

Making them floats is a good idea to be more precise with slicing. I anyway do an int conversion to take care of that, most you get is an IndexError.

This is taken care of now.

I like the interface! Would it be an option to automatically get the TR, or do you think the user should set that himself?

If the TR is not specified, it will be taken from the images. However, keep in mind that some software do not take care of the TR properly, so it's always good to have an option to fix it manually.

[jkroell]

@jkroell How do you like this interface?

preprocess:
  - kind: TemporalSlicer
    start: 0 # int, in second
    stop: 168 # int, in second
    t_r: 2.0  # float, in second (TR)

start and stop, if in seconds, should be floats. If we have sub-second TR we are in trouble. We'll most probably have rounding errors.

Making them floats is a good idea to be more precise with slicing. I anyway do an int conversion to take care of that, most you get is an IndexError.

This is taken care of now.

I like the interface! Would it be an option to automatically get the TR, or do you think the user should set that himself?

If the TR is not specified, it will be taken from the images. However, keep in mind that some software do not take care of the TR properly, so it's always good to have an option to fix it manually.

Okay, makes sense! Looks good to me, then.

[synchon]

@jkroell Was about to reply, but Fede already gave a nice answer.
@fraimondo Have added support for negative indexing in stop.

[synchon]

@fraimondo Ok so now we can have stop=None which would take you to end and duration which is added to start to address the situations you described. I believe it's better to adjust the confounds as well?

The interface now looks like:

• negative stop:

preprocess:
  - kind: TemporalSlicer
    start: 0.0 # float, in second
    stop: -2.0 # -ve float, in second

• no end slicing:

preprocess:
  - kind: TemporalSlicer
    start: 10.0 # float, in second
    stop: null

• duration:

preprocess:
  - kind: TemporalSlicer
    start: 10.0 # float, in second; start at 10s
    stop: null
    duration: 20.0 # float, in second; stop at 30s

Does it make sense now? @fraimondo @jkroell @kaurao

[fraimondo]

@fraimondo Ok so now we can have stop=None which would take you to end and duration which is added to start to address the situations you described. I believe it's better to adjust the confounds as well?

The interface now looks like:

• negative stop:

preprocess:
  - kind: TemporalSlicer
    start: 0.0 # float, in second
    stop: -2.0 # -ve float, in second

• no end slicing:

preprocess:
  - kind: TemporalSlicer
    start: 10.0 # float, in second
    stop: null

• duration:

preprocess:
  - kind: TemporalSlicer
    start: 10.0 # float, in second; start at 10s
    stop: null
    duration: 20.0 # float, in second; stop at 30s

Does it make sense now? @fraimondo @jkroell @kaurao

Yes! Perfect sense.

And you are right, we need to adjust the confounds so they match. Though I believe this should be used after confound removal.

[synchon]

And you are right, we need to adjust the confounds so they match. Though I believe this should be used after confound removal.

Ideally it should be after confound removal, but is there a case where one can do it before confound removal or can use the confounds in markers?

[fraimondo]

And you are right, we need to adjust the confounds so they match. Though I believe this should be used after confound removal.

Ideally it should be after confound removal, but is there a case where one can do it before confound removal or can use the confounds in markers?

We need to be consistent. So I agree with you. Any picking on the BOLD timeseries should also pick any other data that matches.

[synchon]

And you are right, we need to adjust the confounds so they match. Though I believe this should be used after confound removal.

Ideally it should be after confound removal, but is there a case where one can do it before confound removal or can use the confounds in markers?

We need to be consistent. So I agree with you. Any picking on the BOLD timeseries should also pick any other data that matches.

Okay then I'll make the necessary changes.

[synchon]

@fraimondo Updated the code to reflect confounds manipulation, I'll request a review, feel free to add more comments before reviewing.

[synchon]

@fraimondo Shall we get this in?

[jkroell]

Using the slicer after confound removal worked successfully. Thanks for adding this!