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

Request : Add compatibility with next gen BRW files #1156

Open
b-grimaud opened this issue Aug 23, 2022 · 16 comments · May be fixed by #1446
Open

Request : Add compatibility with next gen BRW files #1156

b-grimaud opened this issue Aug 23, 2022 · 16 comments · May be fixed by #1446
Milestone

Comments

@b-grimaud
Copy link
Contributor

b-grimaud commented Aug 23, 2022

Hi,

3Brain is currently moving towards BRW v4.x, compatible with newer versions of their software but most importantly adapted to multiwell chips, which means that recordings from multiple parallel chips can be stored in the same file.
This implies a major rework of the underlying HDF5 architecture, and the current BiocamIO reader is not compatible.

I got the OK from 3Brain to share their documentation on that file format, but it would still probably be better to not have it publically hosted.

Is there someone I can reach out to that could take a look at that documentation and possibly figure out how to update the reader ?

Thanks !

@JuliaSprenger
Copy link
Member

Hi @BptGrm,
thanks for reaching out. This already the right place for this discussion. Do you also already have a dataset in the new format? With a tiny test dataset to be added to GIN we could start extending the current BiocamIO.

@JuliaSprenger
Copy link
Member

@alejoe91 Do you have an idea on how to extend this?

@JuliaSprenger JuliaSprenger added this to the 0.12.1 milestone Apr 3, 2023
@alejoe91
Copy link
Contributor

alejoe91 commented Apr 3, 2023

Hi @JuliaSprenger

Unfortunately not. I think that one will need to explore the new h5 test files and see where they save the relevant stuff. It would be great to ask support from someone from 3Brain directly.

@JuliaSprenger
Copy link
Member

JuliaSprenger commented Apr 3, 2023

@BptGrm Any news on this from your side? As mentioned above, feel free to contribute a small test dataset to GIN to start extending the neo IO.

@b-grimaud
Copy link
Contributor Author

Hi, thanks for bringing this up again !

I submitted a very basic PR to the HerdingSpikes spike sorter to read newer BrainWave files. This might be a starting point but it's definetly not compatible with the multi-well recording that this format is meant to support.

I dug pretty deep in the file structure at the time but there were still some aspects that I couldn't quite figure out, namely how they manage data chunks.

I tried reaching out to 3Brain about this issue a while ago, but I didn't get any answers. As I mentionned in the original post of this issue, they did send me some documentation on the format that I could send through email.

I have a few recordings in this format that I could share, I'll get started on the GIN upload procedure soon.

@JuliaSprenger
Copy link
Member

Hi @BptGrm Thanks for the update. This sounds like it will still take some time and a lot of tinkering to figure out the new format without someone from 3Brain helping out. Unless you require neo supporting the new format I would say we postpone this until 3Brain contributes or someone knowing the format in more detail has a chance to look at it.

@b-grimaud
Copy link
Contributor Author

I'll ask 3Brain again and see if I can get a more positive answer.

In the meantime, if anyone desperately need to open newer BrainWave file through neo, there's another open source project called Xenon LFP analysis which contains a downsampling tool that can convert those files to the older format. Setting the 'new' sampling rate to the original should do the trick.

@JuliaSprenger JuliaSprenger modified the milestones: 0.12.1, 0.13.0 Jul 19, 2023
@Lychfindel
Copy link

Hi all,
I am also very interested for the support of brw 4.x.
I could also access the official documentation of the format, which are very extensive and include also some code snippet to extract the information in python.
How is proceeding the implementation? I'm willing to help and contribute if there is the need.

@b-grimaud
Copy link
Contributor Author

@Lychfindel As of #1326 it is now supported.

@alejoe91
Copy link
Contributor

@Lychfindel you need to install NEO from sources!

@Lychfindel
Copy link

Thank you! This is a great news!
Unfortunately the import of my dataset is still raising errors.
After investigating a little bit I understood that the error comes from the type of raw data saved: while the new implementation handles the .brw file with data type "Raw" (i.e. with no compression applied), it does not handle the other two supported raw data types "WaveletBasedEncodedRaw" and "EventsBasedSparseRaw", which involve some type of data compression.
Do you think it would be possible to include also these raw types even if they are not completely raw? It should be possible to reconstruct the raw signal (with some data loss) even from these types

@b-grimaud
Copy link
Contributor Author

Looking through the docs again, those formats are quite a bit more complicated.
3Brain does provide some code examples for both types, but I don't know how much work it would be to transpose them into NEO.
The PDF is available on the NeuralEnsemble GIN.

@alejoe91
Copy link
Contributor

In principle it should be possible to load the other compressed formats in NEO.

  • For the EventsBasedSparseRaw, this is already supported as one can load spike times and waveforms.
    I don't think that NEO should fill in the data with zeros, since this is basically making up data. If you use spikeinterface, we can discuss adding padding options there (we might have some already).

  • For WaveletBasedEncodedRaw, it could be possible to implement something in NEO, but I honestly would tend towards not supporting this, because it might be hard to maintain. @Lychfindel as a general practice, I recommend storing raw data and not doing lossy compression, and maybe do lossless compression later (e.g., with spikeinterface - see paper)

@Lychfindel
Copy link

I was not aware that was possible to load spike times and waveforms, this will definitely work for the EventsBasedSparseRaw. Thanks for the hint!

I agree with you that is always better storing raw data, unfortunately I'm working with a dataset recorded in the past by a different research group. In any case, I completely understand your point to support only raw formats!

@apdavison apdavison modified the milestones: 0.13.0, 0.14.0 Feb 23, 2024
@b-grimaud
Copy link
Contributor Author

Coming back to this, EventsBasedSparseRaw seems quite a bit different from spikes and waveforms.
The compressed .brw files only contains sections of raw data, unlike .bxr files, at least as far as I've seen.
I'm not exactly sure how BrainWave selects which section to save or not, but that compression mode is available in the basic version of the software, which doesn't include live spike/LFP detection.
It might be possible to combine both spikes and raw signal in a single file using the upgraded versions of BrainWave.

I have a working version of the BiocamRawIO module that can read this format, essentially adapted from 3Brain's own documentation. It is pretty slow, mostly because the nested file structure requires parsing bytes by bytes iteratively.

I can open a "work in progress" PR if anyone is interested.

WaveletBasedEncodedRaw seems easier on paper, but would require adding pywt in the biocam optional dependencies.

@mahlzahn
Copy link
Contributor

I only now saw this ongoing discussion and already implemented the reading of EventsBasedSparseRaw in the open PR #1446

It tightly follows the code example given in the 3Brain documentation. We could also make some of the options available as parameters to the init function of the BiocamRawIO class.

@zm711 zm711 linked a pull request May 17, 2024 that will close this issue
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

Successfully merging a pull request may close this issue.

6 participants