[Sleep] Facilitate scoring of long recordings

[TomBugnon]

Hi @raphaelvallat @EtienneCmb ,

When scoring long recordings (24h in this example), the "current time" indicator is extremely thin

and sometimes even disappears

It is now very impractical and error prone to use Sleep with long recordings, because it's hard to navigate to specific parts of data or to see what periods have been scored already or not (all the more since the default hypnogram value for unscored periods is "wake" rather than "artifact" or left unspecified).

In the Sleepscore software, there's a way to display the hypnogram for only, say 1h segments of data at a time.

What would you think about updating Sleep with the following: 1- set a minimum size of the "current time" marker so that it doesn't become too small for long recording 2- Add another kind of "Zoom" mode that would let the user display in the hypnogram and spectrogram only the 1h period surrounding the current time. 3- Format the displayed Cursor time (and possibly the Go-To?) in hh:mm:ss format rather than seconds 4- (Possibly in a separate update): Set the default hypnogram value to 'artifact' rather than wake to avoid including unscored periods in further analysis. User can set it back to wake manually easily in the Scoring panel

Cheers, Tom

[TomBugnon]

By the way, another quite serious limitation I think is that ...

Sleep is actually quite SLOW to change from one epoch to the next for long recording.. This is very limiting, is there anything we can do about that besides reducing the sampling rate?

Example code for a 24h dummy dataset :

import numpy as np
from visbrain.gui import Sleep

nchan = 10
sf = 100
tEnd = 24 * 60 * 60 #24h
nsamples = tEnd * sf

data = np.random.rand(nchan, nsamples)

Sleep(
    data=data,
    sf=sf,
).show()

[raphaelvallat]

Thanks @TomBugnon! We've only worked with human sleep data so far, which are rarely longer than 12 hours, and thus I've never experienced any of these two issues (marker and speed). On the latter, I think @EtienneCmb will know better since he's the VisPy expert. Have you installed pyopengl_accelerate?

On the former, I'd prefer not overloading the main interface, but if you think this would make the user experience better, than please feel free to submit a PR. I wonder if we should consider creating two branches, i..e human vs animal? Though it may become a bit hard to synchronize everything with the master branch.

[EtienneCmb]

Hello @TomBugnon and @raphaelvallat ,

There's several reasons why it's slow :

• The data are simply to large, that's why the down-sampling is crucial. One possible workaround could have been implementing a lazy loading but it's totally not compatible with the current version of the code.
• Moving from one epoch to an other is probably dependent on the number of displayed channels
• The visual indicators are considerably slowing down the navigation. Try to hide them to see if there's a difference

[EtienneCmb]

About your four points, 2 and 3 are for me the most important ones. An other thing we could add is in the time axis, a simple line made of 0 and 1 reflecting epochs that have been edited (1) or not (0: default). May be this would avoid changing the default hypnogram value (4 -)

[skjerns]

@EtienneCmb is there anything that can be done about increasing/optimising the speed of displaying the next epoch?

Even with normal length sleep recordings I sometimes find it a bit slow (compared to commercial software, which is almost instantaneous). This is especially a problem if there are clear longer phases that I can quickly skim over. I don't know where the bottle neck is, but it seems to be dependent on the data size. If you point me to where the loading is done I can have a look (I already tried to find it, but was a bit lost in the code). Maybe some pre-loading can be done before the next epoch is requested.

Additionally I'd add a +1 to not set Wake as default for not-scored. This makes it quite hard in the end to know what has been scored and what not.

[EtienneCmb]

commercial software, which is almost instantaneous

Is it Python softwares?

[TomBugnon]

Thanks for the quick response @raphaelvallat @EtienneCmb.

About creating two branches, I guess it depends how much you guys want to be bothered with extending the software, how much "cluttering" of the default GUI is acceptable, and how much the "animal" and "human" versions of Sleep would differ. The two main things required for animal scoring are the shorter scoring window in https://github.com/EtienneCmb/visbrain/pull/53 which clutter a bit but not too much the human data scoring I think, and the flexible definition of stages suggested here https://github.com/EtienneCmb/visbrain/issues/35 which doesn't affect the GUI cluttering and is also useful for Human scoring (eg epileptic patients). We starting to use Sleep for animal scoring already so there's the incentive to put some work in on our side anyway, but your decision what to make of it :) (I think we can a single version suited for all uses)

In the case of the updates we're discussing here, I think they would make sense for both human and animal scoring (even though they're not indispensable for humans):

• Even with 8h recordings, I find that it's just a lot clearer to see this ("1h zoom"): than this (8h): And it only adds a single menu button and shortcut

• I like the idea of adding an "edited" marker on the time axis, I think it would solve that issue yes. It could look like this:

• About the cursor time formatting, I'm not sure what's best actually. It would be nice to have the "Go to" and cursor time be consistent but it's a bit cumbersome to set the GoTo in hh:mm:ss format.

[raphaelvallat]

These are all great ideas @TomBugnon @EtienneCmb. But I guess we would also need to export the "edited" binary time series to some sort of a text file so that users can keep track of multiple scoring sessions. An alternative would be to create a new integer value (e.g. -2) to the hypnogram to represent "unscored" data. This new value would be the default for not-scored data.

[skjerns]

commercial software, which is almost instantaneous

Is it Python softwares?

Most likely not (Alice Sleepware, REMLogic, Domino, etc)

still, might it be possible somehow to speed it up?

[EtienneCmb]

@raphaelvallat @TomBugnon if you both think that adding an "unscored" label to the hyprogram, I'm in too. However, from what I remember, this is going to require many modifications in the code because the states we used with Raph are really deeply integrated inside Sleep and I'm not sure the code is smart enough to just support adding a step. But if @TomBugnon thinks he can do it, and dig in, all good for me !

@skjerns when coding Sleep with Raph we had to choose between two GUI strategies :

• The soilution we choosed, having one panel per channel. This is nice because you can easily show / hide each channel independently and the GUI is dynamic. However, when you want to jump to the next epoch you've to loop over the displayed channels and update them. And as you know, Python loops are very slow
• The second possibility could to use one single panel with all the channels inside. With vispy, moving from epoch to an other could have been much faster. However, from the user perspective it's clearly not as good.

I think if you want to compare the performance of Sleep, you've to do it with a programming language that have performances that are relatively comparable (clearly not C/C++).

One thing to speed up navigation is to hide the visual indicators. Those are really slowing down. For sure, this is one point that can be improved.

[TomBugnon]

If we decide that adding an "unscored" label is a better option than the binary "edited" indicator, then it might be worth delaying this update until Sleep supports flexible state definition via config files. (I'm hoping to see this change happen or make it happen at some point). I think the 'unscored' label is a better option regarding speed, GUI simplicity, and interpretation of the exported hypnogram. Moreover the "edited or not" information provided by the binary indicator will be visible straight from the hypnogram.

I'll try and get the 1h-zoom done first. What do you guys think about the hh:mm:ss formatting?

Regarding speed, the visual indicators do make a serious difference indeed

[grahamfindlay]

Re. the speed of moving from one epoch to the next, it is hard to overstate how important this is. I have been trying to encourage the adoption of Sleep in my laboratory for several (6+) months now. I went and installed it on several people's computers, showed them how to use it, etc. Everyone looked at it and said, "Wow, this is great, I'd love to switch." And yet everyone went back to their original software (SleepSign, mostly), and the primary reason was always speed. It is a deal-breaker.

I agree that it is usually unfair to compare the performance of Python to C/C++, but at the same time, I use a Phy (a Python tool based on VisPy) to jump around massive datasets with hundreds of channels all the time, so I feel like it should be possible to get performance to a level that is good enough. Of course, I am completely ignorant of Sleep's internal architecture, and I appreciate that it would probably be a massive undertaking to make the necessary changes. But I just wanted to say that performance really did hinder adoption, at least here in Wisconsin.