Detailed Description of Changes in HALCON 19.05.0.0 Progress

The changes in HALCON 19.05.0.0 Progress are described with respect to HALCON 18.11 Progess.

HDevelop

New Functionality

GUI

HALCON has been extended with means to configure the fill style for displaying XLD contours. The operators set_contour_style, get_contour_style, and the respective HDevelop operator dev_set_contour_style have been added to enable this.
The pie charts displayed by the evaluation procedures for deep learning have been adapted to use this new functionality. Note that this change affects the compatibility. Read more.
HDevelop’s Program Window icons like program counter and break points now adjust their size depending on the chosen font size.
The font size in the Program Window of HDevelop can now be adjusted via
- the mouse wheel + CTRL or via
- CTRL+Plus to increment the font size and
- CTRL+Minus to decrement the font size.

Help

The usability of the HDevelop help has been improved. Now, a search in the HDevelop help also returns results from the procedures located in HDevelop’s standard procedure path (if the search option “Reference” is checked).

Miscellaneous

The content of HDevelop’s main title bar has been improved.

Bug Fixes

Code Export

HDevelop’s C export sometimes generated invalid code when the source program contained deactivated or invalid lines. This problem has been fixed.
Exporting empty vector literals in control expressions to C# or VB.net could have led to syntactically incorrect code. This problem has been fixed.
The export to C# and VB.net did not work correctly for direct modification of global tuple elements containing handles. This problem has been fixed.
Exporting all procedures of a library could have led to duplicate procedures in the exported code. This problem has been fixed.
HDevelop exported empty vector literals in block statements (e.g., if) incorrectly when called via command line. This problem has been fixed.

GUI

The Object Model 3D Inspect Window showed at most 10 extended attributes per 3D object model. If the 3D object model contained more than 10 extended attributes, the names and types of only the first 10 were shown. This problem has been fixed. The Object Model 3D Inspect now shows the names and types of all extended attributes.
Calling open_window in HDevelop on a macOS platform caused an error. This problem has been fixed.
Under certain conditions HDevelop’s Training File Browser crashed when loading a training file for (at least) the second time. This problem has been fixed.
After switching the encoding of the HALCON library to locale with set_system(‘filename_encoding’, ‘locale’), the Read Image dialog was not able to load images with non-ASCII characters in the path or filename. This problem has been fixed.
Using the magnify mode in the HDevelop Graphics Window could have caused a crash on some systems. This problem has been fixed.

IDE

If the program counter was on the last line of an if-block in an if–else-statement or the last line of a try-block in a try–catch statement, and that line was removed or deactivated, the program counter would have moved to the following else– or catch-block even though these should not normally be executed. This problem has been fixed. Now, the program counter moves past those blocks.
Undo did not work correctly after renaming a procedure parameter via the Edit Procedure Interfaces dialog when the new parameter name was already used by a local variable in the procedure. This problem has been fixed. Additionally, HDevelop highlights the edit field of the parameter when a name conflict with a local variable exists.
Calling close_window with a window handle that was obtained with dev_open_window or dev_get_window crashed HDevelop (with some delay). This problem has been fixed. Now, the corresponding Graphics Window is closed. Note that nonetheless the use of close_window in HDevelop is not recommended by any means. Please, use dev_close_window instead.
On a few Linux systems, the description in the “Attach To Process..” dialog was cut off. This problem has been fixed. Now, it is possible to store the size of the dialog so the user can read the description after reopening the dialog.
Until now, when a control variable stops to exist, all open Variable Inspect Windows, which displayed that variable, were closed, regardless whether a Variable Inspect Window also displayed other (still valid) variables. This problem has been fixed. Now, the Variable Inspect Windows are kept open as long as they display at least one valid variable, and only the vanished variables are removed.
Commenting a catch did not comment the try–catch block inside HDevelop. This problem has been fixed.

Procedures

In rare cases, HDevelop crashed when the user deactivated a user-defined procedure directory. This problem has been fixed.
Attempting to load corrupted procedures of a certain type crashed HDevelop. This problem has been fixed.
In rare cases, HDevelop corrupted code lines when pasting the bodies of copied procedures. This problem has been fixed.
When the protection status of programs or procedure libraries, which were protected in the old protection format as a whole, was modified, HDevelop popped up a warning about the protection format change for each procedure in the affected file. This problem has been fixed. Now, only one message per program/library is displayed. Note however, that for local or library procedures, which are protected independently, HDevelop still displays a warning for each modified procedure.

Miscellaneous

HDevelop features an “Extended error code”, which will be set when, e.g., a dynamic library could not be opened (HALCON error code: 8600). When running a different HDevelop program in the same HDevelop session later, and a regular exception was raised, HDevelop again presented the old extended error code from the previous program. This problem has been fixed.
Calling dev_clear_obj on a global variable can cause a crash with JIT execution. Procedures containing such a call will now be executed without JIT compilation. If this affects the performance of your scripts, please move time-critical calculations into a separate procedure.
C++ code exported by HDevelop for comparison operators in expressions (e.g., “a := b + (c<d)”) did not compile with all C++ compilers. This problem has been fixed.
On Japanese Windows systems, the sub dialog “Add Samples From A System Font” of the OCR Training File Browser showed very small symbols in the left list view. This problem has been fixed.
On rare occasions, deactivating a for/while loop crashed HDevelop. This problem has been fixed.
dev_disp_text did not correctly display non-ASCII characters in the HDevelop Graphics Window when the HALCON library was set to locale encoding (set_system(‘filename_encoding’, ‘locale’)). This problem has been fixed.
dev_get_window is specified to return -1 if no window is available. However, for implementations in engine applications, this case was not handled correctly. In particular, with JIT compilation an invalid handle could have led to a crash and in HDevEngine/.NET an empty tuple could have been returned even in a non-JIT case, changing the behavior of the script code. This problem has been fixed. Now, always -1 will be returned. Note that user implementations should never return a numeric value except for legacy mode. Instead, indicate the invalid value with an empty tuple or an empty handle.

HDevelop Example Programs

New HDevelop Example Programs

hdevelop/3D-Object-Model/Segmentation/sample_object_model_3d.hdev
hdevelop/Deep-Learning/Detection/dl_detection_with_orientation_workflow.hdev
hdevelop/Deep-Learning/Detection/dl_detection_workflow.hdev
hdevelop/Deep-Learning/Segmentation/dl_segmentation_workflow.hdev
hdevelop/Image/Acquisition/genicamtl_io_control.hdev
hdevelop/Image/Acquisition/gigevision2_io_control.hdev
hdevelop/Image/Acquisition/gigevision2_roboception_rcvisard_objectmodel3d.hdev
hdevelop/Image/Acquisition/gigevision2_wenglor_shapedrive_objectmodel3d.hdev
hdevelop/Image/Acquisition/usb3vision_io_control.hdev
hdevelop/Matching/Shape-Based/find_shape_low_contrast_high_noise.hdev
hdevelop/Matching/Shape-Based/find_shape_model_clutter.hdev
hdevelop/Tools/Geometry/area_intersection_rectangle2.hdev
hdevelop/Tools/Mosaicking/two_camera_calibrated_mosaicking.hdev

New Functionality

select_points_object_model_3d now accepts a tuple of numbers instead of an attribute name as input on which the threshold is applied. This allows to select points based on some mask without first setting that mask as attribute in the 3D object model. The HDevelop example program hdevelop/3D-Object-Model/Segmentation/select_points_object_model_3d.hdev has been extended to show this new functionality.
The operators find_surface_model, find_surface_model_image, refine_surface_model_pose, and refine_surface_model_pose_image now accept multiple values in their MinScore argument. Those values can be used to set minimum scores for the surface overlap, the 3D edge overlap, and for image-based operators, the 2D edge overlap. Additionally, the values of these scores can be obtained using the operator get_surface_matching_result. The visualization of the corresponding surface matching result handles in the handle inspection windows has been adapted accordingly.
The HDevelop example program hdevelop/3D-Matching/Surface-Based/find_surface_model_with_edges.hdev has been extended to show the new functionality.

Bug Fixes

In the HDevelop example programs hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_3_evaluate.hdev and hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_3_evaluate.hdev the batch size was set after the call of set_dl_model_param (DLModelHandle, ‘runtime_init’, ‘immediately’). This could have led to an out of memory error. This problem has been fixed. Now, the batch size is set before the “runtime_init” call.
The HDevelop example program explore_halcon.hdev used at one point an invalid window handle. Though the invalid handle is ignored by HDevelop, it might have caused problems in HDevEngine applications in combination with custom dev-operator implementations. This problem has been fixed.

HDevEngine

Bug Fixes

Attempting to start the debug server on a platform without HDevEngine debugging support returned the error text “unknown user extension” instead of the intended message “feature not implemented”. This problem has been fixed.
For each instance of an HDevProcedure, HDevEngine has started a separate thread by default (besides the engine’s own main execution thread), regardless whether that thread was used later on or not. When many HDevProcedure instances were created, this led to a substancial resource consumption. This problem has been fixed. Now, new threads are only started when they are actually requested by the executed code.
In the context of the handle rewrite for HALCON 18.05, there was a performance regression in the HDevEngine execution without JIT compilation. For script code that mostly manipulated control variables this could have produced an overhead of about 15%. This problem has been mitigated. The overhead is now closer to 5%.
The file HDevEngineCpp.h contained a wrong comment. In particular, instead of GetInfo, GetProcInfo has been used. This problem has been fixed.
dev_get_window is specified to return -1 if no window is available. However, for implementations in engine applications, this case was not handled correctly. In particular, with JIT compilation an invalid handle could have led to a crash and in HDevEngine/.NET an empty tuple could have been returned even in a non-JIT case, changing the behavior of the script code. This problem has been fixed. Now, always -1 will be returned. Note that user implementations should never return a numeric value except for legacy mode. Instead, indicate the invalid value with an empty tuple or an empty handle.

HALCON Library

Speedup

affine_trans_image, affine_trans_image_size, zoom_image_factor, zoom_image_size, and rotate_image (for angles not multiples of 90 degrees) have been accelerated on Arm 64-bit processors that support the NEON instruction set.
For images of type ‘byte’ and ‘uint2’, the operators are faster
- by up to 20% for Interpolation = ‘bilinear’ and
- by up to 30% for Interpolation = ‘constant’ and Interpolation = ‘weighted’.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
  The new implementation produces identical results as the old implementation.
  For images of type ‘real’, the operators are faster
- by up to 80% for Interpolation = ‘bilinear’,
- by up to 150% for Interpolation = ‘constant’ and Interpolation = ‘weighted’, and
- by up to 60% for Interpolation = ‘bicubic’.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
  The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
  Furthermore, affine_trans_region has been accelerated on Arm 64-bit processors that support the NEON instruction set.
- The acceleration is up to 35% for Interpolation = ‘constant’.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
  The new implementation produces identical results as the old implementation.
affine_trans_image, affine_trans_image_size, zoom_image_factor, zoom_image_size, and rotate_image (for angles not multiples of 90 degrees) have been accelerated on processors that support AVX2.
For images of type ‘byte’, the operators are faster
- by up to 100% for Interpolation = ‘nearest_neighbor’,
- by up to 70% for Interpolation = ‘bilinear’,
- by up to 130% for Interpolation = ‘constant’ and Interpolation = ‘weighted’, and
- by up to 120% for Interpolation = ‘bicubic’ on processors that support AVX2.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
  The new implementation produces identical results as the old implementation.
  For images of type ‘uint2’, the operators are faster
- by up to 120% for Interpolation = ‘nearest_neighbor’,
- by up to 170% for Interpolation = ‘bilinear’,
- by up to 230% for Interpolation = ‘constant’ and Interpolation = ‘weighted’, and
- by up to 90% for Interpolation = ‘bicubic’ on processors that support AVX2.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
  The new implementation produces identical results as the old implementation.
  For images of type ‘int2’, the operators are faster
- by up to 120% for Interpolation = ‘nearest_neighbor’,
- by up to 150% for Interpolation = ‘bilinear’,
- by up to 230% for Interpolation = ‘constant’ and Interpolation = ‘weighted’, and
- by up to 80% for Interpolation = ‘bicubic’ on processors that support AVX2.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
  The new implementation produces identical results as the old implementation.
  For images of type ‘real’, the operators are faster
- by up to 80% for Interpolation = ‘nearest_neighbor’,
- by up to 170% for Interpolation = ‘bilinear’,
- by up to 280% for Interpolation = ‘constant’ and Interpolation = ‘weighted’, and
- by up to 120% for Interpolation = ‘bicubic’ on processors that support AVX2.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
  The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
  Furthermore, affine_trans_region has been accelerated on processors that support AVX2.
  The acceleration is
- up to 50% for Interpolation = ‘nearest_neighbor’ and
- up to 110% for Interpolation = ‘constant’.The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
  The new implementation produces identical results as the old implementation.
The following operators run faster now:
- div_image on ‘byte’ images is faster by up to 17%, on ‘real’ images up to 9%, and on ‘int2’ images up to 23%
- invert_image is faster by up to 6%
- sub_image on byte images is faster by up to 13%, on uint2 images up to 15%
- derivate_gauss with the ‘laplace’ parameter value is faster by up to 23%
- edges_color with the ‘canny’ parameter value on ‘byte’ images is faster by up to 15%
- mirror_image with the ‘mirror’ parameter value on ‘byte’ images is faster by up to 21%
- gen_gauss_pyramid on ‘int2’ images is faster by up to 150% (‘min’,’max’), 230% (‘constant’), or 215% (‘weighted’), and on ‘byte’ images up to 87% (‘weighted’)
- binomial_filter on ‘byte’ images is faster by up to 7%, on ‘uint2’ images up to 10%, and on ‘real’ images up to 16%
- median_image on ‘int2’, ‘uint2’, or ‘int4’ images is faster by up to 36% (for ‘circle’, ‘mirrored’)
- median_separate on ‘int2’, ‘uint2’, or ‘int4’ images is faster by up to 10% (for ‘mirrored’)
- rank_image on ‘int2′,’uint2’, or ‘int4’ images is faster by up to 40% (for ‘mirrored’)
- smooth_image on ‘byte’ images is faster by up to 9% (for ‘deriche1′,’deriche2′,’shen’)
- convert_image_type for ‘byte’ to ‘real’ is faster by up to 98%, for ‘real’ to ‘byte’ up to 50%, and for ‘byte’ to ‘uint2’ or ‘real’ to ‘uint2’ up to 46%.
- dual_rank on ‘uint2’ images is faster by up to 17%
- gray_closing_rect on ‘byte’ images is faster by up to 80%, on ‘real’ images up to 19%
- gray_closing_shape on ‘byte’ images is faster by up to 50% (for ‘rectangle’)
- gray_dilation_rect on ‘byte’ images is faster by up to 67%, on ‘real’ images up to 17%, on ‘int4’ images up to 168%, and on ‘int2’ images up to 230%
- gray_dilation_shape on ‘byte’ images is faster by up to 47% (for ‘rectangle’)
- gray_erosion_rect on ‘byte’ images is faster by up to 68%, on ‘real’ images up to 22%
- gray_erosion_shape on ‘byte’ images is faster by up to 50% (for ‘rectangle’)
- gray_opening_rect on ‘byte’ images is faster by up to 68%, on ‘real’ images up to 20%, on ‘int2’ images up to 43%, and on ‘int4’ images up to 70%
- gray_opening_shape on ‘byte’ images is faster by up to 50% (for ‘rectangle’)
- gray_range_rect on ‘byte’ images is faster by up to 62%, on ‘real’ images up to 20%, on ‘int2’ images up to 110%, and on ‘int4’ images up to 80%
- affine_trans_region is faster by up to 100% (Interpolation: ‘nearest_neighbor’)
- projective_trans_region is faster by up to 46% for ‘bilinear’ interpolation
- partition_dynamic is faster by up to 64%
- threshold on ‘byte’ images is faster by up to 10%, on ‘real’ images up to 9%, on ‘int1’ images up to 46%
- threshold_sub_pix on ‘real’ images is faster by up to 18%
- fuzzy_measure_pairing on ‘byte’ and ‘uint2’ images is faster by up to 20%
- volume_object_model_3d_relative_to_plane is faster by up to 18% (for ‘signed’ method)
- sort_contours_xld is faster by up to 33%
On systems that allow memory prefetching, find_surface_model, refine_surface_model_pose, find_surface_model_image, and refine_surface_model_pose_image are now up to 15% faster, while distance_object_model_3d in voxel mode is up to 30% faster.
gen_image_interleaved is now parallelized on internal data level for all supported image types and color formats. The achievable speedup is dependent on the number of available threads and the image size. gen_image_interleaved has been accelerated further for all color formats of type ‘byte’ and for color format = ‘rgb’ and ‘bgr’ for images of type ‘uint2’ on processors that support SSSE3 or SSE41, respectively.
In particular, the following speedups can be achieved:

Image Size / Type	Color Format	Instruction Set	Speedup without Parallelization and SIMD	Speedup with 4-Thread Parallelization	Speedup with 8-Thread Parallelization	Speedup with 4-Thread Parallelization and SIMD
800×600/byte	‘rgb555’ ‘bgr555’	SSSE3	170%	58%	100%	250%
	‘rgb5551’ ‘bgr5551’	SSSE3	155%	58%	100%	250%
	‘rgb565’ ‘bgr565’	SSSE3	170%	54%	85%	255%
	‘rgb’ ‘bgr’	SSE41	130%	65%	115%	240%
	‘rgbx’ ‘bgrx’	SSSE3	140%	65%	115%	240%
800×600/uint2	‘rgb’ ‘bgr’	SSE41	40%	55%	85%	105%
1600×1200/byte	‘rgb555’ ‘bgr555’	SSSE3	160%	100%	160%	200%
	‘rgb5551’ ‘bgr5551’	SSSE3	150%	100%	160%	195%
	‘rgb565’ ‘bgr565’	SSSE3	145%	95%	160%	195%
	‘rgb’ ‘bgr’	SSE41	120%	100%	150%	155%
	‘rgbx’ ‘bgrx’	SSSE3	115%	100%	140%	140%
1600×1200/uint2	‘rgb’ ‘bgr’	SSE41	45%	63%	75%	75%

Image Size / Type	Color Format	Speedup with 4-Thread Parallelization	Speedup with 8-Thread Parallelization
800×600/uint2	‘rgb555’ ‘bgr555’ ‘rgb5551’ ‘bgr5551’ ‘rgb565’ ‘bgr565’	55%	65%
	‘rgbx’ ‘bgrx’	55%	50%
	‘rgb48’ ‘bgr48’	55%	55%
	‘rgbx64’ ‘bgrx64’	65%	55%
1600×1200/uint2	‘rgb555’ ‘bgr555’ ‘rgb5551’ ‘bgr5551’ ‘rgb565’ ‘bgr565’	50%	60%
	‘rgbx’ ‘bgrx’	35%	45%
	‘rgb48’ ‘bgr48’	35%	35%
	‘rgbx64’ ‘bgrx64’	35%	40%

gray_erosion_rect, gray_dilation_rect, gray_opening_rect, gray_closing_rect, gray_erosion_shape, gray_dilation_shape, gray_opening, and gray_closing_shape with parameter ‘MaskShape’ set to ‘rectangle’ are now faster for ‘byte’ images on Intel compatible processors that support SSE2 or AVX2, depending on the image size and mask dimensions.
In particular, the following speedups can be expected for a 1600×1200 image compared to the previously available SSE2 implementation:

MaskHeight x MaskWidth	Morphological operation	Speedup without Parallelization and with SSE2 (Windows/Linux)	Speedup without Parallelization and with AVX2 (Windows/Linux)	Speedup with xx-Thread Parallelization and with SSE2 (Windows/Linux)	Speedup with xx-Thread Parallelization and with AVX2 (Windows/Linux)
3×3	erosion/dilation	0%/-10	25%/60%	50%/30%	90%/75%
5×5	erosion/dilation	25%/15%	85%/110%	45%/35%	130%/135%
7×7	erosion/dilation	60%/45%	135%/175%	65%/65%	145%/180%
9×9	erosion/dilation	60%/60%	120%/175%	65%/80%	140%/180%
11×11	erosion/dilation	20%/20%	80%/100%	30%/30%	80%/115%
13×13	erosion/dilation	10%/15%	55%/85%	15%/25%	55%/105%
1×3	erosion/dilation	-8%/-10%	2%/10%	75%/50%	80%/75%
3×1	erosion/dilation	5%/30%	15%/55%	90%/55%	100%/110%
1×11	erosion/dilation	-10%/ -15%	5%/5%	0%/0%	10%/15%
11×1	erosion/dilation	5%/25%	15%/55%	20%/40%	30%/50%
3×5	erosion/dilation	-10%/-10%	10%/35%	35%/20%	65%/70%
5×3	erosion/dilation	0%/5%	20%/55%	40%/35%	65%/95%
3×3	opening/closing	0%/-5%	30%/65%	65%/35%	100%/130%
5×5	opening/closing	25%/15%	80%/125%	70%/50%	150%/190%
7×7	opening/closing	45%/40%	110%/175%	75%/60%	150%/220%
9×9	opening/closing	50%/50%	100%/160%	75%/70%	160%/195%
11×11	opening/closing	10%/5%	60%/75%	30%/15%	75%/85%
13×13	opening/closing	0%/2%	45%/65%	15%/11%	60%/75%
1×3	opening/closing	-10%/-15%	0%/3%	80%/65%	95%/100%
3×1	opening/closing	10%/30%	20%/55%	80%/40%	90%/120%

Please note that the new SSE2 implementation for filter masks 1xN (e.g., 1×3, 1×5, …) and for filter masks 3xN (e.g., 3×3, 3×5, …) can be slightly slower than the old SSE2 implementation. This is simply due to a behavior change in the algorithm. Previously, values outside the domain have been calculated in the unparallelized case that led to well defined pixel values outside the actual image domain. Now, the image only contains pixel values in the actual domain.

mean_image has been accelerated for ‘byte’ images.
polar_trans_image_ext has been accelerated on processors that support AVX2.
For images of type ‘byte’, polar_trans_image_ext is faster
- by up to 120% for Interpolation = ‘nearest_neighbor’ and
- by up to 70% for Interpolation = ‘bilinear’ on processors that support AVX2.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
The new implementation produces identical results as the old implementation.
For images of type ‘uint2’, polar_trans_image_ext is faster
- by up to 140% for Interpolation = ‘nearest_neighbor’ and
- by up to 160% for Interpolation = ‘bilinear’ on processors that support AVX2.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
The new implementation produces identical results as the old implementation.
For images of type ‘int2’, polar_trans_image_ext is faster
- by up to 130% for Interpolation = ‘nearest_neighbor’ and
- by up to 150% for Interpolation = ‘bilinear’ on processors that support AVX2.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
The new implementation produces identical results as the old implementation.
For images of type ‘real’, polar_trans_image_ext is faster
- by up to 230% for Interpolation = ‘nearest_neighbor’ and
- by up to 180% for Interpolation = ‘bilinear’ on processors that support AVX2.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
Furthermore, polar_trans_region has been accelerated on processors that support AVX2.
- The acceleration is up to 50% for Interpolation = ‘nearest_neighbor’ and Interpolation = ‘bilinear’.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default) and if ‘avx2_enable’ is set to ‘true’ with set_system (the default on machines that support AVX2).
The new implementation produces identical results as the old implementation.
polar_trans_image_inv has been accelerated on all processors
- by more than 30% for all image types and all interpolation modes
  by an internal implementation that uses slightly less accurate floating-point calculations.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
Furthermore, the new implementation has been accelerated on processors that support AVX2.
The acceleration for Interpolation = ‘nearest_neighbor’ is more than 550% for all supported image types (‘byte’, ‘int2’, ‘uin2’, and ‘real’).
For Interpolation = ‘bilinear’, the acceleration is
- up to 400% for ‘byte’ images,
- up to 600% for ‘int2’ and ‘uint2’ images, and
- up to 550% for ‘real’ images.
Furthermore, polar_trans_region_inv has been accelerated. On processors that do not support AVX2, the acceleration is
- up to 35%.
On processors that support AVX2, the acceleration is
- up to 450% for Interpolation = ‘nearest_neighbor’ and
- up to 350% for Interpolation = ‘bilinear’.
The new implementations are selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
projective_trans_image and projective_trans_image_size have been accelerated on processors that support the Arm NEON instruction set.
On 32-bit Arm systems, the acceleration for images of type byte and uint2 is
- up to 50% for Interpolation = ‘nearest_neighbor’ and
- up to 150% for Interpolation = ‘bilinear’.
  On 64-bit Arm systems, the acceleration for images of type byte and uint2 is
- up to 20% for Interpolation = ‘nearest_neighbor’ and
- up to 50% for Interpolation = ‘bilinear’.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically significantly more accurate than the previous implementation.
The previous implementation cannot be selected any longer.
On 32-bit Arm systems, the acceleration for images of type real is
- up to 250% for both interpolation modes.
  On 64-bit Arm systems, the acceleration is
- up to 230% for nearest-neighbor interpolation and
- up to 130% for bilinear interpolation.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
Furthermore, projective_trans_region has been accelerated on processors that support the Arm NEON instruction set.
On 32-bit Arm systems, the acceleration is
- up to 60% for Interpolation = ‘nearest_neighbor’ and
- up to 150% for Interpolation = ‘bilinear’.
  On 64-bit Arm systems, the acceleration is
- up to 20% for Interpolation = ‘nearest_neighbor’ and
- up to 50% for Interpolation = ‘bilinear’.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically significantly more accurate than the previous implementation.
The previous implementation cannot be selected any longer.
projective_trans_image and projective_trans_image_size have been accelerated on processors that support AVX2.
The acceleration for images of type ‘byte’ is
- up to 100% for Interpolation = ‘nearest_neighbor’ and
- up to 250% for Interpolation = ‘bilinear’.
The acceleration for images of type ‘uint2’ is
- up to 100% for Interpolation = ‘nearest_neighbor’ and
- up to 400% for Interpolation = ‘bilinear’.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default). The new implementation is numerically significantly more accurate than the previous implementation.
The previous implementation cannot be selected any longer.
The acceleration for images of type ‘real’ is
- up to 300% for both interpolation modes.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically infinitesimally less accurate than the previous implementation. If utmost accuracy is desired, the previous implementation can be selected by setting ‘int_zooming’ to ‘false’.
Furthermore, projective_trans_region has been accelerated on processors that support AVX2. The acceleration is
- up to 90% for Interpolation = ‘nearest_neighbor’ and
- up to 200% for Interpolation = ‘bilinear’.
The new implementation is selected if ‘int_zooming’ is set to ‘true’ with set_system (the default).
The new implementation is numerically significantly more accurate than the previous implementation.
The previous implementation cannot be selected any longer.
rotate_image is now faster for 90 and 270 degrees. For ‘byte’ images the speedup is up to 150% on AVX2 capable machines. For ‘int2’/’uint2’ images the speedup is up to 90% on SSE2 capable machines. For ‘real’ images the speedup is up to 50% on SSE2 capable machines.
sobel_amp for FilterType=’sum_abs’ is now faster on processors that support the AVX2 instruction set. Using a filter size of 3, the speedup for byte images with a size of 512×512 is up to 45% and up to 30% for images of size 1600×1200. For larger filter sizes, the speedup is slightly less.
Reading and writing of JPEG images is now faster by up to 30% on AVX2 capable processors.

New Functionality

3D

Surface models that have been created for edge-supported surface-based matching and refinement can now also be used without edge support. This allows to use the same surface model for both edge-supported and non-edge-supported matching. For this, the operators find_surface_model, find_surface_model_image, refine_surface_model_pose, and refine_surface_model_pose_image accept the new generic parameter ‘use_3d_edges’.
The operators find_surface_model, find_surface_model_image, refine_surface_model_pose, and refine_surface_model_pose_image now accept multiple values in their MinScore argument. Those values can be used to set minimum scores for the surface overlap, the 3D edge overlap, and for image-based operators, the 2D edge overlap. Additionally, the values of these scores can be obtained using the operator get_surface_matching_result. The visualization of the corresponding surface matching result handles in the handle inspection windows has been adapted accordingly.
The HDevelop example program hdevelop/3D-Matching/Surface-Based/find_surface_model_with_edges.hdev has been extended to show the new functionality.
reduce_object_model_3d_by_view now allows to use the existing XYZ mapping of a 3D object model instead of a virtual camera.
sample_object_model_3d now includes a new sampling mode that uses the XYZ-mapping of the 3D object model to speed up the sampling. This mode can be activated with the two new parameters ‘xyz_mapping’ and ‘xyz_mapping_compute_normals’. The new HDevelop example program hdevelop/Object-Model-3D/Segmentation/sample_object_model_3d.hdev shows the different sampling strategies that are supported by sample_object_model_3d.
select_points_object_model_3d now accepts a tuple of numbers instead of an attribute name as input on which the threshold is applied. This allows to select points based on some mask without first setting that mask as attribute in the 3D object model. The HDevelop example program hdevelop/3D-Object-Model/Segmentation/select_points_object_model_3d.hdev has been extended to show this new functionality.

Bar Code

HALCON now supports all GS1 application identifiers specified in the latest version of the “GS1 General Specifications” (January 2019).

Calibration

The new HDevelop example program hdevelop/Tools/Mosaicking/two_camera_calibrated_mosaicking.hdev shows how accurate mosaicking can be easily performed using the standard HALCON calibration plate with hexagonally arranged marks. It requires the 28 new images from the subdirectory images/3d_machine_vision/calibrated_mosaic.

Data Code

HALCON now supports all GS1 application identifiers specified in the latest version of the “GS1 General Specifications” (January 2019).

Deep Learning

The inference of deep learning networks using apply_dl_classifier and apply_dl_model can now be done on Arm processors.
A custom HPeek demo has been created, which showcases classification, detection, segmentation, and OCR using deep learning. You can download this demo on our customer area for free and evaluate the performance on your hardware.
Please consider that the inference on Arm processors uses parallelization and the number of threads can be determined via set_system(‘thread_num’, NumThreads).
In order to reduce inference times when using Arm processors, the operator create_dl_model_detection has been adapted to create an improved model. The file examples/hdevelop/Deep-Learning/Detection/detect_pills.hdl used for the HDevelop example program for detection has been changed accordingly.
apply_dl_model provides a new option for the parameter ‘Outputs’ for models of type ‘detection’. In particular, now the bounding box and class predictions of selected levels can be returned.
apply_dl_model is now independent of the batch size. It can be supplied with an arbitrary number of input images. Further, the processing of the operator can be stopped by external interrupts.
The flexibility of object detection heads has been improved. Now, different weights for class and bounding box heads are supported. These weights can be set with create_dl_model_detection using the parameters “bbox_head_weight” and “class_head_weight”.
The Deep Learning detection parameters ‘aspect_ratios’ and ‘num_subscales’, which can be set with create_dl_model_detection have been renamed to ‘anchor_aspect_ratios’ and ‘anchor_num_subscales’, respectively.
set_dl_model_param has been extended to set the parameter ‘batch_size_multiplier’ in a model. This new model parameter is used to enable training with larger numbers of images in a single step which otherwise would not be possible due to GPU memory limitations. The parameter ‘batch_size_multiplier’ does not have any impact during evaluation and inference. Note that the parameter ‘batch_size_device’ of the deep learning classifier has been replaced by the parameter ‘batch_size_multiplier’, which has a different semantics. Note that this change affects the compatibility.
The object detection based on deep learning has been extended by the support of a new instance type. Now, the location of an instance and its orientation within the image can be given by an oriented rectangular bounding box. Such oriented bounding boxes are defined using specific parameters, therefore the dataset dictionaries (e.g., DLDataset) use corresponding parameter entries. The new model parameter ‘instance_type’ has been introduced to distinguish the instance types. For this new instance type the parameter ‘ignore_direction’ allows you to specify if the model shall return the direction of the instance or only its best fitting bounding box, while the parameter ‘class_ids_no_orientation’ allows you to specify for which specific class the orientation shall not be considered (e.g., due to spherical symmetry). The workflow for deep-learning-based object detection stays the same, independent of the instance types.
The HDevelop example program examples/hdevelop/Deep-Learning/Detection/dl_detection_with_orientation_workflow.hdev has been added to show how to use deep-learning-based object detection with oriented bounding boxes in HALCON. It uses the new images in examples/images/screws and the annotations in examples/hdevelop/Deep-Learning/Detection/screws.hdict. The HALCON reference manual has been extended and a set of new local procedures has been added to facilitate the usage of this new instance type.
HALCON’s deep learning core functionality has been moved to the separate library halcondl(xl).dll/libhalcondl(xl).so/libhalcondl(xl).dylib. Applications using HALCON’s deep learning functionality must ship this library along with the HALCON library.
During the training of a deep learning model, now the learning rate is plotted.
The error message regarding outdated graphics drivers (regarding the CUDA version they support) has been clarified.
HALCON has been extended by the new HDevelop example programs Detection/dl_detection_workflow.hdev and Segmentation/dl_segmentation_workflow.hdev in the subdirectory hdevelop/Deep-Learning, which in few lines show the fundamental workflow of preprocessing a dataset, training a model (respectively detection and segmentation), evaluating the model, and inference on new images.
HALCON 19.05 has been successfully tested with CUDA 10.1 capable graphics drivers. Nonetheless, the according system requirements are similar to the requirements of HALCON 18.11.

Graphics

HALCON has been extended with means to configure the fill style for displaying XLD contours. The operators set_contour_style, get_contour_style, and the respective HDevelop operator dev_set_contour_style have been added to enable this.
The pie charts displayed by the evaluation procedures for deep learning have been adapted to use this new functionality. Note that this change affects the compatibility.
Displaying large regions zoomed in a window now requires less memory.

Matching

Shape-based matching now supports new parameters to set clutter constraints on the matching model. This is helpful, e.g., if it is a special characteristic of the model that, in specific parts near to the model, structures are missing. The new operators set_shape_model_clutter and get_shape_model_clutter can be used to respectively set and query those parameters. The input parameter MinScore of the operators find_shape_model, find_shape_models, find_scaled_shape_model, find_scaled_shape_models, find_aniso_shape_model, and find_aniso_shape_models has been extended to pass a maximum clutter value in addition to the minimum score of the matches to be found. The operator set_shape_model_param has been extended to enable and disable the clutter usage.
The Solution Guide on Matching has been extended by a section describing the concept of clutter regions.
The new HDevelop example program hdevelop/Matching/Shape-based/find_shape_model_clutter.hdev shows how to use the new functionality.
The new HDevelop procedure procedures/general/get_hom_mat2d_from_matching_result helps the user to calculate the transformation matrix for the model contours from the results of shape-based matching. The procedure procedures/general/dev_display_shape_matching_results has been extended to visualize the clutter region for each found match. Note that this change affects the compatibility.
The new HDevelop example program hdevelop/Matching/Shape-Based/find_shape_low_contrast_high_noise.hdev shows which parameter settings might improve the performance of shape based matching on images of low contrast and high noise. It uses the new images crosses_01 – crosses_10 from the subdirectory images/crosses.

Miscellaneous

HALCON has been extended with an operator area_intersection_rectangle2, which calculates the intersection area of oriented rectangles. The new HDevelop example program hdevelop/Tools/Geometry/area_intersection_rectangle2.hdev shows the new functionality.

Parallelization

HALCON Spy has been improved and is now also capable to run multi-threaded.

Bug Fixes

3D

calibrate_sheet_of_light did not raise an error for inconsistent gray values in the set disparity image. This problem has been fixed. Now, calibrate_sheet_of_light raises the error 3791 (“The gray values of the disparity image, which specify rows in the camera image, do not fit the height of the camera”).
gen_box_object_model_3d did not create more than one box correctly. This problem has been fixed.
In the procedure debug_find_surface_model, when inspecting the model edges under a direction where the model has no edges, an exception was raised and the tool would have closed. This problem has been fixed. The tool now stays open even if the model has no edges under a particular view.
Some files in the binary PLY format could not be read by read_object_model_3d. This problem has been fixed.
set_camera_setup_param did not handle poses correctly which were of a type other than 0, i.e., the last entry of the pose was not equal to 0. This problem has been fixed.
triangulate_object_model_3d internally calculated the normals using the “greedy” method if the 3D object model did not contain them, but without forcing them inwards. This problem has been fixed. Now, triangulate_object_model_3d internally calculates the normals in the expected direction and the documentation has been modified accordingly.
union_object_model_3d did not free temporary memory correctly if all input object models contained no points. This problem has been fixed.
vector_to_pose raised memory errors in rare cases. This problem has been fixed.
The point density check of the procedure debug_find_surface_model was too lenient. It rated a density of one neighbor per point as ‘good’, which is actually a bit low. This problem has been fixed. Now, a proper warning is shown instead.

Bar Code

In rare cases, find_bar_code could not restore edges. This problem has been fixed.
find_bar_code could not decode GS1 DataBar Expanded Stacked codes with less than four symbol characters in the first row. This problem has been fixed. Now, the minimum number of symbol characters in the first row is two as specified by the ISO/IEC 24724:2011 standard.
In very rare cases, find_bar_code returned the error 3513 (“Internal error: number of chords too big for num_max”). This problem has been fixed.
In very rare cases, find_bar_code crashed in case of GS1 DataBar Expanded Stacked Codes. This problem has been fixed.
In very rare cases, get_bar_code_result and find_bar_code returned an error if the quiet zone check was enabled. This problem has been fixed.
In rare cases, get_bar_code_result returned -1 for all print quality inspection grades or crashed for bar codes near image borders. This problem has been fixed.
set_bar_code_param and set_bar_code_param_specific did not accept empty tuples as generic input parameters. This problem has been fixed.

Calibration

All operators that return camera parameters either returned a tuple that had one extra entry or in rare cases made HALCON crash if camera parameters using the old camera models (i.e., without the leading string containing the camera type) of type ‘area_scan_telecentric_tilt_division’ or ‘area_scan_telecentric_tilt_polynomial’ were passed. This problem has been fixed.
set_calib_data_cam_param and set_camera_setup_cam_param ignored the parameter CameraType, which could have led to unexpected camera setups. This problem has been fixed. Now, CameraType is expected to be equal to [] or to the first entry of CameraParam.

Color Processing

trans_from_rgb could have produced wrong output for the mode ‘ihs’ and some specific input. This problem has been fixed.
RGB/YUV conversion was using wrong equations, not the one from Norm ITU-R BT.470-6: Conventional Television Systems, 1998. This problem has been fixed.

Compute Device

HALCON still used pinned memory after deactivating a compute device. This may have resulted in performance issues, especially if the cache for pinned memory was not sized appropriately. This problem has been fixed.

Data Code

In some cases, find_data_code_2d returned ECC 200 codes which were not mirrored even though the parameter ‘mirrored’ was set to ‘yes’. The problem only occurred for data code models with ‘module_grid’ set to ‘any’. This problem has been fixed.
In rare cases, find_data_code_2d crashed randomly for very small or empty domains. This problem has been fixed.
In rare cases, find_data_code_2d crashed for ECC 200 codes if ‘module_size_min’ was set to a value with which the smallest possible code would have exceeded the image dimensions. This problem has been fixed.
In very rare cases, find_data_code_2d crashed for ECC 200 code candidates that are close to the image border. This problem has been fixed.
In rare cases, find_data_code_2d did not free some intermediate data if the data code model parameter ‘persistence’ was set to 0 or -1. As a consequence, in some cases, get_data_code_2d_objects and get_data_code_2d_results unexpectedly returned print quality results instead of empty objects/tuples. This problem has been fixed.
find_data_code_2d sometimes returned different results in dependence on the chosen value of ‘discard_undecoded_candidates’. This problem has been fixed.
In some rare cases, find_data_code_2d returned a misaligned data code region for ECC 200 codes. This problem has been fixed.
In very rare cases, get_data_code_2d_results crashed for a print quality inspection if the considered data code was located very close to the image boundary. This problem has been fixed.
For set_data_code_2d_param, the parameter ‘format’ allows a list of values. If this list contained an invalid value, the function exited and all previously set values were discarded. This problem has been fixed. Now, the old list of parameters is kept.
write_data_code_2d_model and serialize_data_code_2d_model did not store the value of the data code model parameter ‘discard_undecoded_candidates’. This problem has been fixed.

Deep Learning

When setting a bigger font size in a WindowHandle in the visualization procedure dev_display_dl_data for displaying the confusion matrix in a Deep Learning application, the title “Ground truth” overlapped the content of the confusion matrix. This visualization problem has been fixed.
When training a deep learning model for object detection and segmentation, the legend (TextWindow) for the images (input, ground truth, results) at the training progress was placed at the bottom right corner. As a result, you could not see the predicted bounding boxes quite well. This problem has been fixed. Now, the visualization of the legend is placed at the top right corner.
The cuBLAS and cuDNN libraries shipping with the Linux x64 installer are now from the archives for Ubuntu 16.04.
train_dl_model plotted the mAP incorrectly if the minimum and maximum mAP values are close together. This problem has been fixed.
In the HDevelop example programs hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_3_evaluate.hdev and hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_3_evaluate.hdev the batch size was set after the call of set_dl_model_param (DLModelHandle, ‘runtime_init’, ‘immediately’). This could have led to an out of memory error. This problem has been fixed. Now, the batch size is set before the “runtime_init” call.
train_dl_model_batch did not check if BBoxIDs are in the range of ClassIDs. This problem has been fixed
train_dl_model_batch could have failed for object detection if bounding box coordinates have been passed over as a mixed tuple. This problem has been fixed.
If the batch size, input dimension, or number of classes were changed such that an out of memory exception was thrown, memory leaked temporarily on the GPU in some cases. This memory was freed if the runtime of the model was switched back to CPU or the model was cleared. The problem only existed if the model has already been initialized on the GPU (usually after the first call to train_dl_model_batch / train_dl_classifier_batch). The operators set_dl_model_param and set_dl_classifier_param were affected by this problem. This problem has been fixed.
In some cases, train_dl_model_batch displayed a remaining time greater than zero although the training was completed. This problem has been fixed.
write_dl_model and write_dl_classifier did not handle errors during the write process correctly. Especially, if the model was initialized on the GPU, this could have led to an unusable model and also to a crash. The problem could have occured if during the write operation another process used GPU memory or the underlying CUDA memory decided to use more memory after the write operation than before. This problem has been fixed. Now, the GPU memory is not changed during the write operations. As a positive side-effect, the write operation is faster since no memory is copied back and forth. The speed-up depends on the size of the used deep learning model. Note further that the operators write_dl_model and write_dl_classifier now provide better error reporting in case of hardware faults.
The procedures preprocess_dl_classifier_images and preprocess_dl_model_images have been improved when using ContrastNormalization. Now, when using ContrastNormalization not only ‘real’ and ‘byte’ images can be used but also images of integer-formats.
The procedure preprocess_dl_samples might have returned bounding boxes with zero area. This problem has been fixed. Note that this change affects the compatibility.
The HALCON deep learning features did not support very large images on 64-bit systems. this problem has been fixed.
The procedure dev_display_dl_data had a problem with the indexing of windows. This problem has been fixed.

File

Reading a JSON file with read_dict was not locale-independent and failed on systems with locales where the decimal point is not a point. Applications using HDevelop or HDevEngine were not affected as HDeveEngine sets the LC_NUMERIC locale to “C”. This problem has been fixed.
read_dict did not read some JSON files on Windows. This problem has been fixed.
read_image crashed when reading GIF images in parallel. This problem has been fixed. Now, read_image internally protects reading of GIF images with a mutex.
Writing of very large image files in the HOBJ format did not return. This problem has been fixed.
write_image wrote JpegXR files, even if an error occured. This problem has been fixed and write_image now removes partially written JpegXR files on error.

Filter

convol_image did not handle separable kernels with an adjustment of the kernel center correctly. This problem has been fixed.
polar_trans_image_ext crashed for images with an output width and/or height equal to 1, when set_system (‘floating_exceptions’, ‘zero_divide’) was set. This problem has been fixed.

Graphics

open_window did not work on Linux systems with IPv6 (e. g., Ubuntu 18.04). This caused also 3D plots and OpenGL operations not to work. This problem has been fixed.
Calling open_window in HDevelop on a macOS platform caused an error. This problem has been fixed.
Resizing of xld drawing objects did not work. This problem has been fixed.
The 3d_plot mode with textures leaked OpenGL textures (i.e., host and GPU memory). This problem has been fixed.
Sometimes, thin rectangular regions were not displayed when zooming or shifting images. This problem has been fixed.

Matching

find_ncc_model might have frozen for models with a very small variance of gray values. This problem has been fixed.

Memory

The operator call set_system(‘global_mem_cache’,’cleanup’) did not free the global cache properly. The cached memory blocks of the local thread still remained. This problem has been fixed.

Miscellaneous

Many operators which only expect a single input object did not raise an error when called with multiple input objects. In particular, the operators add_channels, area_center_gray, cooc_feature_image, elliptic_axis_gray, entropy_gray, expand_gray, expand_gray_ref, fit_surface_first_order, fit_surface_second_order, fuzzy_entropy, fuzzy_perimeter, gen_cooc_matrix, gray_features, gray_histo, gray_histo_abs, gray_histo_range, intensity, min_max_gray, moments_gray_plane, paint_region, plane_deviation, region_to_mean, segment_characters, select_gray, and text_line_slant were affected. This problem has been fixed. Now, an error message is raised.
Error messages for which the length was not fixed could have led to a crash. This problem has been fixed.
get_system with ‘parallelize_operators’ returned an empty tuple instead of ‘false’ when operator parallelization was turned off. This problem has been fixed.
Calling get_system with the parameter ‘is_license_valid’ crashed HALCON when using a secure application specific license. This problem has been fixed.
The parameter ‘tsp_thread_num’ could not be set to -1 with set_system. This problem has been fixed.
Excessively long environment variables resulted in HALCON internal buffer overruns. This problem has been fixed.

OCR

In very rare cases, find_text threw the error 3111 (“At least one input object has an empty region”). This problem has been fixed.
In very rare cases, find_text returned the error 3510 (“Exceeding the maximum number of run lengths while automatical expansion”). This problem has been fixed.
In some cases, find_text crashed when it was applied in manual mode on an upright image. This problem has been fixed.
In some cases, find_text returned characters in a wrong order if text models of mode ‘auto’ with ‘text_line_structure’ and ‘text_line_separators’ have been used and ‘return_whole_line’ has been set to ‘true’. This problem has been fixed.
The handle inspect for text model handles and text result handles did not display parameters consistent with the documentation of the ‘manual’ and ‘auto’ mode, respectively. This problem has been fixed.

Region

gen_rectangle1 could have not returned an error for very big coordinates. This problem has been fixed.
line_position sometimes returned incorrect orientations in case of non-integer coordinates as input. This problem has been fixed.
local_threshold returned the error 3513 (“number of choords too big for num_max”) in rare cases. This problem has been fixed.
partition_rectangle stored empty regions also if the system settings were set to ‘store_empty_region’=’false’. This problem has been fixed.
sort_region with character mode did not work correctly when the adjacent rows (columns) overlapped with RowOrCol set to row (column). This problem has been fixed. Now, the character mode also works when there is a slight overlap. The reference manual entry has been adapted to specify the new behavior.

Segmentation

local_threshold returned the error 3513 (“number of choords too big for num_max”) in rare cases. This problem has been fixed.

System

HALCON did not detect the correct operating system version for Windows 8.1 and higher. This problem has been fixed.

Tuple

tuple_gen_sequence returned damaged sequences for inputs like NaN or Inf. This problem has been fixed.
tuple_regexp_replace returned a memory error instead of error 1302 (“Wrong value of control parameter: 2”). This problem has been fixed.

XLD

distance_cc_min_points using the mode ‘fast_point_to_segment’ sometimes mixed coordinate values for resulting contours. This problem has been fixed.
The number of contour points required for get_contour_angle_xld was not clearly defined. This problem has been fixed. Now, the required minimum is checked correctly and specified in the documentation.

HALCON/C++

Functionality

All methods in the C++ language interface that do not change a member of an own instance (i.e., all methods with read only access) are now declared as const in order to see the access rights of the method and to prevent that further casting is needed.

Bug Fixes

Not all headers provided by the HALCON/CPP language interface were included within the HalconCpp namespace. The generated C++ classes were globally defined inside the HalconCppForwards.h file without the HalconCpp namespace. This problem has been fixed. Now, all headers provided by HALCON are inside HalconCppForwards.h and surrounded by the HalconCpp namespace. This is specially useful for software development, to include only HalconCppForwards.h and to define all classes without further modification.

HALCON/.NET

Bug Fixes

If the .NET interface was used, an error occurred in the deserialization. In particular, the deserialized result was not correct. The serialization performed directly on a HALCON object was not affected by this problem. Only if the tuple constructor was used with an object to be serialized as parameter this caused a problem. This problem has been fixed.
The creation of HSmartWindowControl instances failed on Linux when running with newer versions of mono. This problem has been fixed.

Language Interface Example Programs

Bug Fixes

The MFC HDevEngine example exec_procedures_mt_mfc did not compile with some Visual Studio Versions on Windows. This problem has been fixed.

HALCON Variable Inspect

Functionality

The HALCON Variable Inspect extension for Visual Studio now also supports Visual Studio 2019.

Bug Fixes

When examining individual pixels with the HALCON Variable Inspect extension for Visual Studio, the correspondence between the mouse position and the related pixel coordinates was incorrect, as a wrong image coordinate system was used. Thus, the gray values of neighbored pixels might have been returned instead of those of the inspected pixel. This problem has been fixed.
The HALCON Variable Inspect extension for Visual Studio has been extended to support the display of string data in UTF-8 encoding.
In some cases, it was not possible to read iconic variables with the HALCON Variable Inspect extension for Visual Studio. This problem has been fixed.

Extension Packages

Functionality

The fileset of HALCON now contains an example which shows the use of handles in extension packages. In particular, the following files have been added to the new directory example/extension_package/userhandle: common.mak, def/userhandle.def, hdevelop/example.hdev, make.dotnet, makefile, rules.mak, source/cuserhandle.c

HComp

Bug Fixes

With HComp option -R it was no longer possible to create the reference documentation. The error: “module ‘none’ not allowed” appeared during the execution. This problem has been fixed.

Image Acquisition Interfaces

The latest information about new interface revisions and newly supported image acquisition devices can be found on MVTec’s web server. Please refer to the release notes within the documentation of the individual image acquisition interfaces for information about improvements, bugfixes, or whether a new revision of the corresponding device driver is required.

Miscellaneous

When calling open_framegrabber with any interface while an empty tuple was provided as device name, colorspace, cameratype, external trigger, or field parameter, HALCON terminated. This problem has been fixed.
The MVTec GigE Vision Streaming Filter version 2.1.8.2 that is part of the Windows installer now supports the [Stream]EventTransferEnd event and several stream statistics which were only available with the socket driver before.

Digital I/O Interfaces

The latest information about new interface revisions and newly supported digital I/O interfaces can be found on MVTec’s web server. Please refer to the release notes within the documentation of the individual digital I/O interfaces for information about improvements, bugfixes, or whether a new revision of the corresponding device driver is required.

Documentation

Programmer’s Manuals

The Programmers Guide showed an erroneous .NET example code. This problem has been fixed.
The Programmers Manual did not mention that the HALCON Variable Inspect extension for Visual Studio with HALCON/C++ can currently not be used with activated CLR. This problem has been fixed.
The Programmer’s Manual contained incorrect information on the usage of X11. This problem has been fixed.

User Guides

The documentation for HALCON for Arm-based Platforms has been improved to better describe installation related issues, e.g., necessary variables, uninstallation, and the type of installation for the development PC.
The description of the “Visualisation Settings” in the HDevelop User’s Guide was outdated. This problem has been fixed.

Reference Manual

The reference manual entry of boundary has been improved. Now, it mentions possible differences of output regions due to input parameter values.
The reference manual entry of find_data_code_2d has been improved. Now, the parameters trained with this operator are documented for each option.
The reference manual entry of find_surface_model has been extended by adding descriptions for the generic parameters ‘viewpoint’ and ‘max_gap’.
The reference manual entry of find_surface_model mentioned an outdated accuracy. This problem has been fixed.
The reference manual entry for find_surface_model missed information about the behavior without point normals. This problem has been fixed.
The German reference manual entry for the chapter 2D Transformations included a wrong axis assignment. This problem has been fixed.
The reference manual entry for gen_grid_region has been improved to describe some restrictions more clearly.
The reference documentation regarding the overall grade returned by the print quality inspection of 1D bar codes was incorrect. Since HALCON 18.11 the ISO/IEC 15416:2016 standard is supported. In this revised standard the overall grade is not the minimum of the other grades as the documentation incorrectly explained. This problem has been fixed. The reference manual entry of get_bar_code_result has been updated accordingly.
The reference manual entry of get_bar_code_result did not mention all possible status ids. This problem has been fixed.
The reference manual entry of get_data_code_2d_results now mentions also the output parameters ‘format information’ and ‘version information’, which are returned when querying the print quality for QR Code and Micro QR Code with ‘quality_isoiec_tr_29158’ and ‘quality_aimdpm_1_2006’.
The reference manual entry of get_deformable_model_params has been improved. Now, it is mentioned how further parameter values can be retrieved.
The reference manual entry of get_dl_model_param did not mention the value interval of weight_classes. This problem has been fixed.
The reference manual entry of get_string_extents did not mention that the operator treats multiple line strings as if they were concatenated. This problem has been fixed.
The reference manual entry of get_system contained some incorrect information for ‘cuda_version’ in combination with a GPU that does not meet the minimum system requirements. This problem has been fixed.
The code example in the reference manual entry of interleave_channels set the wrong pixel format. This problem has been fixed.
The reference manual entry of open_compute_device falsely stated that the parameter DeviceHandle is queried with query_available_compute_devices instead of DeviceIdentifier. This problem has been fixed.
The reference manual entry of select_grayvalues_from_channels has been improved to document the channels of the index image more clearly.
The reference manual entry of select_points_object_model_3d has been extended by the information that if an empty object model is passed the error 9515 (“Required points missing in 3D object model”) is raised.
The reference manual entries of select_shape, select_shape_xld, select_lines, partition_lines, and segment_contour_attrib_xld were not clear about the possible range of values for the parameters ‘Min’ and ‘Max’. This problem has been fixed.
The reference manual entry of set_bar_code_param for the parameter ‘check_char’ was confusing. This problem has been fixed.
The reference manual entry of set_color did not mention the restriction of a maximum of 256 entries. This problem has been fixed.
The reference manual entry of set_system has been extended with the information that the parameter ‘int_zooming’ affects different processing steps.
The reference manual entry for trans_to_rgb had a wrong conversion formula, further the entry of this operator as well as for trans_from_rgb had a misleading conversion hint. This problem has been fixed. The formula is now correct and the conversion hint reformulated.
The reference manual entry of write_image has been extended by the information that you need write permission in your current working directory in order to save an image in JPEG-XR format, regardless of the target directory.
Within the reference manual, the chapter Image has been extended with an introduction that provides an overview of the different image types.

Miscellaneous

The HDevelop User’s Guide and the Programmer’s Guide mentioned only some of the limitations for HDevEngine remote debugging. This problem has been fixed. Now they refer to the other limitations as well.
In the reference manual entries of set_bar_code_param, get_bar_code_result, get_data_code_2d_param, and get_data_code_2d_results, as well as in the Solution Guide Basics and the Solution Guide on 2D Data Codes the exact identifiers of multiple ISO/IEC standards have been added.
General information concerning a possible slow down due to window extrapolations has been moved from the Programmer’s Guide to the reference manual entries of set_window_extents and set_part.
The technical note on Gray Value Interpolation has been extended by information about the effects of the new implementation using floating-point calculation for interpolation. The reference manual entries of projective_trans_image, projective_trans_image_size, affine_trans_image, affine_trans_image_size, polar_trans_image_ext, polar_trans_image_inv, rotate_image, scale_image, zoom_image_factor, and zoom_image_size have been adapted as well.
The OCR rejection class is returned as ‘0x1a’ (hexadecimal basis) and ‘032’ (octal basis), but only the first notation has been mentioned in the corresponding reference manual entries and in the Solution Guide on Classification. This problem has been fixed.

Installation

HALCON has been extended with a hrun program, which is a command line utility to run HDevelop scripts.
If more than one HALCON version was installed, the HALCON uninstaller on Windows always set the HALCON version with the highest version number to active. This problem has been fixed. Now, the uninstaller asks, which version should be set to active, if there is no version active after uninstalling the current HALCON version.
For the HALCON student edition on linux, install_linux.sh contained a syntax error. This problem has been fixed.