Skip to content

WhiteMatterRecordingExtractor #3849

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

Merged
merged 23 commits into from
Apr 22, 2025
Merged

WhiteMatterRecordingExtractor #3849

merged 23 commits into from
Apr 22, 2025

Conversation

pauladkisson
Copy link
Collaborator

@pauladkisson pauladkisson commented Apr 8, 2025

Fixes #3848

Pretty minimal wrapper around BinaryRecordingExtractor with a specified file_offset, dtype, and gain. As far as I know these should be constant for WhiteMatter files, but I only have one example, and no formal spec from WhiteMatter (so far). So, I think we should keep an eye out for WhiteMatter files in future conversions and be prepared to update this extractor as necessary.

@pauladkisson pauladkisson marked this pull request as ready for review April 9, 2025 19:09
@pauladkisson pauladkisson requested a review from alejoe91 April 9, 2025 19:09
Copy link
Member

@alejoe91 alejoe91 left a comment

Choose a reason for hiding this comment

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

Thanks @pauladkisson

See comments

Comment on lines 61 to 74
@staticmethod
def write_recording(recording, file_paths, **job_kwargs):
"""
Save the traces of a recording extractor in binary .dat format.

Parameters
----------
recording : RecordingExtractor
The recording extractor object to be saved in .dat format
file_paths : str
The path to the file.
"""
job_kwargs["byte_offset"] = 8
BinaryRecordingExtractor.write_recording(recording, file_paths=file_paths, dtype="int16", **job_kwargs)
Copy link
Member

Choose a reason for hiding this comment

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

I would remove this and just write it in the test

Copy link
Collaborator

Choose a reason for hiding this comment

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

+1

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done!

@alejoe91 alejoe91 added the extractors Related to extractors module label Apr 10, 2025
Comment on lines 61 to 74
@staticmethod
def write_recording(recording, file_paths, **job_kwargs):
"""
Save the traces of a recording extractor in binary .dat format.

Parameters
----------
recording : RecordingExtractor
The recording extractor object to be saved in .dat format
file_paths : str
The path to the file.
"""
job_kwargs["byte_offset"] = 8
BinaryRecordingExtractor.write_recording(recording, file_paths=file_paths, dtype="int16", **job_kwargs)
Copy link
Collaborator

Choose a reason for hiding this comment

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

+1

Copy link
Collaborator

@h-mayorquin h-mayorquin left a comment

Choose a reason for hiding this comment

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

This LGTM.
I think the read small traces test should be removed. No need to test here was is tested already.

I would like to have testing data on gin for this but I think @alejoe91 should make the call if this is necessary or not for this for merging.

Otherwise this has my +1.

from spikeinterface.core.numpyextractors import NumpyRecording


def test_round_trip(tmp_path):
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is OK but I would prefer testing data. Can we add something to gin? This should be easy to stub.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, this is awaiting gin access. Should be up in a day or two.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

GIN PR is merged :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ok, waiting for the test and should be good to go after that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ok, waiting for the test and should be good to go after that.

Done!

@zm711
Copy link
Member

zm711 commented Apr 11, 2025

Two minor comments unrelated to the PR content.

  1. We typically do a forking workflow. Our docs do say that for dev, but lately we've been sneaking in more PRs from project branches. Do we want to loosen that requirement for people affiliated with the project or do we want to be strict about this (other than CI/release branches)
  2. Is there a reason why we wouldn't want to implement this at the Neo level just to keep things separate? is it a concern about Neo releases? If so we could do the extractor like this for now, but work on a neo level and then convert? I think there is a benefit to keep as much non-sorting extractor stuff hived off. But if there is a good reason for us to not do that I would love to know people's opininons.

@pauladkisson
Copy link
Collaborator Author

  1. We typically do a forking workflow. Our docs do say that for dev, but lately we've been sneaking in more PRs from project branches. Do we want to loosen that requirement for people affiliated with the project or do we want to be strict about this (other than CI/release branches)

I'm sorry I didn't follow the recommended forking workflow. I just defaulted to the branching workflow that we use with neuroconv, but I can be more diligent about it in the future.

  1. Is there a reason why we wouldn't want to implement this at the Neo level just to keep things separate? is it a concern about Neo releases? If so we could do the extractor like this for now, but work on a neo level and then convert? I think there is a benefit to keep as much non-sorting extractor stuff hived off. But if there is a good reason for us to not do that I would love to know people's opininons.

@h-mayorquin and I decided against including this in neo since there is no header to parse, so it seemed like it wouldn't naturally lend itself to the neo structure. Also worth noting that BinaryRecordingExtractor (the parent of this class) does not depend on neo.

@alejoe91
Copy link
Member

I agree it's not worth including in NEO at this point!

Copy link
Member

@zm711 zm711 left a comment

Choose a reason for hiding this comment

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

Couple comments :)

@@ -0,0 +1,62 @@
from pathlib import Path
from typing import List, Union, Optional
Copy link
Member

Choose a reason for hiding this comment

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

We are far enough along in python that we can use the built-in list, but since you're pulling in Union and Optional if you want to use List it doesn't cost extra I suppose.

@pauladkisson
Copy link
Collaborator Author

Any other issues holding up this PR?

@h-mayorquin
Copy link
Collaborator

Data and removing of unnecessary test for me. Either Alessio and Sam should take a look as well.

@pauladkisson
Copy link
Collaborator Author

Not sure why the file is not being found...

@zm711
Copy link
Member

zm711 commented Apr 18, 2025

Not sure why the file is not being found...

I think our tests do not update the ephy_cache all the time. So I'm wondering if your specific file changes aren't triggering a cache check and so you're not getting the updated version. GIN is down this weekend for maintenance, but if this still isn't working Monday after a cache refresh from the cron job then I think we should explore this more.

Copy link
Collaborator

@h-mayorquin h-mayorquin left a comment

Choose a reason for hiding this comment

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

Let's make the test work and this should be ready to go.



file_path = (
get_global_dataset_folder()
Copy link
Collaborator

Choose a reason for hiding this comment

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

@pauladkisson
Copy link
Collaborator Author

Tests are passing now! (minus linux which should be fixed by #3877)

Copy link
Collaborator

@h-mayorquin h-mayorquin left a comment

Choose a reason for hiding this comment

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

I am OK with this.

@alejoe91 alejoe91 merged commit 28cb527 into main Apr 22, 2025
15 checks passed
@h-mayorquin h-mayorquin deleted the white_matter branch April 22, 2025 13:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extractors Related to extractors module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature Request: WhiteMatter
4 participants