"Halcon联合编程官方文档：HALCON 21.11编程指南"

需积分: 1 185 浏览量更新于2024-04-10 1 收藏 2.03MB PDF 举报

The HALCON Unified Programming Official Documentation provides comprehensive guidance on utilizing the programming language interfaces of HALCON, Version 21.11.0.0. Developed by MVTec Software GmbH, this guide covers all aspects of programming with HALCON and is a valuable resource for developers and programmers. The document is protected by copyright and prohibits reproduction or distribution without prior written consent from the publisher. MVTec Software GmbH, based in Munich, Germany, retains all rights to the content within the HALCON Unified Programming Official Documentation. By following the guidelines outlined in this guide, users can effectively leverage HALCON's powerful features for machine vision applications. Whether it be image processing, object detection, or geometric measurements, HALCON offers a wide range of functionalities that can be implemented through various programming interfaces. HALCON's versatility and flexibility make it a popular choice among developers seeking to integrate machine vision capabilities into their applications. With the HALCON Unified Programming Official Documentation as a reference, programmers can confidently develop solutions that meet their specific requirements while taking advantage of the latest features and enhancements in HALCON Version 21.11.0.0. Overall, this guide serves as a comprehensive resource for anyone looking to harness the full potential of HALCON for machine vision programming. From basic concepts to advanced techniques, the HALCON Unified Programming Official Documentation covers it all, empowering users to unlock new possibilities in the field of machine vision technology.

16 Parallel Programming and HALCON

2.1.2 The Methods of Automatic Parallelization

For the automatic parallelization of operators, HALCON exploits data parallelism, i.e., the property that parts of

the input data of an operator can be processed independently of each other. Data parallelism can be found at four

levels:

1. tuple level

If an operator is called with iconic input parameters containing tuples, i.e., arrays of images, regions, or

XLDs, it can be parallelized by distributing the tuple elements, i.e., the individual images, regions, or

XLDs, on parallel threads. This method requires that all input parameters contain the same number of

tuple elements (or contain a single iconic object or value).

2. channel level

If an operator is called with input images containing multiple channels, it can be parallelized by distributing

the channels on parallel threads. This method requires that all input image objects contain the same number

of channels or a single channel image.

3. domain level

An operator supporting this level can be parallelized by dividing its domain and distributing its parts on

parallel threads.

4. internal data level

Only parts of the operator are parallelized. The actual degree of parallelization depends on the implemen-

tation of the operator. As a result, the potential speedup on multi-core systems varies among operators

utilizing this parallelization method.

The description of a HALCON operator in the Reference Manuals contains an entry called ’Execution Informa-

tion’, which speciﬁes its behavior when using HALCON on a multi-core or multi-processor hardware. This entry

indicates whether the operator will be automatically parallelized by HALCON and by which method (tuple, chan-

nel, domain, internal data).

The parallelization method of an arbitrary operator opname can also be determined using get_operator_info:

get_operator_info('opname', 'parallel_method', Information)

2.2 Parallel Programming Using HALCON

HALCON supports parallel programming by being thread-safe and reentrant, i.e., different threads can call HAL-

CON operators simultaneously without having to wait. However, not all operators are fully reentrant. This section

takes a closer look at the reentrancy of HALCON. Furthermore, it points out issues that should be kept in mind

when writing parallel programs that use HALCON.

The example program example_multithreaded1.c in the directory example\c shows how to use multithread-

ing to extract different types of components on a board in parallel using HALCON/C.

Furthermore, HALCON provides special operators to synchronize threads (see section 2.2.3 on page 18).

2.2.1 A Closer Look at Reentrancy

In fact there are different “levels” of reentrancy for HALCON operators:

1. reentrant

An operator is fully reentrant if it can be called by multiple threads simultaneously independent of the data

it is called with.

Please note that you must take special care when multiple threads use the same data objects, e.g., the

same image variable. In this case, you must synchronize the access to this variable manually using the

corresponding parallel programming mechanisms (mutexes, semaphores). Better still is to avoid such

cases as far as possible, i.e., to use local variables. Note that this is no special problem of HALCON but of

parallel programming in general.

2.2 Parallel Programming 17

2. local

Operators marked as local should be called only from the thread that instantiates the corresponding objects.

3. single write multiple read

A certain group of operators should be called simultaneously only if the different calling threads work on

different data.

As this thread behavior is not recommended quite generally, HALCON does not actively prevent it and

thus saves overhead. This means that if you (accidentally) call such operators simultaneously with the

same data no thread will block, but you might get unwelcome effects.

4. mutually exclusive

Some operators cannot be called simultaneously by multiple threads but may be executed in parallel to

other HALCON operators.

5. exclusive

A group of operators is executed exclusively by HALCON, i.e., while such an operator is executed, all

other threads cannot call another HALCON operator.

6. independent

A group of operators is executed independently from other, even exclusive operators.

As mentioned already, the description of a HALCON operator in the Reference Manuals contains an entry called

’Execution Information’, which speciﬁes its behavior when using HALCON. This entry speciﬁes the level of

reentrancy as described above.

2.2.2 Program Design Issues for Parallelization

The following issues have to be considered for multithreaded programming in general:

• Number of threads ≤ number of processors or cores

If you use more threads than there are processors or cores, your application might actually be slower than

before because of the synchronization overhead. Note that when counting threads only the so-called worker

threads are relevant, i.e., threads that are running / working continuously.

• Local variables

If possible, use local variables, i.e., instantiate variables in the thread that uses them. If multiple threads use

the same variable, you must synchronize their access to the variable using the appropriate parallel program-

ming constructs (mutexes, semaphores; please refer to the documentation of your programming language for

details).

When using HALCON, please keep the following issues in mind:

• Initialization

HALCON is initialized implicitly at the ﬁrst operator call. During this initialization, among others, the li-

cense is checked, HALCON memory management is set up, the thread pool for internal operator paralleliza-

tion is started, internal system parameters and synchronization objects are initialized. This initialization

process is thread safe in a multithreading environment.

Note that the default value of some system parameters can be changed before this initialization process.

Compare the include/HGlobal.h ﬁle and some references to the corresponding parameters in this document.

If used, make sure that all default values are set before calling the ﬁrst operator in your multithreaded envi-

ronment.

• I/O and visualization

Keep in mind that operators which create or delete ﬁles work exclusively, i.e., other threads have to wait.

The programmer has to assure that threads do not access the same ﬁle (or handle) simultaneously!

See section 2.3 on page 18 for information about visualization issues on different operating systems.

• Multithreading vs. automatic parallelization

If you explicitly balance the load on multiple processors or cores in a multithreaded program, we recommend

that you either switch off the automatic parallelization mechanism to get an optimal performance or reduce

the number of threads used by it so that the sum of threads does not exceed the number of processors or

cores. How to switch of the automatic parallelization or reduce the number of internal threads is described

in section 2.5.1 on page 20.

General Issues

2.4 Using HALCON with OpenMP 19

All HALCON graphic operators are automatically redirected to the correct thread. This is done by sending a

special message to the window. To avoid conﬂicts with user code, the ID of this message is dynamically generated

using the Win32 RegisterWindowMessage function. For windows not created by HALCON (this is relevant

to open_ext_window and when specifying a parent window to open_window, the (non-HALCON) window is

automatically subclassed using the Win32 SetWindowSubclass function. The only requirement for user code is

that for this mechanism to work, each window must have an active message loop.

To avoid having to write user code to handle the message loop of a HALCON window, HALCON can be instructed

to create all top level HALCON windows from a special thread via set_system(’use_window_thread’,’true’),

which will then also take care of the message loop. Note that this may negatively affect performance if many

windows are used simultaneously, as HALCON provides only a single thread for all windows.

2.3.2 X11

When using the X11 windowing system, HALCON will automatically call the Xlib function XInitThreads when

the ﬁrst window is opened (note that querying the available OpenGL features will open a hidden X11 window in

the background).

This means that if an application using HALCON also uses Xlib functions independently of HALCON, either

directly by explicitly calling Xlib functions or indirectly through some other library that uses Xlib, care must be

taken that XInitLibrary is called ﬁrst before any other Xlib function. The easiest way to ensure this is to call

XInitThreads very early in the application’s main function, before calling any other library functions.

2.3.3 macOS

On macOS, any operation that manipulates the NSView hierarchy must be done from the main thread. Furthermore,

to ensure events are processed in the correct order, any access to the event queue should also be done from the main

thread.

All HALCON graphic operators are automatically redirected to run from the main thread. This is done by using

Grand Central Dispatch to dispatch the execution of HALCON operators as tasks to the main thread’s dispatch

queue. In order for this to work, the main thread must call dispatch_main or conﬁgure a run loop as described in

Apple’s “Concurrency Programming Guide” for macOS. Please note that since HALCON uses AppKit to display

windows, the main thread should also be handling events from the window server. Standard Cocoa applications

that call NSApplicationMain satisfy this requirement automatically, but C or C++ code exported by HDevelop

does not, as this requires creating an application bundle, which is beyond the scope of the HDevelop code exporter.

2.3.4 Additional Considerations Applicable to Windows and macOS

The various HALCON draw_* operators work by actively polling the message (Windows) or event (macOS)

queue. Since all graphics operators are run on the main thread in macOS, only a single draw_* operator can be

active at any given time. On Windows, several draw_* operators can be active if they target windows belonging to

different threads.

2.4 Using HALCON with OpenMP

Using different OpenMP runtimes in a single program leads to an undeﬁned behavior. Thus, if you have an

application using HALCON and OpenMP, meaning your application uses the halcondl library and OpenMP, you

have to link against the Intel OpenMP library libiomp5. The latter one is installed with HALCON. For the linking,

the necessary steps depend on your platform:

Windows: You can do this over Visual Studio:

1. Open Visual Studio.

2. Go to Project Properties → Linker → Input.

3. Add vcomp.lib (vcompd.lib for the debug conﬁguration) to Ignore Specific Default Li-

braries

General Issues

20 Parallel Programming and HALCON

4. Add libiomp5md.lib from %HALCONROOT%\lib %HALCONARCH% to the Additional Dependen-

cies.

Linux/MacOS: For gcc and clang, add

• -fopenmp to the compile ﬂags

• -L$HALCONROOT/lib/$HALCONARCH/thirdparty -liomp5 to the linker ﬂags

Note, that the default installation of clang on macOS does not support OpenMP.

2.5 Additional Information

This section contains additional information that helps you to use HALCON on multi-core or multi-processor

hardware.

2.5.1 Customizing the Parallelization Mechanisms

With the help of HALCON’s system parameters, which can be set and queried with the operators set_system and

get_system, respectively, you can customize the behavior of the parallelization mechanisms.

You can query the number of processors (or cores) by calling

get_system('processor_num', Information)

You can switch off parts of the features of HALCON with the help of the operator set_system. To switch off

the automatic parallelization mechanism, call (HDevelop notation, see the Reference Manual for more information)

set_system('parallelize_operators','false')

To switch off reentrancy, call

set_system('reentrant','false')

Of course, you can switch on both behaviors again by calling set_system with ’true’ as the second param-

eter. Please note that when switching off reentrancy you also switch off automatic parallelization, as it requires

reentrancy.

A reason for switching off the automatic parallelization mechanism could be if your multithreaded program does

its own scheduling and does not want HALCON to interfere via automatic parallelization. Note that you do not

need to switch off automatic parallelization when using HALCON on a single-processor or single-core computer;

HALCON does so automatically if it detects only one processor or core.

When switching off the automatic parallelization, you might consider switching off the use of thread pools (see the

parameter ’thread_pool’ of set_system).

Please do not switch on reentrancy if this is already the case! Otherwise, this will reset the parallelization!

system, which includes switching on the automatic operator parallelization. This will decrease the performance in

case of manual parallelization (multithreading).

With the system parameter ’parallelize_operators’ you can customize the automatic parallelization mecha-

nisms in more detail. Please see the description of set_system for more information.

Finally, you can inﬂuence the number of threads used for automatic parallelization with the parameters

’thread_num’ and ’tsp_thread_num’ (set_system). Reducing the number of threads is useful if you also

perform a manual parallelization in your program. If you switch off automatic parallelization permanently, you

should also switch off the thread pool to save resources of the operating system.

剩余198页未读，继续阅读

qxhhhh

粉丝: 10

"Halcon联合编程官方文档：HALCON 21.11编程指南"

QT与Halcon联合编程示例程序2022.4.3.zip

MFC和Halcon联合编程程序

海康相机通过SDK二次开发与Halcon混合编程.7z

QT和halcon联合编程

halcon联合编程初始化

qt联合halcon编程

halcon联合c#编程

Halcon联合C#编程

qt联合halcon编程如何配置

c#联合halcon 建立定位编程範例

最新资源