EventViewer as part of ctapipe-process tool

[maxnoe]

This adds a QT based GUI EventViewer that can be started and used to browse through event data using ctapipe-process -i <file> --viewer.

Add the moment, I only added rudimentary displays of the subarray and of the dl1 intensity image, mainly to test that the general approach works and to gather some early feedback.

I think it should have:

• [ ] Reconstruction view like @kosack is working on here: #2539
• [ ] Waveform view when clicking on a pixel in the image viewers
• [ ] peak_time image
• [ ] table views for the container data

To launch, on this branch make sure to have pyside6 installed: mamba install pyside6 and then run:

ctapipe-process --viewer -i dataset://gamma_prod5.simtel.zst

[kosack]

Features I would want (some are already mentioned above):

• DL1/DL0: on DL1 charge/peak_time display: if DL0 or below exists, ability to plot waveforms on click (perhaps shift-click to plot multiple waveforms on the same plot). Ideally with charge extraction windows overlaid as plt.axvspan if there is a charge extractor that uses windows.
• DL1: mark clean pixels (or option to show only cleaned pixels)
• DL1: option to show Muon fit overlays (e.g. ring and width) for debugging muon analysis
• DL2: in addition to the ellipse-style ground and sky intersection plots, a summed image plot, probably using resampling to show all cameras the same plot (I have a nice script for that, will add it to a gist or link it here) with optional overlay of Hillas ellipses. Maybe also the ground plot with images, though that can get very large and slow

Another question that came up for me when I was making the Reco display: should we stick with matplotlib for this type of interactive plot, or use Bokeh? The advantage of Bokeh is that it is much faster at interactive drawing, particularly if you want to switch between many CameraDisplays. The disadvantage is is doesn't produce nice PDF output for papers/presentations (it only does PNGs, which are not quite as nice and scalable).

Another advantage of Bokeh is that you can use it for all the controls/tabs/etc, and avoid Qt dependencies, and that way a viewer can also be use in a notebook.

[maxnoe]

The advantage of Bokeh is that it is much faster at interactive drawing,

Is that true? I also notice quite a delay when updating the browser based figures / overlays / pixel values using the bokeh viewer.

After creating the matplotlib objects, drawing them is quite fast (the camera viewer now creates one display per camera type and just updates the image when telescope / event are changed).

[kosack]

Is that true? I also notice quite a delay when updating the browser based figures / overlays / pixel values using the bokeh viewer.

I think that's more of an issue with how it's implemented in ctapipe: I was able to get very fast camera displays going with essentially realtime image changes, even re-creating all pixel glyphs on each frame ( e.g. with an interactive slider to select the cleaning threshold), but that wasn't using exactly the ctapipe implementation. Mostly it's just that Bokeh is designed for interactive graphics, while matplotlib is more designed towards nice publication-quality rendering.

After creating the matplotlib objects, drawing them is quite fast (the camera viewer now creates one display per camera type and just updates the image when telescope / event are changed).

Yes, it may be fine if that is how it is implemented, and I do generally prefer the nice output of matplotlib. The CameraDisplays were designed to be fast at updating, but not fast to create. I can get about 20 frames per second, though, which isn't bad. With bokeh, it's much more, but perhaps it's not worth the effort.