Providing example GUIs for users to build upon #38
Comments
|
Here's some progress: |
|
This is awesome! Some comments:
More potential additions if useful:
Out of original scope but very useful:
Iteration 2: how can we potentially include camera data? |
|
These things are implemented:
These things I'm unsure about:
For later:
Other information: I made a change to save trigger data as a CSV using the same pattern that's used to save video data. I noticed the CSV file is created even if no data is written to it |
|
This is awesome, it's so great to see it taking shape, thank you, Cris. Some more asks after reviewing the docs:
|
It makes sense that that's how users are expected to user it. But I'm not sure we want UI elements to have side-effects like this. I think for now it's ok that they have to manually set it, and we can come back to this on the next GUI revision (when we get feedback, add the bobblehead visualizer, etc.)
That seems important. I'm going to implement this and push the corresponding change in PR #41 (commit: 4dbbc56)
Not sure we should expose this to user. We want a simplified GUI. But I will make it easier to change in the workflow, and add a note about how to change it in the tutorial
Oh you're right, the visualizer only allows limit changes in the standalone visualizer, not the one embedded in the GUI. Not sure how to do this, I'm leaving it for now. |
The approach here would be three-fold:
Modular examples of additional processing and how to edit the standard layout to include them. These can be miniscope specific, such as ROI intensity dynamics, a maximum intensity projection to identify cells, a heading calculation from the quaternion data, etc. Additionally, we could show some other typical experimental data viz such as a behavioral camera view, centroid tracking, 2D histogram of space occupation, etc. This is to inspire users to make their own custom representations according to their experimental needs.
A proper GUI would have to include record control and file management. Not only a Record button on the UI, but also settings such as path, encoding, recording length, etc. The logic to make this would define a folder structure that therefore can provide standarization for miniscope data acquired in Bonsai. In turn, having a standardized data structure and format makes it easier to interface with open sharable data analysis pipelines.
These thoughts are obviously heavily inspired by the existing functionality of the Miniscope-DAQ-qt soft from the UCLA Miniscope Team and the OEGUI modularity, and pushed forward by user requests. Once we have a prototype, we should ask for feedback and contributions. The scope has to be clear because, even with all of Bonsai's interoperability and flexibility, I'm not sure making layouts will make for a true bespoke GUI application. Such an application additionally needs to log changes in parameters and report meaningful errors for troubleshooting.
The text was updated successfully, but these errors were encountered: