LOG OUT
HALCON Progress Key Visual shows a person running at high speed

Release Notes for HALCON 18.11 Progress

This document provides the release notes for MVTec HALCON 18.11.0.1 Progress, as released in December 2018.

Addendum to the Release Notes of HALCON 18.11.0.0 Progress

The originally released version of HALCON 18.11.0.0 Progress had a few issues:

  • 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 substantial resource consumption. This problem has been fixed. Now, new threads are only started when they are actually requested by the executed code.
  • There was a performance regression in HDevEngine execution without JIT compilation. For script code that mostly manipulated control variables this could produce an overhead of about 15%. This problem has been fixed.

Therefore, the original version HALCON 18.11.0.0 Progress was substituted by an updated version HALCON 18.11.0.1 Progress.

To find out which version is currently installed, please open the dialog "Help->About" in HDevelop. The fixed version of the HALCON library is indicated by: "HALCON version: 18.11.0.1 (07.12.2018)". The file version of the HALCON library can also be checked with the following operator call: get_system('file_version',FileVersion), or, under Windows, by inspecting the file properties of the files halcon.dll and halconxl.dll.

Contents

Major New Features of HALCON 18.11.0.0 Progress

Deep Learning

HALCON 18.11 Progress introduces two new deep learning functionalities: object detection and semantic segmentation. Combined with the preexisting deep-learning-based image classification, users now have a comprehensive set of deep learning functions at their disposal.

With semantic segmentation, trained defect classes can be localized with pixel accuracy. This allows users to, e.g., solve inspection tasks, which previously could not be realized, or only with significant programming effort.

Object detection localizes trained object classes and identifies them with a surrounding rectangle (bounding box). Object detection also separates instances of touching or partially overlapping objects. This is especially useful when objects need to be counted.

ECC 200 Code Reader Improvements

The overall recognition rate of the ECC 200 data code reader could be increased by 5 % (data based on our internal benchmark consisting of more than 3,700 images from various applications). In addition, the ECC 200 reader is now able to read codes with a disturbed quiet zone. Also, codes against complex backgrounds can now be read faster and more robustly.

Dictionaries

HALCON now includes a new data structure "dictionary", which is an associative array that opens up various new ways to work with complex data. This enables developers to bundle arbitrary data into a single variable, making it easier to structure complex procedures. Dictionaries can also be read from and written to a file.

Handle Variable Inspect

HDevelop can now display detailed information on most important handle variables. This allows developers to easily inspect the current properties of complex data structures at a glance, which is extremely useful for debugging. Double-clicking a handle variable now returns all para­meters associated with the handle and their current settings.

Support for 64-bit Arm-based platforms

HALCON now also supports 64-bit Arm®-based platforms out of the box. The Linux installer, which can be downloaded from the MVTec website, has been extended by the option to additionally install the components necessary for 64-bit Arm-based platforms.

Enhanced field bus communication

HALCON 18.11 introduces the Hilscher-cifX interface. This allows HALCON to communicate with almost all industrial field bus protocols via Hilscher PC cards. Among others, CC-Link, EtherCAT, EtherNet/IP, PROFIBUS, and PROFINET are supported.

Compatibility

Licenses

HALCON 18.11.0.0 Progress requires a valid HALCON Progress license and does not run with licenses of HALCON 13 and earlier versions.

Furthermore, please note the following compatibility issues related to licenses:

HALCON Library

Compared to HALCON 18.05 Progress, many extensions have been introduced. Thus, the HALCON 18.11.0.0 Progress libraries are not binary compatible with HALCON 18.05 Progress or earlier versions. However, HALCON 18.11.0.0 Progess is mostly source-code compatible to HALCON 18.05 Progress except for the changes listed below:

HALCON Applications

Please re-compile all C, C++, or .NET programs developed with HALCON 18.05 Progress. The incompatibility with HALCON 18.05 Progress or earlier versions mainly concerns the binaries, with only few changes in the language interfaces. If you encounter problems during recompiling your programs, please check the detailed description of changes below.

Image Acquisition Interfaces

In general, HALCON 18.11.0.0 Progress, HALCON 18.05 Progress and HALCON 13.0.x image acquisition interfaces are library compatible.

HALCON 18.11.0.0 Progress includes only a subset of available image acquisition interfaces. Image acquisition interfaces that are included are: BitFlow, DirectFile, DirectShow, Ensenso-NxLib, File, GenICamTL, GigEVision2, LinX, MILLite, MultiCam, O3D3xx, pylon, SaperaLT, SICK-3DCamera, SiliconSoftware, uEye, USB3Vision, and Video4Linux2. You can download additional interfaces from our web server.

Digital I/O Interfaces

In general, HALCON 18.11.0.0 Progress, HALCON 18.05 Progress and HALCON 13.0.x digital I/O interfaces are library compatible.

HALCON 18.11.0.0 Progress includes only a subset of available digital I/O interfaces. Digital I/O interfaces that are included are: OPC_UA, and Hilscher-cifX. You can download additional interfaces from our web server.

Extension Packages

Please re-generate your own extension packages developed with HALCON 18.05 Progress.

Note also the following compatibility issues:

  • German and English def-files, which are used to describe the behavior of user defined operators provided via a HALCON extension package, must be UTF-8 encoded from now on. More information.

Further Compatibility Information

  • To avoid potential problems with memory management, the HDevEngine/C++ operator SetHDevOperatorImpl no longer supports the automatic deletion of passed HDevOperatorImpl objects, and, as a consequence, no longer supports the parameter mem_set_intern. Instead, the application always has to free HDevOperatorImpl objects. HDevEngine/C++ applications, which use SetHDevOperatorImpl, must be adapted accordingly. More information.

String Encoding

HALCON's string encoding is now based on UTF-8. This may cause the following incompabilities:

  • The HALCON/C interface assumes strings to be encoded in UTF-8. This must be taken into account when C applications pass strings with non-ASCII characters to HALCON via the HALCON/C interface.  With SetHcInterfaceStringEncodingIsUtf8(false) at the beginning of the application, the HALCON/C interface can be switched to use the string encoding of the current locale. More information.
  • The HALCON/C++ interface assumes strings to be encoded in UTF-8. This must be taken into account when C++ applications pass strings with non-ASCII characters to HALCON via the HALCON/C++ interface. With HalconCpp::SetHcppInterfaceStringEncodingIsUtf8(false) at the beginning of the application, the HALCON/C++ interface can be switched to use the string encoding of the current locale. More information.
  • The operators tuple_split, tuple_str_bit_select, tuple_str_first_n, tuple_str_last_n, tuple_strchr, tuple_strlen, tuple_strrchr, tuple_strrstr, tuple_strstr and tuple_substr now operate on Unicode code points. If indices should reference raw bytes, use set_system('tsp_tuple_string_operator_mode', 'byte') to switch these operators to byte mode. More information.
  • The behavior of the operators tuple_ord, tuple_ords, tuple_chr, and tuple_chrt has changed so that they may return different results compared to older HALCON versions:
    1. True latin-1 characters (ISO88591) work as before because the Unicode codes of these characters are the same as their latin-1-ANSI codes.
    2. Latin-1 extensions like Windows code page 1252 or latin-9 (ISO885915) contain characters with ANSI-codes which differ from their Unicode counterparts, e.g., the EURO sign (€) has different codes in Windows code page 1252, latin-9, and Unicode.
    3. Multi byte characters like Asian letters or any special character in UTF-8 couldn't be processed with tuple_ord and tuple_chr until now. As a workaround it was possible to call tuple_ords and tuple_chrt for creating such a character from a number sequence or converting it into one (according to the current encoding). Such workarounds are no longer needed, but also no longer possible (with the default settings).
    Programs which used these operators with special characters which are not true latin-1 are very likely to need some modifications with the advantage that the new code is interchangeable between different locales and platforms.
    More information.
  • The data code readers assume the string encoding of the strings encoded in the symbol to be UTF-8 by default. If the string is encoded in the string encoding of the current locale, use set_data_code_2d_param(DataCode2DHandle, 'string_encoding', 'locale'). More information.
  • HDevEngine/C++ assumes strings to be encoded in UTF-8. Non-ASCII strings in the local system encoding are no longer handled correctly since they are interpreted as UTF-8 by default. This can be changed by setting HalconCpp::SetHcppInterfaceStringEncodingIsUtf8(false). More information.
  • Applications that read text files with non-ASCII characters may need to be adapted if these files have not been encoded in UTF-8. Text files should therefore be provided in UTF-8 in the future. In addition, applications which use fread_char for reading files byte-wise and rely on the fact that this operator returns exactly one byte, must be adapted. Furthermore, the operator fread_line now returns on all systems, i.e., also on Linux and macOS X, the line ending '\n' when the file was written under Windows with the line break sequence '\r\n' (carriage return + line feed). More information.
  • When communicating via send_tuple, receive_tuple, send_data, and receive_data, non-ASCII characters might not be transferred correctly anymore. If the strings of the connection partner are encoded in the encoding of the current locale, the parameter 'string_encoding' of open_socket_accept and open_socket_connect should be set to 'locale'. More information.
  • In the very unlikely case that an old lexicon file contains non-ASCII entries in the local-8-bit encoding that all could be misinterpreted as valid UTF-8 words, the lexicon would not represent the expected words. The favored way to solve the problem would be to transcode the lexicon file into UTF-8. If this is not possible because the file must be used by an old HALCON version as a workaround one could enter one entry in the native encoding that cannot be misinterpreted as UTF-8. More information.
  • When communicating via serialize_tuple or deserialize_tuple using a previous HALCON version, non-ASCII characters might not be transferred correctly anymore. In that case, you can set the parameter 'write_halcon_files_encoding' or 'read_halcon_files_encoding' of set_system to 'locale' to force HALCON to write or read its files with the current locale system encoding instead of UTF-8. More information.
  • Old programs that rely on the locale string encoding may need to be modified for returning the same results on HALCON 18.11. More information.
  • If the HDevelop command line option -convert was used to export HDevelop programs to C or C++ programs, until now string constants were encoded with the local-8-bit encoding. Now, the default to encode these strings is UTF-8. By the new option -encoding native this can be changed back to the old behavior. More information.

Legacy or No Longer Supported Functionality

The following functionality may be discontinued in a future major release:

  • Switching the string encoding of the HALCON library to the local-8-bit encoding of the current locale via set_system('filename_encoding', 'locale') is declared to be legacy now.

See the reference manual entries of legacy operators for details on how to replace them.

Planned Discontinuation of the x86-win32 platform version for Windows

MVTec plans to discontinue the x86-win32 platform version for Windows. This might likely to be happening in the course of 2020. We recommend to start switching your applications to the x64-win64 platform version for Windows.

Supported Operating Systems

Windows

HALCON 18.11.0.0 Progress has been compiled for the following Windows platform versions:

  • x86-win32 platform version for Windows 7/8/8.1/10 or Windows Server 2008 R2/2012/2012 R2/2016 on Intel Pentium 4 or AMD Athlon 64 with SSE2
  • x64-win64 platform version for Windows 7/8/8.1/10 or Windows Server 2008 R2/2012/2012 R2/2016 x64 Edition on Intel 64 or AMD 64 processors

The setup process checks whether it is running on a 32- or 64-bit system and provides a suitable list of platform versions that can be installed. During the installation, the environment variable HALCONARCH is set to x86sse2-win32 or x64-win64 to indicate the installed platform version. Please note that if you want to switch to another platform version, you must first install it. Then, you must adapt the environment variable HALCONARCH (see the Installation Guide for more information).

Linux

HALCON 18.11.0.0 Progress has been compiled for the following Linux platform versions:

  • x64 platform version for Linux x86_64, GLIBC_2.17, GLIBCXX_3.4.15, on Intel 64 or AMD 64 processors
  • armv7a platform version for Linux armv7a, Kernel with hidraw support, hard-float ABI, GLIBC_2.17, GLIBCXX_3.4.15 on Armv7-A processors with NEON support
  • aarch64 platform version for Linux aarch64, Kernel with hidraw support, GLIBC_2.17, GLIBCXX_3.4.20 on AArch64 processors

Please refer to the Installation Guide for detailed system requirements corresponding to the different Application Binary Interfaces.

macOS

HALCON 18.11.0.0 Progress has been compiled for the x64 platform version of macOS 10.12/10.13 on Intel 64.

Detailed Description of Changes in HALCON 18.11.0.0 Progress

The changes in HALCON 18.11.0.0 Progress are described with respect to HALCON 18.05 Progess. The detailed description of changes in previous HALCON versions can be found in the release notes of the previous HALCON versions.

HDevelop

New Functionality

Code Export
  • HDevelop now warns the user if code containing invalid lines is exported from the command line. Depending on the graphics capabilities of the used system, either a message box pops up or a message is written to stdout. If the option -no_msg_box is set, the message is only written to stdout and HDevelop returns -1. This is useful for a command line export via scripts, which can use the return value to catch an erroneous code export.
GUI
  • The 'Start Dialog' and the dialog box 'About' now always show the full version number, even if the last parts of the version number only contain zeros.
  • The Variable Window in HDevelop now shows the semantic type of handles for tuples that contain only a single handle.
  • HDevelop now allows to inspect handles using a new Handle Inspection Window, which can be opened by double-clicking on a variable that contains a single handle, or using the context menu of the Variable Window. The Handle Inspection Window shows the properties of the handle that can also be obtained using the get-Operators for that handle type. Note that depending on the handle type, more or less information can be displayed. The content of the window is automatically updated when stepping through the program and changes are highlighted.
Miscellaneous
  • The out-dated functionality 'Insert Program ...' has been removed from HDevelop. To transfer or reuse code use HDevelop's copy/paste mechanism, or procedures and procedure libraries.

Bug Fixes

Assistants
  • The image acquisition assistant no longer generated a close_framegrabber call. However even with the new handle mechanism an explicit close is usually desired for external resources. Therefore the call has been added again.
  • In rare cases, the operator find_text and the OCR Assistant caused a low level error about still allocated temporary memory blocks. This problem has been fixed.
  • The results of the OCR Assistant could appear corrupted in the Graphics Window. In addition, when setting the system parameter 'filename_encoding' to 'utf8', character names were not displayed correctly in the OCR Assistant. These problems have been fixed.
  • The OCR Training File Browser displayed sample names with non-ASCII characters incorrectly. This problem has been fixed. In addition, the encoding of the sample names is automatically detected (for training files that have been written with HALCON versions earlier than HALCON 18.05 Progress). If all sample names are valid UTF-8 characters the file is assumed to be encoded in UTF-8, otherwise local-8-bit encoding is used.
  • Changing the case of the variable name (e.g. from 'MyImportantVariable' to 'myimportantvariable') in the dialog box 'Read Image' did not work. This problem has been fixed.
Code Export
  • Exporting an external procedure via command line with the options -convert -no_export_of_referred_procs yielded different results than the export via the GUI with comparable settings. This problem has been fixed.
  • HDevelop's library project export generated one superfluous and corruptive semicolon which prevented the exported code from compiling. Note that this problem has already been fixed in HALCON 18.05.0.1.
  • HDevelop code which is exported to C# could not be compiled if it contained a vector expression that accesses a control variable from an object variable. This problem has been fixed.
  • In HDevelop programs that were exported as C programs or procedures in native encoding, some strings with non-ASCII characters were not correctly encoded. This problem has been fixed.
  • Temporary vectors in expressions exported to C# or VB.NET were not disposed properly in some cases. This problem has been fixed.
GUI
  • HDevelop's Function Inspect Window sometimes displayed erroneous labels on its x-axis. This problem has been fixed.
  • The tab order in the dialog box 'Bounds' of the Function Inspect Window was unintuitive. This problem has been fixed.
  • HDevelop crashed if an 3D object model has been inspected while the model changed via program execution. This problem has been fixed.
  • HDevelop's 'Visualize Object Model 3D' widget might have crashed HDevelop if more than one model was displayed together with its model ID. This problem has been fixed.
  • Interaction with the Graphics Window after changing the display font could also change the font for existing text overlays created using the disp_text operator. This problem has been fixed.
  • Interaction with the Graphics Window after changing the set_system parameter 'filename_encoding' could corrupt existing non-ASCII text overlays created using the disp_text operator. This problem has been fixed.
Help
  • HDevelop's Help Window displayed HDevelop operators with parentheses, while regular HALCON operators were displayed without parentheses. This problem has been fixed.
  • The dialog box 'Export Library Project' was linked to a wrong help page. This problem has been fixed.
IDE
  • The dialog box for selecting iconic arrays and vectors (accessible from the context menu 'Display Content' > 'Select ....') did not update its content if the variables have been changed after opening the dialog. This problem has been fixed.
  • HDevelop's auto completion suggested incorrect parameters after the code has been executed. Note that this problem has already been fixed in HALCON 18.05.0.1.
  • Interlacing two block statements in HDevelop (like for, while, endfor, endwhile) usually causes a syntax error. If one of the two blocks is actually deactivated (like * for, while, * endfor, endwhile) it must not affect the second one, and, therefore, no syntax error must occur. This, however, happened. This problem has been fixed.
  • HDevelop opened new inspection widgets for variables with sem_type 'framegrabber' instead of using an already opened inspection widget. This problem has been fixed.
  • The auto completion for dev_inspect_ctrl suggested too less variables. This problem has been fixed.
  • HDevelop could have crashed in rare cases when inserting very long program code lines. This problem has been fixed.
Procedures
  • In rare cases calls to imported procedures appeared as valid code lines although they had too many parameters. This problem has been fixed.
  • The copy-and-paste of local procedures between different HDevelop instances did not work if there was an existing local procedure at the destination with matching signature and name. This problem has been fixed.
  • Procedures with calls to non-JIT-compiled procedures could not be executed JIT-compiled, even if the calls to such procedures have been deactivated. This problem has been fixed.
  • In rare cases HDevelop corrupted code lines when pasting the bodies of copied procedures. This problem has been fixed.
  • Invalid code lines were not displayed with their actual text in the tab cards 'Invalid Lines', 'Find Results', 'Breakpoints' and 'Bookmarks' of the Quick Navigation Window. This problem has been fixed.
  • Library procedures that were both explicitly opened and available via a procedure path disappeared completely when the procedure path was removed (though they should have stayed available for editing). This problem has been fixed.
  • HDevelop sometimes didn't resolve library procedures when loading. This problem has been fixed.
Miscellaneous
  • The operator dev_set_part did not work consistently to set_part for special cases. This problem has been fixed. The remaining differences are documented.
  • HDevelop could have crashed when dev_get_system threw an error in a JIT-compiled procedure after setting ~give_error. This problem has been fixed.
  • The operator dev_set_window_extents resized the Graphic Window more than once. This problem has been fixed.
  • Drawing a region of interest while running an HDevelop script, e.g., within a while loop, led to problems. This problem has been fixed. Now, the execution of the script stops when activating the ROI tool.
  • open_socket_accept and open_socket_connect may have caused memory corruption due to an improper error handling. This problem has been fixed.

HDevelop Example Programs

New Functionality
  • The HDevelop example program hdevelop/explore_halcon.hdev has been improved by providing the program runtime for each example application.
Bug Fixes
  • The HDevelop example browser listed too many examples in the category 'Method' > 'I/O'. This problem has been fixed. Now, only IO interface examples are listed.
  • The HDevelop example program hdevelop/System/Parameters/query_system_parameters.hdev did not work correctly on machines without OpenGL installed. This problem has been fixed.
New HDevelop Example Programs
  • hdevelop/3D-Object-Model/Segmentation/measure_plant.hdev
  • hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_1_prepare.hdev
  • hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_2_train.hdev
  • hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_3_evaluate.hdev
  • hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_4_infer.hdev
  • hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_1_preprocess.hdev
  • hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_2_train.hdev
  • hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_3_evaluate.hdev
  • hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_4_infer.hdev
  • hdevelop/Image/Acquisition/genicamtl_acquisition_events.hdev
  • hdevelop/Image/Acquisition/genicamtl_devicelost_event.hdev
  • hdevelop/Image/Acquisition/genicamtl_fileaccess.hdev
  • hdevelop/Image/Acquisition/genicamtl_fwupdate.hdev
  • hdevelop/Image/Acquisition/gigevision2_acquisition_events.hdev
  • hdevelop/Image/Acquisition/gigevision2_action_control.hdev
  • hdevelop/Image/Acquisition/gigevision2_devicelost_event.hdev
  • hdevelop/Image/Acquisition/gigevision2_fileaccess.hdev
  • hdevelop/Image/Acquisition/gigevision2_fwupdate.hdev
  • hdevelop/Image/Acquisition/usb3vision_acquisition_events.hdev
  • hdevelop/Image/Acquisition/usb3vision_fileaccess.hdev
  • hdevelop/Image/Acquisition/usb3vision_fwupdate.hdev
  • hdevelop/System/IO-Devices/hilscher-cifx_data_conversion.hdev
  • hdevelop/System/IO-Devices/hilscher-cifx_read.hdev
  • hdevelop/System/IO-Devices/hilscher-cifx_simple_diagnostic.hdev
  • hdevelop/System/IO-Devices/hilscher-cifx_write.hdev
  • hdevelop/System/IO-Devices/opc_ua_monitor_subscription.hdev
  • hdevelop/System/Multithreading/get_current_hthread_id.hdev
  • hdevelop/System/Multithreading/interrupt_operator.hdev
  • hdevelop/Tuple/Data-Containers/dictionary.hdev
  • hdevelop/Tuple/String-Operations/tuple_operators_using_unicode.hdev
  • hdevelop/Tuple/String-Operations/tuple_ord_chr.hdev

HDevEngine

Bug Fixes

  • There was a (rather theoretical) possibility to crash an HDevEngine C++ application using the operator SetHDevOperatorImpl with mem_free_intern='true'. This problem has been fixed. Now, SetHDevOperatorImpl no longer supports mem_set_intern, and, as a consequence, user defined HDevOperatorImpl objects have always to be deleted by the application. Note that this change affects the compatibility. Read more.
  • During the initialization of HDevEngine, it might have happened that a small memory leak occurred (about 120kB). This problem has been fixed.
  • In rare circumstances, it was possible for HDevEngine threads to run without proper error handling so that an error encountered during script execution could have led to an application crash instead of raising an HDevException. This problem has been fixed.
  • Creating an HDevProcedure instance from a local procedure in an HDevProgram did not work when that local procedure referenced other local procedures. This problem has been fixed.

HALCON Library

Speedup

  • derivate_gauss is now slightly faster on Intel compatible processors that support AVX. In particular, the following speedups can be expected:
    Image
    Size     		Sigma Speedup
    without
    Parallelization     		Speedup
    with 8-Thread
    Parallelization
     512x512 1  15%  10%
      3  21%  10%
      5  12%  9%
      7  9%  10%
      9  8%  7%
           
     800x600 1  11%  0%
      3  22%  12%
      5  16%  13%
      7  13%  15%
      9  16%  5%
           
     1024x768 1  8%  -5%
      3  18%  11%
      5  22%  9%
      7  17%  14%
      9  18%  8%
           
     1600x1200 1  8%  0%
      3  23%  14%
      5  18%  13%
      7  12%  9%
      9  16%  11%
    Please note that the achieved speedups are slightly dependent on the chosen derivative or feature to be calculated. As a result of the speed-up, the following operators also become slightly faster:
  • The operator deviation_image is now faster for image types uint2 and real. In particular, the following speedups can be excepted:
    Image
    Size     		Image
    type     		Mask
    Size     		Speedup
    without
    Parallelization     		Speedup
    with 8-Thread
    Parallelization
    512x512 uint2 3x3 160% 180%
        9x9 540% 450%
        99x99 7000% 4250%
             
             
     1600x1200    3x3  170% 65%
         9x9  525% 265%
         99x99  7250% 3330%
             
     512x512  real 3x3  105%  40%
        9x9  365%  210%
        99x99  6050%  2500%
             
     1600x1200   3x3 100% 10%
        9x9 340% 125%
        99x99 4800% 2150%

  • The operators gen_gauss_pyramid, zoom_image_factor, and zoom_image_size are now faster for byte images on systems that support SSSE3/AVX2 for the interpolation mode 'constant' and a scale factor of 0.5 when the image width is not divisible by 16/32 without remainder. In particular, the following speedups can be expected:
    Operator Image Size Available Instruction Set Speedup
    zoom_image_size
    zoom_image_factor    		 700x500 SSSE3 up to 65%
        AVX2 up to 140%
      1180x1000 SSSE3 up to 75%
        AVX2 up to 170%
      1400x1050 SSSE3 up to 75%
        AVX2 up to 150%
           
    gen_gauss_pyramid 700x500 SSSE3 up to 45%
        AVX2 up to 105%
      1180x1000 SSSE3 up to 70%
        AVX2 up to 155%
      1400x1050 SSSE3 up to 70%
        AVX2 up to 155%
    Furthermore, there was a restriction that AVX2 code was only executed when the input images were 32 byte aligned, even if the image size was divisible by 32 without remainder. This restriction has been removed. The following speedups can be expected for byte images:
    Operator Image Size Speedup
    zoom_image_size
    zoom_image_factor    		 800x600 up to 45%
      1024x768 up to 45%
      1280x960 up to 35%
      1600x1200 up to 35%
         
    gen_gauss_pyramid 800x600 up to 35%
      1024x768 up to 30%
      1280x960 up to 30%
      1600x1200 up to 40%


New Functionality

Compute Device
  • On Arm-based platforms, available compute devices may use OpenCL now.
Data Code
  • The ECC 200 reader has been improved. In particular, it is now more robust against disturbed quiet zones. The new data code model parameter 'candidate_selection' can be used to determine the selection of candidate regions that are used for symbol detection. Further, the parameter 'contrast_min' has been removed for ECC 200 codes. The following HDevelop example programs have been adapted accordingly:
    • hdevelop/Applications/Data-Codes/ecc200_optimized_settings.hdev,
    • hdevelop/Identification/Data-Code/2d_data_codes_data_access.hdev,
    • hdevelop/Identification/Data-Code/ecc200_contrast_tolerance.hdev,
    • hdevelop/Identification/Data-Code/ecc200_print_quality_intermediate_results.hdev, and
    • hdevelop/explore_halcon.hdev.
    The HDevelop example program hdevelop/Identification/Data-Code/2d_data_codes_default_settings.hdev has been extended with the new images images/datacode/ecc200/ecc200_quiet_zone_disturbed_[01-03].png. For very simple images find_data_code_2d now has the option to use a less complex symbol search method with the new parameter 'symbol_search'.
  • The operator set_data_code_2d_param has been extended by the parameter 'string_encoding'. It specifies the expected encoding of the string which is encoded in the symbol. The string will be transcoded if necessary. Note that this change affects the compatibility. Read more.
Deep Learning
  • The classifier pretrained_dl_classifier_compact.hdl has been adapted such that the network can be used as backbone for the new operator create_dl_model_detection. Moreover, the minimal image width and height of the network have been changed from 17 pixel to 15 pixel.
  • HALCON has been extended with deep learning based object detection to locate object instances in an image. The location of an instance within the image is given by a rectangular, axis parallel bounding box.
    The new operator create_dl_model_detection has been added to create a deep learning model for object detection. For all other purposes besides creation, the general purpose dl_model operator set is used.
    The object detection model uses a pretrained deep learning classifier as backbone network. All pretrained classifiers shipping with HALCON can be used for this purpose to fit detection tasks of different difficulty.
    The HDevelop example series
    • examples/hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_1_prepare.hdev
    • examples/hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_2_train.hdev
    • examples/hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_3_evaluate.hdev
    • examples/hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_4_infer.hdev
    has been added to show how to use deep learning based object detection in HALCON. These examples use the new images in examples/images/pill_bag and the annotations in examples/hdevelop/Deep-Learning/Detection/pill_bag.json.
    To enable usage of part 3 and 4 of this series without executing the time consuming training part, the pretrained object detection model examples/hdevelop/Deep-Learning/Detection/detect_pills.hdl, the preprocessing parameters examples/hdevelop/Deep-Learning/Detection/detect_pills_preprocess_param.hdict, and the evaluation results examples/hdevelop/Deep-Learning/Detection/detect_pills_deep_learning_3_evaluate_result.hdict are used.
    The HALCON Operator Reference Manual has been extended with a chapter on object detection to describe how to use the new deep learning functionality ("Deep Learning -> Object Detection").
    The new procedure read_dl_dataset_from_coco can be used to read a set of annotations for object detection in the COCO format.
    Please note that this functionality has special system requirements. Amongst others, third party libraries have to be installed with a separate installer. This installer also contains the images and pretrained model for the examples. Please refer to the Installation Guide for more information.
  • HALCON now includes a pretrained deep learning classifier based on the popular ResNet-50 architecture: dl/pretrained_dl_classifier_resnet50.hdl.
    This classifier can be used for very complex classification tasks or as backend for very complex object detection problems.
  • HALCON has been extended with functionality to train deep learning based semantic segmentation models. These new segmentation models are a big advantage compared to previous segmentation methods. They learn automatically to segment defects or objects based on training data. These models are able to solve both
    very complex and easy segmentation tasks.
    HALCON has been extended with two pretrained semantic segmentation models, which can be found in the directory dl:
    • pretrained_dl_segmentation_compact.hdl and
    • pretrained_dl_segmentation_enhanced.hdl.
    These models can be used as a good starting point to solve advanced segmentation tasks. The general purpose dl_model operator set can be used to train, adjust, and apply these models to custom segmentation tasks. The input image dimension of this feature is flexible in width, height, and depth. The maximum image dimension is limited by the capacity of the available GPU memory used to train the model. Inference of these models is highly optimized for CPU and GPU. Training is implemented for GPUs only.
    The HDevelop example series
    • examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_1_preprocess.hdev
    • examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_2_train.hdev
    • examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_3_evaluate.hdev
    • examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects_deep_learning_4_infer.hdev
    has been added to show how to use deep learning based semantic segmentation in HALCON. These examples use ground truth annotations located in the folder examples/images/labels/pill.  To enable usage of part 3 and 4 of this series without executing the time consuming training part, the pretrained segmentation model examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects.hdl and the corresponding preprocessing parameters examples/hdevelop/Deep-Learning/Segmentation/segment_pill_defects_preprocess_param.hdict are used.
    The HALCON Operator Reference Manual has been extended with a chapter on semantic segmentation to describe how to use the new deep learning functionality ("Deep Learning -> Semantic Segmentation").
    The new procedure read_dl_dataset_segmentation can be used to read annotation data used commonly in semantic segmentation tasks.
    Please note that this functionality has special system requirements. Amongst others, third party libraries have to be installed with a separate installer. This installer also contains the images and pretrained model for the examples. Please refer to the Installation Guide for more information.
  • get_dl_classifier_train_result has been extended to individually query the 'mll_loss' and 'regularization_loss' terms of the loss function.
  • The operator train_dl_classifier_batch now supports arbitrary batch sizes independent of the available GPU device memory. This is realized by subdividing the batch into smaller subbatches from which the update is iteratively calculated. The size of the subbatches can be set with 'batch_size_device' using set_dl_classifier_param.
  • HALCON has been extended with a general purpose operator set for deep learning, which is shared by the new deep learning based functionalities Object Detection and Semantic Segmentation. The following operators have been added: The HALCON Operator Reference Manual has been extended with a chapter explaining the general concept of the deep learning model in HALCON and the data handling ("Deep Learning -> Model"). The operators train_dl_model_batch and apply_dl_model batch operate on DLSample dictionaries. A set of procedures has been added to facilitate working with these dictionaries and a set of these samples, which is called DLDataset.
    • find_dl_samples
    • gen_dl_samples
    • gen_dl_samples_from_images
    • read_dl_dataset_from_coco
    • read_dl_dataset_segmentation
    • read_dl_samples
    • split_dl_dataset
    • write_dl_samples
    The new procedure library dl_visualization contains procedures to visualize DLSamples and evaluation results
    • dev_display_dl_data
    • dev_display_dl_data_close_windows
    • dev_display_dl_data_tiled
    • dev_display_detection_detailed_evaluation
    • dev_display_segmentation_evaluation
    The new procedure library dl_preprocess contains procedures to preprocess a DLDataset for training of individual DLSamples for inference:
    • calculate_dl_segmentation_class_weights
    • create_dl_preprocess_param
    • create_dl_preprocess_param_from_model
    • gen_dl_segmentation_weight_images
    • preprocess_dl_dataset
    • preprocess_dl_model_images
    • preprocess_dl_model_segmentations
    • preprocess_dl_samples
    The new procedure library dl_evaluation contains procedures to evaluate a trained model:
    • calculate_evaluation_measures
    • create_evaluation_default_param
    • evaluate_dl_model
    • init_running_evaluation_measures
    • update_running_evaluation_measures
    The new procedure library train_dl_model contains procedures to train a dl_model:
    • create_dl_train_param
    • set_dl_model_param_based_on_preprocessing
    • train_dl_model
    The new procedure augment_dl_samples can be used to augment DLSamples for training.
    The new procedure set_dl_model_param_max_gpu_batch_size can be used to determine the maximum available batch size for a DLModel with respect to the available GPU memory.
    Please note that this functionality has special system requirements. Among others, third party libraries have to be installed with a separate installer. Please refer to the Installation Guide for more information.
  • The procedure gen_interactive_confusion_matrix has been added. It visualizes a confusion matrix whose entries can be clicked, displaying the respective images.
  • HALCON now ships with version 7.3.1 of the cuDNN library.
  • To use HALCON's deep learning functionality with NVIDIA GPUs it is now required that the graphics driver supports at least CUDA 10.0. The cuDNN and cuBLAS libraries shipping with HALCON now target CUDA 10.0.
    This does not affect the aarch64 platform, which only requires a CUDA 9.0 compatible driver.
File
Filter
  • The operator deviation_image is now faster by up to 40% for byte images. Note that this change affects the compatibility. Read more.
Matching
Miscellaneous
  • The new operators get_handle_param, get_handle_tuple, and get_handle_object have been added. They can be used to inspect handles of most types, which can help during development and debugging of applications.
  • When HALCON was installed into a folder with non-ASCII characters or if global HALCON folders like the image or 3d model directory were set with the set_system operator to a path with non-ASCII characters, and if afterwards the filename encoding was changed, the folder names became corrupted and could not be used correctly, e.g., when opening an image with the read_image operator passing only the file name without full path. This problem has been fixed.
  • HALCON has been extended with the new set_system parameter 'disabled_operators' that disables the specified HALCON operators. Those operators will return H_ERR_OP_DISABLED if used. The intended use case is to allow developers of freely programmable devices (usually with HDevengine) to explicitly deactivate certain HALCON operators which could affect the security of the device.
Timeout
  • HALCON has been extended with the operators get_current_hthread_id and interrupt_operator that enable sending an interruption signal to an operator running in a particular thread from another thread. The new HDevelop example programs hdevelop/System/Multithreading/get_current_hthread_id.hdev and hdevelop/System/Multitthreading/interrupt_operator.hdev show how the new operators can be used to interrupt operators running in a known thread.
  • The operator get_operator_info provides a new parameter 'interrupt_mode' to query whether a specific operator supports execution cancellation.
Tuple
  • HALCON has been extended with a new container data type called 'dictionary'. It allows to store arbitrary key-value pairs, which can be retrieved in constant time. This can help to structure programs when, e.g., passing many parameters to a procedure. For this, the following new operators were introduced: serialize_handle and deserialize_handle have been adapted so that they can (de)serialize dictionaries. Besides a HALCON-specific format, read_dict can also read files in the JSON format.
    The HDevelop example program examples/hdevelop/Tuple/Data-Containers/dictionary.hdev has been added, which replaces the HDevelop example examples/hdevelop/System/Multithreading/messages_as_dictionary.hdev.
    The HDevelop example programs examples/hdevelop/Applications/Robot_Vision/pick_and_place_with_2d_matching_moving_cam.hdev, examples/hdevelop/Applications/Robot_Vision/pick_and_place_with_2d_matching_stationary_cam.hdev, and examples/hdevelop/Calibration/Hand-Eye/calibrate_hand_eye_stationary_cam_approx.hdev have been adapted to use dictionaries instead of messages. Note that this change affects the compatibility. Read more.
  • When an empty tuple was used in tuple_concat, a mixed tuple was returned. Now the returned tuple has the type of the non empty tuple.

Bug Fixes

3D
  • When calling create_surface_model in parallel from several threads with the 'train_3d_edges' parameter set to 'true', the created models were incorrect and could contain invalid 2D and 3D edges. This problem has been fixed. create_surface_model is now safe to use from multiple threads.
  • The operators disp_object_model_3d, render_object_model_3d, display_scene_3d, and render_scene_3d could crash when displaying infinite primitive shapes (cylinders or planes without boundary). This problem has been fixed.
  • The operator distance_object_model_3d, when applied with the 'voxel' method, sometimes returned incorrect distances. This problem has been fixed. Note that 3D object models for which the 'voxel' index was previously created with the operator prepare_object_model_3d and that were written as OM3 file need to be re-prepared to apply this fix.
  • distance_object_model_3d was not using the information prepared in prepare_object_model_3d by default. This problem has been fixed.
  • The operator fit_primitives_object_model_3d can fit cylinders into point clouds. Sometimes, small changes of the input point cloud switched the orientation of the fitted cylinder, i.e., its pose and axis. This problem has been fixed. Now, the axis points towards the half space in which the origin is located.
  • gen_binocular_rectification_map and set_stereo_model_image_pairs in rare cases raised an error because the generated maps got too large. This problem has been fixed. Now, the parameter 'Method' of gen_binocular_rectification_map has the new default value 'viewing_direction'. set_stereo_model_image_pairs also uses this method per default. set_stereo_model_param, get_stereo_model_param, and create_stereo_model have been extended with the generic parameter (GenParamName) 'rectif_method' and the according parameter values (GenParamValue) 'viewing_direction' or 'geometric'. Note that this change affects the compatibility. Read more.
  • The debug procedure procedures/general/debug_find_surface_model.hdpl displayed incorrect edges if the center of the surface model was not the origin. Additionally, the initial visualization pose was such that the model was not visible. These problems have been fixed. debug_find_surface_model.dhpl now shows the correct edges and uses the correct initial pose.
  • The operator segment_object_model_3d crashed in rare cases. This problem has been fixed.
  • For the file format 'om3', the operators set_object_model_3d_attrib, set_object_model_3d_attrib_mod and read_object_model_3d did not raise errors for inconsistent 'xyz_mappings', e.g., for mappings of height zero, or pixel values outside the given image dimensions. Many operators processing object_model_3d with mappings might have crashed due to the inconsistently generated models. This problem has been fixed. Now, set_object_model_3d_attrib and set_object_model_3d_attrib_mod return the following errors:
    • 3524 ("Image width <= 0"),
    • 3521 ("Image width > MAX_FORMAT"),
    • 3525 ("Image height <= 0"),
    • 3523 ("Image height > MAX_FORMAT"),
    • 1304 ("Wrong value of control parameter 4").
    The operator read_object_model_3d now returns the error 9511 ("Invalid 3D object model").
  • triangulate_object_model_3d with Method set to 'implicit' returned different results for empty GenParamName and GenParamValue on the one hand, and GenParamName set to 'implicit_octree_depth', GenParamValue set to 6 on the other hand, although 6 is the default value of 'implicit_octree_depth'. This problem has been fixed. Now, triangulate_object_model_3d in both cases returns the results which previously were returned for empty parameters.
  • The procedure debug_find_surface_model sometimes threw internal exceptions when some 3D object models, such as edges, were empty. This problem has been fixed. Now, exceptions in sub-tools are caught and properly reported.
Bar Code
  • find_bar_code, decode_bar_code_rectangle2, and find_data_code_2d in some cases returned incorrect results if the internal image width and height of the system were smaller than the actual size of the input image. This could have happened in cases where the operators were called in a different thread than the one in which the corresponding image has been read or created or if the system image width and height has been changed with set_system. This problem has been fixed.
  • The operator find_bar_code crashed in rare cases when the 'quiet_zone' of set_bar_code_param was set to a high value. This problem has been fixed.
  • In some cases, find_bar_code was significantly slower on machines with many cores. This problem has been fixed.
  • The operator find_bar_code did not check the quiet zone correctly when the quiet zone check was enabled. This problem has been fixed.
  • get_bar_code_result could have returned wrong values for the ISO/IEC 15416 decodability in case of EAN-8 symbols. This problem has been fixed.
  • get_bar_code_result with quality_isoiec15416 in rare cases returned an incorrect modulation grade when an edge was lying directly at the end of the quiet zone. This problem has been fixed.
  • The operator set_bar_code_param adapted the value of 'min_identical_scanlines' when 'num_scanlines' was set to 0. This problem has been fixed. Now, 'min_identical_scanlines' is adapted only when 'num_scanlines' is greater than 0.
  • In very rare cases, horizontally oriented barcodes could not be decoded. This problem has been fixed. Note that this change affects the compatibility. Read more.
  • HALCON now supports all GS1 application identifiers specified in the latest version of the "GS1 General Specifications" (January 2018).
Calibration
  • The operators calibrate_cameras, binocular_calibration, and the camera calibration in calibrate_hand_eye in rare cases did not perform as well as expected, i. e., they have returned with an unnecessarily high reprojection error. This problem has been fixed. Note that this change affects the compatibility. Read more.
  • The comments of the calibration description files generated by create_caltab contained misleading values for 'width' and 'height'. Furthermore, the formulas for 'width' and 'height' in the reference manual entry of create_caltab were incorrect. These problems have been fixed.
  • gen_binocular_rectification_map and set_stereo_model_image_pairs in rare cases raised an error because the generated maps got too large. This problem has been fixed. Now, the parameter 'Method' of gen_binocular_rectification_map has the new default value 'viewing_direction'. set_stereo_model_image_pairs also uses this method per default. set_stereo_model_param, get_stereo_model_param, and create_stereo_model have been extended with the generic parameter (GenParamName) 'rectif_method' and the according parameter values (GenParamValue) 'viewing_direction' or 'geometric'. Note that this change affects the compatibility. Read more.
  • get_calib_data for ItemType set to 'camera' and DataName set to 'params_deviations' or 'params_covariances' returned unintuitive values more often than necessary, in particular when the covariance matrix was nearly singular. This problem has been fixed. Note that this change affects the compatibility. Read more.
Classification
  • The operators classify_class_gmm and evaluate_class_gmm returned incorrect values for the k-sigma probability 'KSigmaProb' for Gaussian Mixture Models with covariance type 'spherical' or 'diag'. This problem has been fixed. Note that this change affects the compatibility. Read more.
  • When removing sample identifier training data out of a set of multiple samples, internal data structures may have been corrupted. This problem has been fixed.
  • In very rare cases a support vector machine (SVM) issued an error that it is not trained yet, despite being trained. This problem has been fixed.
Data Code
  • find_bar_code, decode_bar_code_rectangle2, and find_data_code_2d in some cases returned incorrect results if the internal image width and height of the system were smaller than the actual size of the input image. This could have happened in cases where the operators were called in a different thread than the one in which the corresponding image has been read or created or if the system image width and height has been changed with set_system. This problem has been fixed.
  • In very rare cases find_data_code_2d crashed for ECC 200 symbols if a candidate was found close to the image border. This problem has been fixed.
  • In very rare cases, find_data_code_2d crashed with signal 11 failure for Aztec codes. This problem has been fixed.
  • The operators find_data_code_2d and find_bar_code were not able to decode in case of an GS1 Code containing the application identifier 714. This problem has been fixed.
  • The operators find_data_code_2d and set_distance_transform_xld_param did not set the 'modified' flag for their handle parameter, which can get queried with get_param_info. This problem has been fixed.
  • For invalid values of the data code model parameter 'module_gap' find_data_code_2d crashed in rare cases. This problem has been fixed.
  • For Micro QR and Aztec codes find_data_code_2d in some cases was significantly slower on machines with many cores. This problem has been fixed.
  • In very rare cases the print quality inspection for ECC 200 codes crashed for symbols that lay close to the image border. This problem has been fixed.
  • In some cases the variable module grid used for print quality inspection of the ECC 200 reader was inaccurate in case of distorted clock patterns. This could have led to bad quality grades. This problem has been fixed.
  • get_data_code_2d_results returned wrong values for 'symbol_identifier' of Aztec codes when the data string contained a FNC1 character. This problem has been fixed.
  • In some cases get_data_code_2d_results returned wrong  ISOIEC 15415 and AIMDPM-2006-1 quality values for 'print growth' and 'contrast uniformity'. This problem has been fixed.
  • The operator get_data_code_2d_results returned invalid values for the candidate groups 'symbology_ident' and 'structured_append' in case of Micro QR Codes. This problem has been fixed.  Note that this change affects the compatibility. Read more.
  • HALCON now supports all GS1 application identifiers specified in the latest version of the "GS1 General Specifications" (January 2018).
Deep Learning
  • Handles of the deep-learning-based classifier (dl_classifier) could not be deserialized with deserialize_handle. This problem has been fixed.
  • The deep-learning-enhanced classifier did not perform well when resized. This problem has been fixed. As a consequence the minimal image width and height for the enhanced classifier is now 47.
  • The procedure dev_display_dl_classifier_heatmap did not work for single-channel input images. This problem has been fixed. Now, the procedure works for images with either one or three channels.
  • In some cases, train_dl_classifier_batch reported a cuDNN error in out of memory constellations. This problem has been fixed. Now, an error indicating that no memory is available on the GPU is returned instead.
  • The serialization of larger models was significantly slower than writing them to disc. This behavior has been improved. As a consequence, the memory consumption of serialized models increased up to 25%.
Feature
File
  • Calling copy_file with long path names on Windows could lead to an error in temporary memory management. This problem has been fixed.
  • Using very long path names for the copy_file operator could crash HALCON. This problem has been fixed.
  • The operators read_image and read_region leaked memory when for concatenated objects the error 5279 ("Unexpected object detected") was returned for the second or any subsequent indices of the object array. This problem has been fixed.
  • Using very long filenames with write_image in 'tiff' format or write_ocv may have caused buffer overruns and crashes. This problem has been fixed.
  • A check preventing serialized data to be written to files not opened in binary mode was missing, resulting in possible data corruption. This problem has been fixed. Now, the error 5281 ("File has not been opened in binary file format") is returned in attempts to read or write serialized data to/from files not opened in binary mode.
Filter
Graphics
  • The operators disp_rectangle1 and disp_rectangle2 could show unwanted display artifacts when anti-aliasing was enabled. This problem has been fixed.
  • dump_window_image now supports setting the internal image width and height of the system. The internal width and height of the system are the maximum width and height of all HALCON image objects. It will be increased if images of greater width or height are instantiated subsequently.
  • The operator read_string allows to limit the size of the string that can be entered into a HALCON window. After switching the encoding of the HALCON library to UTF-8 with set_system ('filename_encoding', 'utf8') the passed length could not entirely be used when non-ASCII characters had been entered. This problem has been fixed. In UTF-8 mode the Length parameter now determines the number of characters instead of the number of bytes. This is not true in the legacy 'locale' encoding mode and for legacy HALCON windows.
  • set_drawing_object_params in rare cases might have caused HDevelop to freeze. For drawing objects of type rectangle1, set_drawing_object_params in rare cases might have crashed or raised a memory error. This problem has been fixed.
  • The operators set_window_extents and dev_set_window_extents crashed if 'flush' was set to 'false'. This problem has been fixed.
  • If HIOCancelDraw was called before calling a drawing operator, the drawing operator aborted immediately. This problem has been fixed.
Images
  • The operator channels_to_image threw the HALCON error 3513 ("Internal error: number of chords too big for num_max") for images with 'Width' equal to 1. This problem has been fixed.
  • The operators crop_rectangle1 and crop_part raised an error in cases where more than one input image and more than one set of region parameters was specified and the numbers were not equal. Furthermore, they might have raised errors when used in parallel in cases where more input images than available threads and more than one set of region parameters was specified. This problem has been fixed.
  • write_image leaked memory when writing the 'jpegxr' format. This problem has been fixed.
Matching
Measure
Memory
  • The temporary memory used by the last operator returned by get_system('temp_mem') was inaccurate. This problem has been fixed.
Miscellaneous
  • The operators disp_text and dev_disp_text crashed if a handle was passed for the parameters 'String', 'Row', or 'Column'. This problem has been fixed.
  • Setting the parameters 'width' or 'height' for region clipping purpose in a multi threaded environment might have led to an unpredictable automatic update behavior of these parameter values by image generating operators. This problem has been fixed.
  • The operator get_operator_info could leak memory when attempting to retrieve a slot that is empty for an operator. This problem has been fixed.
  • The operator line_position converted its inputs to integer values prior to calculating its outputs. This problem has been fixed. The operator will now work correctly on floating point input values.
  • The operator optimize_aop crashed if the help files could not be found. This problem has been fixed. Now, optimize_aop will report an error instead.
  • In contrast to the documentation, the operator set_sheet_of_light_param did not accept 'um' as alternative to 'microns' for the different generic scale and offset parameters. This problem has been fixed. In addition, the operator read_object_model_3d also accepts 'um' for the parameter 'Scale' now.
  • Using excessively long arguments for set_system or HAccessGlVar may have resulted in buffer overruns. This problem has been fixed. Now, the HALCON error 5141 ("String too long or too high") will be raised.
  • For some error codes no error messages were returned. This problem has been fixed.
  • In rare cases HALCON could deadlock when running out of memory. This problem has been fixed.
Morphology
OCR
  • In rare cases find_text led to a stack overflow for highly textured images. The problem occured for text models of mode 'manual' and for parameter settings that created a very large number of candidate regions. This problem has been fixed.
  • In rare cases, the operator find_text and the OCR Assistant caused a low level error about still allocated temporary memory blocks. This problem has been fixed.
  • The operator get_text_object crashed when no value or only an integer or float value was passed to the parameter 'ResultName'. This problem has been fixed. Note that this change affects the compatibility. Read more.
  • When a lexicon file was created in UTF-8 encoding and the file starts with a Unicode marker (some editors like Windows Notepad add it automatically), the first entry of the lexicon file could not be read correctly by the appropriate HALCON operators import_lexicon and do_ocr_word_*. This problem has been fixed.
Parallelization
  • find_bar_code, decode_bar_code_rectangle2, and find_data_code_2d in some cases returned incorrect results if the internal image width and height of the system were smaller than the actual size of the input image. This could have happened in cases where the operators were called in a different thread than the one in which the corresponding image has been read or created or if the system image width and height has been changed with set_system. This problem has been fixed.
Region
Segmentation
  • auto_threshold crashed for images of type 'real' with a constant gray value. This problem has been fixed.
System
  • Calling get_system for the parameter 'opengl_info' returned an error if the DISPLAY environment variable was not set on Linux systems, or when not running in a graphical session on macOS systems. This problem has been fixed. Now, get_system will return 'No OpenGL support included' in both cases.
Tuple
  • The semantic type of some handles as reported by tuple_sem_type and tuple_sem_type_elem were inconsistent with the semantic type defined in the operator arguments that use those handles. This problem has been fixed. In particular, now the following semantic types are used consistently:
    • 'surface_matching_result' (previously also 'surface_result')
    • 'deformable_surface_matching_result' (previously also 'surface_result_deformable')
    • 'sheet_of_light_model' (previously also 'sheet_of_light')
    • 'dl_classifier_train_result' (previously also 'dl_classifier_training_result')
      Note that this change affects the compatibility. Read more.
  • The error codes of the operators tuple_str_first_n and tuple_str_last_n were wrong. When the Position parameter was lower than 0 or greater than the string length, these operators returned the error 1301 ("Wrong value of control parameter 1"). This problem has been fixed. Now, in case of an invalid Position parameter these operators return the error 1302 ("Wrong value of control parameter 2").
XLD

String Encoding

HALCON's string encoding is now based on UTF-8. The following adaptions have been made:

  • The HALCON operators that handle regular expressions, namely tuple_regexp_match, tuple_regexp_replace, tuple_regexp_select, and tuple_regexp_test as well as the OCR operators do_ocr_word_cnn, do_ocr_word_knn, do_ocr_word_mlp, and do_ocr_word_svm are now able to match arbitrary Unicode characters like German Umlauts and Japanese characters. This includes the correct counting of characters as well as the correct interpretation of character classes like spaces (\s), letters or digits (\w), lower and upper case letters ([:lower:], [:upper:], option 'ignore_case'), and word boundaries. In addition, in tuple_regexp_replace a problem with regular expressions with '^' (start of string) and the 'replace_all' option has been fixed.
  • The HALCON/C interface has been improved to support the handling of strings with a defined encoding in C applications that use HALCON. The default encoding that is used by the HALCON/C interface is UTF-8 now. For applications using strings with the locale encoding, the interface can be changed by calling the function SetHcInterfaceStringEncodingIsUtf8(false) at the beginning of the program. In addition, the HALCON/C interface now provides functions for passing and receiving strings with a defined encoding when working with Htuple, independently on the global interface encoding. Under Windows this includes also functions for passing and receiving wide character strings (wchar_t*). Note that this change affects the compatibility. Read more.
  • The HALCON/C++ interface has been improved to ease the integration of HALCON into Unicode aware C++ applications. Character pointers in HTuple and HString as well as strings returned by HALCON operators are encoded in UTF-8 and will be transcoded to the internal string encoding of the HALCON library when necessary. Furthermore, under Windows support for wide characters has been added. It is now possible to initialize an HTuple, HTupleElement and HString with wchar_t*-string. Operators except wide character strings as input. HString has been extended by HString::TextW() and HString::LengthW(), providing access to a wide character representation of the string and its length. When UNICODE is defined, HString::Text() and HString::Length() will refer to these wide character variants, otherwise to HString::TextA() and HString::LengthA(), the character variants in interface encoding. Wide character strings internally are transcoded to the interface encoding. For applications using strings with locale encoding, it is possible to switch the HALCON/C++ interface encoding to the locale string encoding by calling HalconCpp::SetHcppInterfaceStringEncodingIsUtf8(false) at the beginning of the program. For each HALCON operator call, the HALCON/C++ interface will transcode all strings to the HALCON internal encoding (default UTF-8). To ease the compatibility with other C++ code, the HString class has been extended by the methods HString::FromUtf8, HString::ToUtf8, HString::FromLocal8Bit and HString::ToLocal8Bit to convert strings independently of the HALCON/C++ interface encoding. Note that this change affects the compatibility. Read more.
  • The operators tuple_split, tuple_str_bit_select, tuple_str_first_n, tuple_str_last_n, tuple_strchr, tuple_strlen, tuple_strrchr, tuple_strrstr, tuple_strstr and tuple_substr now support Unicode code points. All positions reference Unicode code points. Unicode code points may consist of more than one byte in the UTF-8 string. If positions should reference raw bytes, these operators may be switched to a byte mode with the thread specific setting set_system('tsp_tuple_string_operator_mode', 'byte'). Note that this change affects the compatibility. Read more.
  • HDevelop has been adapted to support the new UTF-8 handling in HALCON.
    Some changed behavior is implicit due to the changed behavior of the HALCON library. In particular the default setting for 'filename_encoding' is now 'utf8', and string operations in the HDevelop language inherit UTF-8 aware behavior from the improved HALCON operators. For example the expression s{i} will now correctly return the character at position i as documented instead of byte i of the encoded representation as previously. Similarly, ord and chr functions will convert between string representations and Unicode code points. For pure ASCII strings the behavior is backward compatible. Also for legacy purposes it is still possible to revert to the 'locale' setting.
    In addition, the word processing functionality in the OCR assistant has been fixed to properly handle corrections for non-ASCII text.
  • The operators tuple_ord, tuple_ords, tuple_chr, and tuple_chrt have been improved. In older HALCON versions these operators were based on the byte representation of characters and strings. That was accompanied by the following disadvantage: first, the result of the operations depended on the current encoding ('locale' vs. 'utf8') and the system (Windows, Linux, macOS X), and second, the operators tuple_ord and tuple_chr could not be called with multi byte characters. These restrictions have been resolved: When the encoding used by the HALCON library is UTF-8 (which is the default now) these operators are based on Unicode characters and return or accept Unicode code points. This allows to call tuple_ord also on Asian letters or German Umlauts and to get the same result on all systems. If the actual byte representation of a UTF-8-string is needed, the behavior can be changed with the new set_system option 'tuple_string_operator_mode' which can be set to 'byte'. When the HALCON library encoding was set to the legacy mode 'locale' the operators behave as in older HALCON versions. There is a new example program hdevelop/Tuple/String-Operations/tuple_ord_chr.hdev. It demonstrates the usage of these operators with arbitrary Unicode code points. Note that this change affects the compatibility. Read more.
  • HDevEngine has been adapted to the improved handling of string encoding in HALCON. For HDevEngine/C++ the expected encoding for const char* parameters is now the explicitely specified HALCON/C++ interface encoding (default is UTF-8). This also holds when creating or accessing HTuple instances, e.g., for passing parameters to procedures. In addition, members with const char* parameters that represent path or file names have been extended with a const wchar_t* signature variant under Windows. Those always accept the standard UTF-16 encoding for UNICODE applications. For HDevEngine/.NET this change is transparent to the user and everything will work as before. A problem in HDevProcedure.ShortDescription was fixed and this property will now also correctly represent non-ASCII characters in the short description. Note that this change affects the compatibility. Read more.
  • The operator open_file now supports setting the string encoding. Three modes are supported: 'utf8_encoding', 'locale_encoding' and 'ignore_encoding'. If the encoding is not explicitly set to be ignored, the string encoding is used by all operators that read or write text files (fread_char, fread_line, fread_string and fwrite_string). These operators are now able to handle multi-byte characters as well as special encoding-dependent characters like Unicode white spaces and line breaks. Furthermore, the strings are now correctly transcoded between the internal encoding of the HALCON library and the file encoding if the encodings differ. Note that this change affects the compatibility. Read more.
  • The operators send_tuple, receive_tuple, send_data, and receive_data now use UTF-8 by default to encode strings. Note that this change affects the compatibility. Read more.
  • Lexicon files can be used to provide a predefined set of words, e.g., for looking them up in conjunction with OCR operators. From now on, these lexicon files have to be encoded in UTF-8 if they contain non-ASCII characters. Old lexicon files with non-ASCII characters that were encoded with the local-8-bit encoding are still supported and will automatically be detected and converted to UTF-8, as long as they do not contain only strings that accidentally are all also valid UTF-8.
    The operator suggest_lexicon can be used to suggest for an arbitrary word that entry of the lexicon that can be obtained with the minimum number of edit operations applied on the input word. Until now, this operation depended on the encoding because it counted the number of bytes to change. From now on it is based on the actual characters so the results will meet one's expectations better.
    Note that this change affects the compatibility. Read more.
  • Sequence files used by the HALCON virtual image acquisition (i.e., file) interface have to be encoded in UTF-8 from now on. Old sequence files, which use the local-8-bit encoding and do not accidentally yield a valid UTF-8 string, are still supported and will automatically be detected.
  • The operators serialize_tuple and deserialize_tuple now use UTF-8 by default to encode strings. Note that this change affects the compatibility. Read more.
  • The default encoding which is used for representing strings with non-ASCII characters within the HALCON library was changed to UTF-8. This allows to represent arbitrary characters in a unique way on all systems independent of the system and the current locale. The locale encoding is still supported as legacy mode for running old programs. This mode can be achieved via set_system('filename_encoding', 'locale') or by setting the environment variable HALCON_ENCODING to LOCALE. Applications that use the HALCON/C or HALCON/C++ interface for calling HALCON operators can also set the encoding of the interface independently of the HALCON encoding. Note that this change affects the compatibility. Read more.
  • Programmers who want to extend HALCON by their own operator set via the 'HALCON Extension Package Interface' have to respect that the def-files which are used to define the operators and to describe their functionality are expected to be UTF-8 encoded from now on for all supported languages, not only for Japanese as before. Note that this change affects the compatibility. Read more.
  • For HDevelop programs that are exported to one of the programming languages C, C++, C#, or VisualBasic .NET via the HDevelop command line option -convert, the default encoding of string constants in the output source files was changed to UTF-8. This can be set back to locale encoding by the new command line option -encoding native, which can only be used in conjunction with the -convert option. In order to avoid problems with some C and C++ compilers, in the exported C and C++ files the non-ASCII characters in string constants are represented by octal code sequences. Furthermore, when an HDevelop program is exported in native (locale) encoding to a C or C++ program, the HALCON/C or C++ interface encoding is set accordingly at the begin of the generated program. Note that this change affects the compatibility. Read more.

Procedures

Functionality

  • The usability of the procedure inspect_object_model_3d and the operator create_shape_model_3d has been improved. Now, it is mentioned that the coordinate system of the model may differ from the CAD origin.
  • The procedure visualize_object_model_3d no longer throws an exception when passing an empty 3D object model for visualization.
  • The standard procedures in HALCON contained the procedure determine_optimum_pose_distance twice, in different libraries. This problem has been fixed. The duplicate was removed and the procedure now exists only in the library visualize_object_model_3d.hdpl.

Bug Fixes

  • The procedure reference entry of list_image_files mentioned a wrong path to an environment variable. This problem has been fixed.
  • The procedures disp_object_model_no_opengl, color_string_to_rgb, disp_object_model_3d_safe, disp_text_button, gen_arrow_object_model_3d, get_object_models_center, and tuple_vector_cross_product were delivered as public and as private procedures. This problem has been fixed. Now, they are only delivered as public procedures.

HALCON/C

Bug Fixes

HALCON/C++

Bug Fixes

  • The behavior for vector remove function has been changed in the language interfaces C# and C++. Deleting with an index greater than the tuple size caused an error. This problem has been fixed.

HALCON/.NET

Functionality

  • The HSmartWindowControlWPF has been extended to fully support Data Binding. To achieve this, additional properties have been added to the HSmartWindowControl to set the drawing options. In addition, HIconicDispayObjectWPF and HMessageDisplayObjectWPF objects can be added as items to the HSmartWindowControlWPF. These new objects also support Data Binding.
  • The performance of tuple_concat when using the HALCON/.NET language interface has been improved in some common cases.

Bug Fixes

  • Tuples of a single type were sometimes converted into mixed tuples leading to unexpected results from the tuple_is_string and tuple_is_int operators. This problem has been fixed.
  • The behavior for vector remove function has been changed in the language interfaces C# and C++. Deleting with an index greater than the tuple size caused an error. This problem has been fixed.
  • If HIOCancelDraw was called before calling a drawing operator, the drawing operator aborted immediately. This problem has been fixed.
  • HDevelop code which is exported to C# could not be compiled if it contained a vector expression that accesses a control variable from an object variable. This problem has been fixed.
  • The HSmartWindowControl was overwriting the property HImagePart when the internal HALCON window was created. This problem has been fixed.

Language Interface Example Programs

Bug Fixes

  • In the header file HDevEngineCpp.h for using the HDevEngine two comments were marked with TODO. This problem has been fixed.
  • The C# DrawingObjectsWPF example did not work correctly when using handles. This problem has been fixed.
  • The operator set_drawing_object_params only accepted integer values for the generic parameter 'line_width'. This problem has been fixed. Now, also floating point numbers are accepted. In this case the number is rounded to the nearest integer.

HALCON Variable Inspect

Bug Fixes

  • Reading the memory in HALCON Vaiable Inspect Visual Studio extension failed in some cases. This problem has been fixed.

Extension Packages

Bug Fixes

  • Messages previously allowed only certain strings as keys. This restriction has been lifted. Messages now allow integers and arbitrary strings as keys.

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.

New Image Acquisition Interfaces

  • The USB3Vision image acquisition interface is now also available for Arm-based platforms.

Miscellaneous

  • The handling of events in the GenICamTL, GigEVision2 and USB3Vision interfaces has been extended. It is now possible to register a message queue for GenICam events like DeviceLost. Furthermore, subscriptions to nodes with the OPC_UA interface now support registering a message queue that receives notifications when the node value changes.
  • GenApi has been updated to version 3.1.0, which is required by the GenICamTL, GigEVision2, and USB3Vision image acquisition interfaces.
  • Opening and closing multiple framegrabbers using the same image acquisition interface could lead to crashes. This problem has been fixed.
  • The operator open_framegrabber crashed with strings longer than 1024 characters as input control data. This problem has been fixed. Now, an error is returned.
  • When a sequence file, which collects images for the HALCON Virtual File interface, was created in UTF-8 encoding and the file starts with a Unicode marker (some editors like Windows Notepad add it automatically), the first entry of the sequence file could not be read correctly by the operator grab_image. This problem has been fixed.
  • In the template to create an image acquisition interface (%HALCONEXAMPLES%\ia_integration), the value of 'HGInitNewImage' was modified via 'HWriteSysComInfo' before calling 'HNewImage'. In case of failure, its value was not always properly restored. This problem has been fixed. Moreover, the third argument of 'HReadSysComInfo' was of type *HINT instead of the expected type *HBOOL. This could lead to potential access to uninitialized memory. This problem has been fixed.

Image Acquisition Example Programs

  • The following HDevelop example programs used old handle names, display settings, or acquisition interfaces:
    • hdevelop/Identification/Data-Code/calibration_aimdpm_1_2006.hdev,
    • hdevelop/Identification/Data-Code/print_quality_aimdpm_1_2006.hdev,
    • hdevelop/Matching/Component-Based/cbm_param_visual.hdev, and
    • hdevelop/Matching/Component-Based/cbm_sbm.hdev.
    This problem has been fixed.
  • The following image acquisition example programs have been renamed so that the name is consistent with other examples:
    • genicamtl_gocator_objectmodel3d.hdev -> genicamtl_lmi_gocator_objectmodel3d.hdev
    • genicamtl_areascan3d_objectmodel3d.hdev -> genicamtl_vrmagic_areascan3d_objectmodel3d.hdev
    • gigevision2_atc4_objectmodel3d.hdev -> gigevision2_automation_technology_c4_objectmodel3d.hdev

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.

New Digital I/O Interfaces

  • The OPC_UA interface is now also available for the Arm-based platforms armv7a and aarch64.
  • HALCON now provides the new Hilscher-cifX interface which in combination with hardware using Hilscher communication chips supports communication with PLCs. In particular, you can now communicate with a PLC directly from HALCON via real-time ethernet and fieldbus protocols when using this new interface.

Miscellaneous

  • The handling of events in the GenICamTL, GigEVision2 and USB3Vision interfaces has been extended. It is now possible to register a message queue for GenICam events like DeviceLost. Furthermore, subscriptions to nodes with the OPC_UA interface now support registering a message queue that receives notifications when the node value changes.
  • HALCON did not unload an I/O interface after the last device using it is closed. This problem has been fixed.
  • The operator get_io_channel_param always returned an empty tuple for the parameter GenParamValue for any digital I/O interface. Note that this problem has already been fixed in HALCON 18.05.0.1.
  • Opening an I/O device leaked a small amount of memory. This problem has been fixed.
  • The OPC_Classic interface is no longer part of the standard HALCON installation. However, it is still available for download.

HALCON for Embedded Vision

Functionality

  • HALCON is now also available for 64-bit Arm-based platforms.  I.e., the Linux installer, which can be downloaded as usual from the MVTec website, has been extended by the option to additionally install the components necessary for 64-bit Arm-based platforms. These components include:
    • HALCON libraries including HDevEngine,
    • two example programs for C++ and HDevEngine,
    • image acquisition interfaces (Video4Linux2, File, GenICamTL, GigEVision, USB3Vision),
    • the I/O interface OPC_UA, and
    • a tar-file for the installation of the runtime files on a 64-bit Arm-based platform.
    Additionally, hbench has been extended by a new reference CPU, which is an Arm Cortex-A57.
  • On Arm-based platforms, available compute devices may use OpenCL now.

Documentation

Programmer's Manuals

  • The Extension Package Programmer’s Manual now includes instructions on how to use the HANDLE_PAR data type in tuples.
  • In the Programmers Guide, chapter 5.2.5 'The Tuple Mode', in the 2nd code block, 'ToString()' was missing. This problem has been fixed.
  • The Programmer's Guide did not clearly mention the procedure call clean up in case of an exception. This problem has been fixed.

Reference Manual

  • The reference manual entry of binary_threshold falsely listed 'real' as possible value for the image type of the input image. This problem has been fixed.
  • For create_surface_model and find_surface_model, the reference manual did not mention that the normal vectors need to point inwards when 'train_3d_edges' is enabled. This problem has been fixed.
  • The reference manual entries of do_ocr_word_cnn, do_ocr_word_knn, do_ocr_word_mlp and do_ocr_word_svm have been extended. They now describe how the score parameter is calculated.
  • The operators draw_nurbs, draw_nurbs_mod, draw_nurbs_interp, draw_nurbs_interp_mod, drag_region1, drag_region2, and drag_region3 do not work in HDevelop graphics windows. The corresponding warning messages in the operator reference have been updated accordingly.
  • The generic parameters 'pose_ref_dist_threshold_edges_rel', 'pose_ref_dist_threshold_edges_abs', 'pose_ref_scoring_dist_edges_rel', and 'pose_ref_scoring_dist_edges_abs' of the operators find_surface_model and find_surface_model_image were not documented. This problem has been fixed. Note that the parameters are also supported, even if not documented, by previous versions of HALCON that support edge-supported surface-based matching.
  • Within the chapter Calibration / Calibration Object of the reference manual, the list of suggested calibration plates for the parameter 'CalPlateDescr' was outdated. This problem has been fixed.
  • In the reference manual, it was not documented that the parameter 'MinContrast' influences the automatic contrast estimation of the parameter 'Contrast' when creating a model for shape-based, component-based, or deformable matching. This problem has been fixed.
  • The legacy status for the Wiener filter has been removed from the Reference Manual.
  • The description of the camera poses has been improved. Now, for the pose parameters of frequently used operators the direction of the transformation is mentioned.
  • The reference manual entries of gen_image1, gen_image1_extern, gen_image1_rect, gen_image3, gen_image3_extern, and gen_image_interleaved now include a warning, stating that a crash may occur for invalid pointer values.
  • The reference manual entry of get_bar_code_result did not mention the quality grade '-1'. Furthermore, the reference manual entry of get_bar_code_object contained a misleading statement. These problems have been fixed.
  • The documentation of the parameter 'quality_isoiec15416_values' (get_bar_code_result) stated 'N/A' as value for 'Overall Quality', 'Overall Quality Linear' and 'Overall Quality Composite', although floating grades are returned. This problem has beed fixed.
  • The reference manual entries of get_contour_attrib_xld and get_contour_global_attrib_xld have been improved to better describe the set of possible contour parameters.
  • The operator reference of get_data_code_2d_results was inconsistent for the parameters 'mirrored' and 'structured_append'. This problem has been fixed.
  • The documentation of the operator get_object_model_3d_params has been improved. Now, the option 'extended_attribute_types' for extended parameters is documented.
  • The reference manual entry of get_support_vector_class_svm contained misleading phrases concerning the parameter 'IndexSupportVectors'. This problem has been fixed.
  • The reference manual entry of get_support_vector_class_svm falsely stated that an array was allowed as input for the parameter 'IndexSupportVector'. This problem has been fixed.
  • For the operator open_socket_accept the GenericParameter option 'reuseaddr' was not documented. This problem has been fixed.
  • The reference manual entry of send_data mentioned zeros instead of NULL-Bytes. This problem has been fixed.
  • The documentation of the operator set_bar_code_param was formulated over-simplified which led to a wrong description for the result value concerning the removal of the check character. This problem has been fixed.
  • The example snippet within the reference manual entry of set_fuzzy_measure transformed a function and then used the original function instead of the transformed one. This problem has been fixed.
  • The reference manual entry of vector_to_pose has been improved. In particular, it has been extended with references to the publications the implementations of the methods are based on.
  • The introduction of the chapter Camera Calibration / Multi-View has been extended with more detailed descriptions regarding the calibration process of different camera setups.
  • For several operators, the semantic type definitions have been specified more precisely.
  • The reference manual had several operators where the warning or attention block was missing. This problem has been fixed.

Release Documents

  • In the documentation, the 'Third-party Copyrights' now contain information about the version of the used third-party libraries.

Solution Guides

  • The Solution Guide on Image Acquisition still listed the OpenNI interface as supported interface although the support ended with HALCON 13.0. This problem has been fixed.
  • In the Solution Guide on 3D Vision the equation for the polynomial model of tilt lenses was erroneous. This problem has been fixed.

User Guides

  • Some example paths within the user manuals referred to %HALCONROOT% instead of %HALCONEXAMPLES%. This problem has been fixed.
  • Within the PDF version of the HDevelop User's Guide a link to the Programmer's Guide did not work. This problem has been fixed.
  • The HDevelop User's Guide falsely stated that within the Help Window PDFs could be opened in an external viewer using the Return key. This problem has been fixed.
  • Table 8.6 in the HDevelop User's Guide was numerated erroneous in the pdf-file. This problem has been fixed.

Installation

  • The deep learning classifiers have been moved from the main installer to the separate installer (Windows) / tarball (Linux) for deep learning. See the Installation Guide for more details.
  • Under Linux it is no longer necessary to manually install the cuBLAS and the cuDNN libraries. These are included in the Linux tarball for deep learning.
  • The link to the HALCON Uninstaller has been removed from the Windows Start Menu.

Licensing

  • On macOS systems without any HID devices attached, HALCON would crash during initialization.This problem has been fixed.
  • HALCON has been extended with an operator get_system_info that can be used to query a subset of the parameters supported by get_system without requiring a valid HALCON license. Note that this change affects the compatibility. Read more.

Miscellaneous

  • The semantic type of a background estimator as returned by tuple_sem_type has been changed from 'bg_esti' to 'bg_estimation'.
  • The HDevelop example hdevelop/3D-Object-Model/Segmentation/measure_plant.hdev has been added. With this example we demonstrate how you can segment and measure different parts of a plant.

Follow this link to read about the changes of previous HALCON versions.

Products/HALCON/Work with HALCON/Documentation