Add `cameleon-gui`

[Y-Nak]

Feature

We need a GUI for new cameleon users and for debugging purposes.
Probably this should be done in another repository.

Implementation

⌨️

Drawbacks

None

[bschwind]

Did you have any tech choices in mind for this issue? There's egui paired with glium or wgpu, as well as many other up-and-coming Rust UI frameworks (slint, iced, dioxus, etc.)

I'd be interested to see a list of requirements for this and help out if I can.

[Y-Nak]

Thanks for your interest!

We tested iced for the GUI one year ago, and it seemed to work well. Unfortunately, the GUI project stalled, and we couldn't make it public.
But yeah, it feels like the time to revisit the GUI feature.

Requirements

Basically, the more elegant pylon-viewer is in my mind as the GUI.

So the rough sketch would be the below.

• Displaying the image stream with proper pixel format conversion in real-time. We may need to use OpenCV for various pixel conversions, but it'd be better to design the GUI to work well without OpenCV, though the available pixel format conversions would be less than with OpenCV.
• Multiple camera connections and simultaneous multiple stream displays.
• Saving images.
• Intuitive but a fully-functional interface to modify camera parameters.
• Saving/Loading camera parameters. These parameters would be stored in a human-readable file, e.g., toml.

Please feel free to ask any questions. Also, I'm happy to hear your suggestions/opinions.
Anyway, I'll make the repository for the cameleon-gui and make it public so that we can start hacking.

[bschwind]

@Y-Nak thanks for laying out some of those requirements, this is great.

I work at tonari and we're currently evaluating switching to GenICam-compatible cameras. We currently have an internal tool for connecting to various cameras, doing pixel conversions, and displaying a live feed while allowing you to adjust a few select camera parameters and other image processing values. It's currently based on egui.

Not all of it is relevant to cameleon and GenICam, but in short I have some experience building this kind of tool and would be happy to help.

I agree that it would be nice to avoid OpenCV if we can - most pixel conversions can happen in GPU shaders which gives a massive speedup compared to CPU approaches. We currently use OpenGL for some older compatibility reasons, but I imagine this tool could be easily based on WPGU to get better cross-platform support for things like compute shaders, and a more modern API to work against.

I'll take a look at Iced again and compare to egui, I know System76 is picking up Iced and improving it a lot for the work on their distro so maybe that will soon have better support. That being said, egui is very easy from a developer perspective, both to integrate with things like wgpu/opengl, and for day-to-day UI dev.

I see it has a wgpu integration example so that's probably a good place to start (or perhaps cameleon-gui has already started there).

I'm assuming we don't need to support the ability to run this in a browser, right? I think the limiting factor there would be USB access to the camera, but maybe that's possible with WebUSB...

[Y-Nak]

@bschwind Thanks for your feedback!

I have some experience building this kind of tool and would be happy to help.

I appreciate your help and am happy to work on the task together.
I made cameleon-gui public, which contains init branch as a PoC work.

this tool could be easily based on WPGU

I fully agree with the idea. I'll look through egui and its integration example with wgpu.

I'm assuming we don't need to support the ability to run this in a browser, right?

Yes, I don't think we should support it for now. I may start to consider when cameleon reaches more users :).

BTW, do you have any preference for the way to push the GUI implementation forward? I think we would need an initial minimal implementation for collaborative work to start adding features on top of it.
So, if you want to work on the initial implementation, I'm willing to hand it over to you. Or if you feel it weighs on you, then I'll start working on it. Either is completely fine for me.

[bschwind]

@Y-Nak I think I'll leave the higher level direction and technical choices to you (whether to use Iced or egui) as I don't want to force an opinion there.

I'm happy to create a starter project in egui though if you really have no preference on the matter.

Assuming we're eventually moving the captured frame into a GPU texture to display, my main helpful contributions would probably be writing shaders which do the color conversions, to keep things speedy. I'll take a look at the existing code to see what's there so far.