Python Script Engine in Common Vision Blox
Beyond Bindings
Stemmer Imaging's Common Vision Blox (CVB) PyScript engine combines the advantages of classic embedded Python scripting with a more flexible and open technical approach. By attaching to an existing Python interpreter instead of embedding one, CVB avoids version lock-in, unnecessary dependencies, and limitations of the Python ecosystem. At the same time, users retain support for isolated environments, modern IDEs, and full debugging capabilities.
Bild: Stemmer Imaging AGVIDEO: How does CVB PyScript work?
While the user interface (l.) and the application workflow is ran by known ecosystems (e.g. Qt or WPF) in C++ and .NET, parts of special interest (algorithm, configuration, tuning) can be outsourced in isolated Python functions (r.).
Python has established itself as one of the most popular and widely used general- purpose programming languages. Consequently, it has its place in machine vision and image processing environments, alongside C, C++, and C#. It is not a universal replacement for these languages, nor is it suitable for every part of a vision system. However, Python offers a set of characteristics that make it particularly valuable in specific roles within vision applications. One of Python's key strengths is ease of use. Its readable syntax, dynamic typing, and low entry barrier enable fast development and short iteration cycles. This is especially helpful during prototyping, algorithm evaluation, parameter tuning, and when implementing application-specific logic that is expected to evolve over time.
Another important factor is the ecosystem surrounding Python. A large variety of mature libraries are available for numerical computation, image processing, data analysis, visualization, and machine learning. Libraries such as NumPy, SciPy, and various AI frameworks (e.g. Keras, TensorFlow, or PyTorch) allow developers to reuse proven building blocks. In many real-world vision systems, Python is therefore used primarily to orchestrate and connect processing components rather than to replace them.
In production environments, intellectual property protection plays a central role. Core algorithms, hardware interaction, and performance-critical processing steps are typically implemented in native code. In this context, Python's open nature can be a drawback only if sensitive IP is implemented directly in Python code. In practice, this is rarely the case. Python is usually positioned as a flexible glue layer between application logic and native processing libraries. The protected IP resides in compiled binaries, while Python is used for configuration, control flow, integration, and customization. This separation allows developers to benefit from Python's flexibility without exposing critical algorithms.
Bild: Stemmer Imaging AG
Bild: Stemmer Imaging AGExtending compiled applications with Python
Python is particularly effective as an interface language because it allows developers to separate concerns cleanly: stable, high-performance application code can remain native, while Python provides an interface to the core computer vision algorithms. Performance-critical components, UI logic, threading models, and long-term maintenance can stay in compiled languages that are well suited for robust desktop or industrial applications. At the same time, Python can expose those algorithms through a concise, readable API that lowers the barrier for development, testing, and experimentation. Also, referring to the above-mentioned popularity, this all comes without the overhead of learning a new scripting language. Embedding or integrating a Python scripting engine into a compiled vision application enables fast adjustments without recompiling or redeploying the entire system. Inspection logic, parameter handling, decision rules, or experiment-driven extensions can be implemented in Python and modified on site. This is especially valuable in industrial environments, where systems must adapt to new products, changing conditions, or evolving customer requirements.
CVB Python Script Engine
With Common Vision Blox 15.0, this approach is realised through the CVB PyScript engine. Following the most flexible approach, CVB does not embed its own Python interpreter. Instead, it chooses and binds to a Python interpreter that is already available on the target system. This approach avoids coupling CVB to a specific Python version. Users are free to choose and upgrade their Python installation independently of CVB releases. It also prevents unnecessary dependencies for users who do not require Python scripting at all. At the same time, attaching to a system interpreter provides unrestricted access to the full Python ecosystem as installed on the machine. For convenience, most complex CVB API types like images, streams or devices, can be passed seamlessly to Python, and received from it.
Despite not embedding an interpreter, isolated environments are fully supported. CVB PyScript can be used together with isolated environments created via tools such as pyenv or Python virtual environments (venv). This allows precise control over dependencies and package versions and enables clean separation between different applications or deployments. Furthermore, tooling and debugging are important aspects of daily life. Because the Python code is executed by a standard Python interpreter, developers can use their preferred IDE. Using pydebug, it is possible to set breakpoints and step through Python code that is executed by the interpreter. This allows interactive debugging, variable inspection, and step-by-step execution, even when Python scripts are invoked from within a compiled application. CVB 15.0 provides a small showcase application called ScriptLab that demonstrates the usage. While the native application provides a display and user interaction, device discovery and processing are done in Python. CVB PyScript positions Python where it delivers the most value: as a flexible extension layer for high-performance native components. The result is a practical scripting solution that integrates naturally into professional machine vision applications.
Stemmer Imaging's Common Vision Blox (CVB) PyScript engine combines the advantages of classic embedded Python scripting with a more flexible and open technical approach. By attaching to an existing Python interpreter instead of embedding one, CVB avoids version lock-in, unnecessary dependencies, and limitations of the Python ecosystem. At the same time, users retain support for isolated environments, modern IDEs, and full debugging capabilities.
Bild: Stemmer Imaging AGVIDEO: How does CVB PyScript work?
While the user interface (l.) and the application workflow is ran by known ecosystems (e.g. Qt or WPF) in C++ and .NET, parts of special interest (algorithm, configuration, tuning) can be outsourced in isolated Python functions (r.).
Python has established itself as one of the most popular and widely used general- purpose programming languages. Consequently, it has its place in machine vision and image processing environments, alongside C, C++, and C#. It is not a universal replacement for these languages, nor is it suitable for every part of a vision system. However, Python offers a set of characteristics that make it particularly valuable in specific roles within vision applications. One of Python's key strengths is ease of use. Its readable syntax, dynamic typing, and low entry barrier enable fast development and short iteration cycles. This is especially helpful during prototyping, algorithm evaluation, parameter tuning, and when implementing application-specific logic that is expected to evolve over time.
Another important factor is the ecosystem surrounding Python. A large variety of mature libraries are available for numerical computation, image processing, data analysis, visualization, and machine learning. Libraries such as NumPy, SciPy, and various AI frameworks (e.g. Keras, TensorFlow, or PyTorch) allow developers to reuse proven building blocks. In many real-world vision systems, Python is therefore used primarily to orchestrate and connect processing components rather than to replace them.
In production environments, intellectual property protection plays a central role. Core algorithms, hardware interaction, and performance-critical processing steps are typically implemented in native code. In this context, Python's open nature can be a drawback only if sensitive IP is implemented directly in Python code. In practice, this is rarely the case. Python is usually positioned as a flexible glue layer between application logic and native processing libraries. The protected IP resides in compiled binaries, while Python is used for configuration, control flow, integration, and customization. This separation allows developers to benefit from Python's flexibility without exposing critical algorithms.
Stemmer Imaging AG
Dieser Artikel erschien in inVISION 1 (März) 2026 - 04.03.26.Für weitere Artikel besuchen Sie www.invision-news.de
