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

Incorrect std value in LFP viewer #615

Open
florian6973 opened this issue Jun 20, 2024 · 10 comments
Open

Incorrect std value in LFP viewer #615

florian6973 opened this issue Jun 20, 2024 · 10 comments

Comments

@florian6973
Copy link

florian6973 commented Jun 20, 2024

Hi!

I generated a white noise signal with a std of 10. When playing it in OE, I get absurd std values like 1-2 instead of something around 10 (see image below).
image

Am I missing something please?

I thank you in advance for your help,

Best,

@florian6973
Copy link
Author

Here is one of the files if you'd like to test
structure5.zip

@jsiegle
Copy link
Member

jsiegle commented Jun 21, 2024

Thanks, I see what the problem is – the standard deviation is being calculated on the "screen buffer" (which aggregates multiple samples into a single pixel), rather the "display buffer" (which contains the original samples). We are planning to overhaul this part of the LFP Viewer in the next release (and likely switch to displaying RMS values, instead of standard deviation). We will make sure this gets fixed!

@florian6973
Copy link
Author

Thank you very much for your insights! Computing RMS or MAD values on several channels at the same time would be a very exciting feature indeed!

In the meantime, is there an easy way to replace the screen buffer by the display buffer in the code (like rewriting getMean and getStd with displayBuffer instead of screenBufferMean) and recompile or is it better to use a custom plugin or custom script with ZeroMQ streaming to measure noise please?

@jsiegle
Copy link
Member

jsiegle commented Jun 23, 2024

I think actually just changing those functions to read from the displayBuffer should work, as long as you get the indexing right. It should read around 0.1 s worth of samples up to the current displayBufferIndex for the selected channel. Can you try that and see if it gives reasonable values?

@florian6973
Copy link
Author

Thanks for your help!

I updated the code accordingly florian6973@e5d92ba. It seems to work almost well:

  • the std value now makes sense (10 expected):
    image
  • but sometimes when refreshing by a click it just displays 0, I have to click again to get a new coherent value:
    image

Do you have any idea of the reason of this behavior please? Thanks!

@jsiegle
Copy link
Member

jsiegle commented Jun 25, 2024

I'm not sure why this is happening – you could try creating a breakpoint or adding some debug outputs (using LOGD) to check the state of specific variables each time there's a mouse click. That may shed light on the problem.

@florian6973
Copy link
Author

Thank you for your help!
Here is the log:

[open-ephys][debug] DisplayBufferIndex 852 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 470 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 88 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 984 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 18450 - 2000 points required
[open-ephys][debug] Returning 10.0597
[open-ephys][debug] DisplayBufferIndex 176 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 13382 - 2000 points required
[open-ephys][debug] Returning 9.76821
[open-ephys][debug] DisplayBufferIndex 220 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 690 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 11362 - 2000 points required
[open-ephys][debug] Returning 9.82194
[open-ephys][debug] DisplayBufferIndex 734 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 2438 - 2000 points required
[open-ephys][debug] Returning 9.82081
[open-ephys][debug] DisplayBufferIndex 16922 - 2000 points required
[open-ephys][debug] Returning 10.074
[open-ephys][debug] DisplayBufferIndex 10128 - 2000 points required
[open-ephys][debug] Returning 9.91319
[open-ephys][debug] DisplayBufferIndex 352 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 1204 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 396 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 10620 - 2000 points required
[open-ephys][debug] Returning 9.80364
[open-ephys][debug] DisplayBufferIndex 6808 - 2000 points required
[open-ephys][debug] Returning 9.82985
[open-ephys][debug] DisplayBufferIndex 18736 - 2000 points required
[open-ephys][debug] Returning 9.48451
[open-ephys][debug] DisplayBufferIndex 14 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 5978 - 2000 points required
[open-ephys][debug] Returning 9.50558
[open-ephys][debug] DisplayBufferIndex 16202 - 2000 points required
[open-ephys][debug] Returning 9.77602
[open-ephys][debug] DisplayBufferIndex 2592 - 2000 points required
[open-ephys][debug] Returning 9.93193
[open-ephys][debug] DisplayBufferIndex 9408 - 2000 points required
[open-ephys][debug] Returning 9.75315
[open-ephys][debug] DisplayBufferIndex 910 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 8578 - 2000 points required
[open-ephys][debug] Returning 10.0691
[open-ephys][debug] DisplayBufferIndex 528 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 1828 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 146 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 1850 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 616 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 4024 - 2000 points required
[open-ephys][debug] Returning 9.9698
[open-ephys][debug] DisplayBufferIndex 212 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 1086 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 13462 - 2000 points required
[open-ephys][debug] Returning 9.80752
[open-ephys][debug] DisplayBufferIndex 704 - 2000 points required
[open-ephys][debug] Returning 0
[open-ephys][debug] DisplayBufferIndex 7946 - 2000 points required
[open-ephys][debug] Returning 9.92874

But I am now even more confused:

  • one click on the screen seems to call several times the getStd function
  • the displayed value is not always the last one mentioned in the log. (for instance, with the current state I get 0 but the last returned value is 9.92)
  • the displaybuffer seems to be reset randomly from time to time, instead of just shifted.

One solution would be to use fewer points (like 200), but the estimate may be less precise. Or to understand better how the buffer works :) If you have any insights, I would be very grateful, thanks!

@jsiegle
Copy link
Member

jsiegle commented Jun 26, 2024

I see what the issue is. If the current index is less than 2000, it fails because some of the requested data will appear at a negative index. In that case, you'll need to read from the buffer in two steps. For example, if the current index is 500, you would read 1500 values from the end of the buffer, then 500 values from the start of the buffer. Can you try implementing that and see if it fixes the problem?

@florian6973
Copy link
Author

Thank you so much for your help! It fixes the problem indeed :) I just hope displayBuffer->getNumSamples() - samp will always be a positive index, I can add some extra condition if you think there is such a risk.

I will use this modified version of OpenEphys from now on, until the new release of OE. I opened a PR if you are interested.

@jsiegle
Copy link
Member

jsiegle commented Jun 26, 2024

Thanks! We will test out the PR and merge if everything looks good

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

No branches or pull requests

2 participants