Release Notes for HALCON 19.05 Progress

• DevOperator implementation classes for HDevEngine have to be extended with an implementation for the new dev_set_contour_style operator. More information.
• Due to a fixed problem for the procedure preprocess_dl_samples, there might be minimal differences during the training process of a deep learning detection network. However, these differences should not affect the training results. More information.
• The signature in the following member functions of the classes HImage and HShapeModel have changed in the language  interfaces HALCON/CPP and HALCON/.NET: FindAnisoShapeModel,  FindScaledShapeModel, and FindShapeModel. The parameter MinScore has changed the type from double to HTuple, so that under certain circumstances ambiguities may occur during a type conversion in the compilation process. In these cases, an explicit cast of your passed variable to double resolves the ambiguity. More information.
• The parameter 'batch_size_device' of the deep learning classifier has been replaced by the parameter 'batch_size_multiplier', which has a different semantics. Hence, programs using 'batch_size_device' need to be adapted to use 'batch_size_multiplier' instead. More information.

GUI

Help

Miscellaneous

Code Export

GUI

IDE

Procedures

Miscellaneous

New HDevelop Example Programs

New Functionality

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.

• 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
  800x600/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%
  800x600/uint2	'rgb' 'bgr'	SSE41	40%	55%	85%	105%
  1600x1200/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%
  1600x1200/uint2	'rgb' 'bgr'	SSE41	45%	63%	75%	75%
  Image Size/Type	Color Format	Speedup with 4-Thread Parallelization	Speedup with 8-Thread Parallelization
  800x600/uint2	'rgb555' 'bgr555' 'rgb5551' 'bgr5551' 'rgb565' 'bgr565'	55%	65%
  	'rgbx' 'bgrx'	55%	50%
  	'rgb48' 'bgr48'	55%	55%
  	'rgbx64' 'bgrx64'	65%	55%
  1600x1200/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 1600x1200 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)
  3x3	erosion/dilation	0%/-10	25%/60%	50%/30%	90%/75%
  5x5	erosion/dilation	25%/15%	85%/110%	45%/35%	130%/135%
  7x7	erosion/dilation	60%/45%	135%/175%	65%/65%	145%/180%
  9x9	erosion/dilation	60%/60%	120%/175%	65%/80%	140%/180%
  11x11	erosion/dilation	20%/20%	80%/100%	30%/30%	80%/115%
  13x13	erosion/dilation	10%/15%	55%/85%	15%/25%	55%/105%
  1x3	erosion/dilation	-8%/-10%	2%/10%	75%/50%	80%/75%
  3x1	erosion/dilation	5%/30%	15%/55%	90%/55%	100%/110%
  1x11	erosion/dilation	-10%/ -15%	5%/5%	0%/0%	10%/15%
  11x1	erosion/dilation	5%/25%	15%/55%	20%/40%	30%/50%
  3x5	erosion/dilation	-10%/-10%	10%/35%	35%/20%	65%/70%
  5x3	erosion/dilation	0%/5%	20%/55%	40%/35%	65%/95%
  3x3	opening/closing	0%/-5%	30%/65%	65%/35%	100%/130%
  5x5	opening/closing	25%/15%	80%/125%	70%/50%	150%/190%
  7x7	opening/closing	45%/40%	110%/175%	75%/60%	150%/220%
  9x9	opening/closing	50%/50%	100%/160%	75%/70%	160%/195%
  11x11	opening/closing	10%/5%	60%/75%	30%/15%	75%/85%
  13x13	opening/closing	0%/2%	45%/65%	15%/11%	60%/75%
  1x3	opening/closing	-10%/-15%	0%/3%	80%/65%	95%/100%
  3x1	opening/closing	10%/30%	20%/55%	80%/40%	90%/120%

  Please note that the new SSE2 implementation for filter masks 1xN (e.g., 1x3, 1x5, ...) and for filter masks 3xN (e.g., 3x3, 3x5, ...) 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 512x512 is up to 45% and up to 30% for images of size 1600x1200. 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.

3D

Bar Code

Calibration

Data Code

Deep Learning

Graphics

Matching

Miscellaneous

Parallelization

3D

Bar Code

Calibration

Color Processing

Compute Device

Data Code

Deep Learning

File

Filter

Graphics

Matching

Memory

Miscellaneous

OCR

Region

Segmentation

System

Tuple

XLD

• 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.

• 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.

• 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.

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

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

• 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.

• 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

• 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.

• 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.