Why WaveMe
Looking for a solution that involves a vision camera? Want a high-performance application that lets you call the shots? Then you should have a look at WaveMe. WaveMe is a platform that solves the common problems you will encounter when building vision applications that need access to high-end graphics. WaveMe is for you who find that Labview is too heavy, and writing an application from scratch is too much.
With this tech-talk, I would like to dive little deeper into what WaveMe offers as a generic programming environment and why you, or Senslogic, could build a high-performance tool with very little effort.
Basic Architecture
How does WaveMe do that? From the word go, WaveMe was designed to handle fundamentally diverse set of applications with the vision camera as the common component. The core of the platform is a pipeline handled by a pipeline manager which adds and removes modules (that’s your code) with defined in and output types.
The pipeline, as well as the rest of the application, is based on a producer-consumer paradigm. This goes for everything from images to memory allocation. The producer is usually a camera, but can be anything that generates data. Everyone can be a producer on the pipeline. The (ultimate) consumer is a compositor that handles all tasks related to displaying images, responding to graphics commands, handing events, and eventually retiring the data allocated by the producer when it is no longer needed. The only thing special about the compositor is that it runs in an OpenGL context, which means that we have access to the full set of OpenGL commands.
The platform comes with a whole lot of predefined graphics primitives, like drawing lines, polygons, circles, crosshairs, rendering text, and even displaying Zernike polynomials. If you don’t find what you like, you can easily add your own. That does come with some additional effort, but we are never limited by the platform which. If we need it, exposes the full glory of OpenGL to us.
Cooperative Modules
A WaveMe module is a library that brings it’s own user interface, defines its input and output types and will be added to a live pipeline where appropriate data is available. Modules work as filters and are cooperative. They see all data on the pipeline. A module typically does the following,
- Look at the type of the data
- If the data is an exit request, return with an exit code. This module is going away. The cleanup will be done with the registered cleanup functions you provided when starting the module
- Push the message down the pipeline if it’s not correct type and return with a continue code
- If the data is what we are looking for,
- Do the work and when we no longer need the data, give it back to the pipeline. Maybe some other module also wants it. It’s up to you. You can “drop” the data, thereby invoking its cleanup functions.
- We can also generate additional messages to be pushed down the pipeline to eventually be handled by the compositor.
- When all done, return with a continue code. The module will be woken up again when the next message arrives.
Mouse & Keyboard Events
When writing a full-fledged GUI application, there are many standard events to handle. WaveMe comes with a template where mouse and keyboard events are predefined so that they cooperate with the rest of the platform. By default, your application lives inside a tab alongside other modules. One of those is the module handling the camera. When you select the camera tab, WaveMe expects modules that currently handle keyboard and mouse events to let go and, conversely, to grab them when the module’s tab is selected. All that is handled by the standard template. All we need to do is the change the name of the template callback functions and add your own code, at least if we want to interact those events.
Graphical Toolkit & User Interface
WaveMe is based on GTK4 and glib-2.0 for its user interface, and much of the way in which modules interact with the pipeline follows the patterns used by those libraries.
It assumes that the camera provides a constant flow of images with modules responding by generating messages based on what they see. This semantics fits well with graphical elements which are tracking some property of every image.
This behaviour may not fit everything so we may need to change it. The compositor, unless told otherwise, assumes all objects it receives are persistent and that another message with the same ID is only a few milliseconds away. There are things we may want to do that do not fit that description. For example, if we want to change a color map, that’s definitely a message that doesn’t need a follow-up. For these types of messages, we must mark the message as one-off. Shoot and forget. The action part of the message will be called once and never again.
One last thing worth mentioning at least once, all messages can have a cleanup function, and the cleanup function runs inside on OpenGL context. If we need to peek into the OpenGL state and send it back to the application, this is the place to do it.
Summing Up
I hope that I have given a glimpse of what WaveMe can do and how. Some things have not been covered, such as how we build the user interface, or at least the parts of the user interface that are specific to WaveMe. Much of that is covered in the template from which all modules currently available for WaveMe are derived. The general philosophy is to keep a template that covers all the bases and extend from that with the specifics of each application. Having written a couple of them already, I think WaveMe has evolved to a reusable platform from which many applications can build quickly. Give it a thought. Maybe even give it a shot. Feel free to contact me at [email protected] if you’d like to see if WaveMe can be a fit for you too.
Leave a Reply