Ideas for further refinement of example GUIs for users to build upon

[ChucklesOnGitHub]

The approach here would be three-fold:

1. A standard layout that shows all the datastreams and the control panel, with some additional visualization processing / quantification that will be useful for most users. This would be useful in the context of acquisition: seeing the data flowing in and adjusting parameters. A rough mockup is below. It includes the image, imu and digital input data representations, and df/f, saturation and pixel intensity.

2. 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.

3. 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.

[cjsha]

Here's some progress:

miniscope-gui.zip

[ChucklesOnGitHub]

This is awesome! Some comments:

• could we have two numbers, one for elapsed acquisition time (start of wf) as well as one for elapsed recording time?
• make sure all data is getting timestamped
• do ppl want property values to be persistent or initialize to a set value when wf is opened
• add duration units ("seconds") to the recording duration
• fix the y value of the Input Trigger graph
• see how to handle exception of not having a suffix and hitting record without overwrite

More potential additions if useful:

• look into example workflows and see if the gui could use buttons to control things
  • commutator functionality idk enable/disable
  • a checkbox for triggering recordings based on Input trigger = TRUE? Under the RecordingDuration checkbox.
• max pixel value projection over many frames to be able to count cells (in a radio button)

Out of original scope but very useful:

• have the ability to supply a filename and playback videos

Iteration 2: how can we potentially include camera data?

[cjsha]

These things are implemented:

• could we have two numbers, one for elapsed acquisition time (start of wf) as well as one for elapsed recording time?
• make sure all data is getting timestamped
• add duration units ("seconds") to the recording duration
• a checkbox for triggering recordings based on Input trigger = TRUE? Under the RecordingDuration checkbox.

These things I'm unsure about:

• do ppl want property values to be persistent or initialize to a set value when wf is opened
  • I think values should persist, I think that makes the GUI easier to use.
• fix the y value of the Input Trigger graph
  • I'm not sure what you mean by this, but people have the capacity to right-click the graph and change zoom or whatever

For later:

• see how to handle exception of not having a suffix and hitting record without overwrite
  • I'm not immediately sure the best way to handle this
• button for commutator functionality idk enable/disable
• have the ability to supply a filename and playback videos
• max pixel value projection over many frames to be able to count cells (in a radio button)

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

miniscope-gui.zip

[ChucklesOnGitHub]

This is awesome, it's so great to see it taking shape, thank you, Cris. Some more asks after reviewing the docs:

• have the "Reecord On Trigger" button also change the LedRespectsTrigger property to True, and back to False again when the button is deselected, because that is how most ppl will intend the recording trigger to be used (LED is on when trigger signal is high and thus recording files).
• have the recorded file increment on each hardware trigger instead of appending the frames to the same file
• expose the FourCC propery in the properties pane?
• fix the y value of the Input Trigger graph -> here I meant to say we could fix ylim at, say (0,1.1) because the values are going to be either 0 or 1 and otherwise the graph initializes as -1 and 1 and then jumps. Just cosmetic. I was unable to change the ylim during acquisition, only by editing the workflow normally.

[cjsha]

have the "Reecord On Trigger" button also change the LedRespectsTrigger property to True, and back to False again when the button is deselected, because that is how most ppl will intend the recording trigger to be used (LED is on when trigger signal is high and thus recording files).

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.)

have the recorded file increment on each hardware trigger instead of appending the frames to the same file

That seems important. I'm going to implement this and push the corresponding change in PR #41 (commit: 4dbbc56)

expose the FourCC propery in the properties pane?

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

fix the y value of the Input Trigger graph -> here I meant to say we could fix ylim at, say (0,1.1) because the values are going to be either 0 or 1 and otherwise the graph initializes as -1 and 1 and then jumps. Just cosmetic. I was unable to change the ylim during acquisition, only by editing the workflow normally.

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.

[ChucklesOnGitHub]

In the latest one, the GUI seems to be producing the quaterion data files even though I haven't pressed record. this is known, right? it's what happens with onix too.

re: the "Record On Trigger", in the tutorial I wanted to add that users should change the LedRespectsTrigger property to True, but I haven't had time to edit the source.

[cjsha]

Tech meeting 2025-07-16:

• Move this thing to its repo. This could be its own application which runs bonsai headlessly.
• We discussed a way to change index in the GUI using a higher-order observable which would allow run-time subscription of miniscope node.
• It should go in a gallery.

[ChucklesOnGitHub]

A first pass of this tutorial is here #41
And these discussions can serve for further refinement in the future.