This document provides the release notes for MVTec HALCON 126.96.36.199 Steady, as released in December 2018.
Addendum to the Release Notes of HALCON 188.8.131.52 Steady
The originally released version of HALCON 184.108.40.206 Steady 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 substancial 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 220.127.116.11 Steady was
substituted by an updated version HALCON 18.104.22.168 Steady.
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: 22.214.171.124
(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.
Major New Features of HALCON 126.96.36.199 Steady
With HALCON 18.11 users are able to train their own classifier using CNNs (Convolutional Neural Networks) based on pretrained networks that are included in HALCON. These have been highly optimized for industrial applications and are based on hundreds of thousands of images. HALCON 18.11 offers a seamlessly integrated, comprehensive set of deep learning functions for
- classifying entire images
- object detection
- semantic segmentation.
Deep-learning-based image classification allows to easily assign images to trained classes. The low labeling effort enables particularly short set-up times, and applying the classifier to new data is especially fast.
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). Touching or partially overlapping objects are also separated, enabling object counting.
To maximize its potential in industrial environments, HALCON’s deep-learning-based image classification, semantic segmentation and object detection inference can all be performed on GPUs, as well as on x86 CPUs.
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.
HALCON’s bar code reader now features optimized edge detection, which improves the ability to reliably read bar codes with very small line widths as well as strongly blurred codes. Moreover, the quality of the bar codes is also verified in accordance with the most recent version of the ISO/IEC 15416 standard.
HALCON now features an improved automatic text reader, which now detects and separates touching characters more robustly.
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.
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 parameters associated with the handle and their current settings.
HDevelop provides a new library export that makes the use of HALCON procedures from C++ and .NET as easy and intuitive as calling any other C++/.NET function. This is possible via a wrapper that encapsulates the necessary HDevEngine API calls. This new library export also generates CMake projects which can easily be configured to output project files for many popular IDEs, such as Visual Studio. The new functionality is accessible from the HDevelop GUI and via command line interface.
HALCON now makes it much more comfortable to work with handles by clearing these automatically once they are no longer required. This significantly reduces the risk of creating memory leaks because you no longer have to manually release unused memory. This way, writing “safe code” is now much simpler.
HALCON now offers a new method that fuses multiple 3D point clouds into one watertight surface. This new method is able to combine data from different or even various 3D sensors, like a stereo camera, time of flight camera, or fringe projection. The data from these sensors get fused into one highly optimized 3D point cloud. This technology is especially useful for reverse engineering.
HALCON now offers optimized functions for surface-based 3D matching: These can be used to determine the position of objects in 3D space more reliably, making development of 3D applications easier. In addition, HALCON now also includes a new helper procedure that allows developers to quickly inspect and debug parameters and results of a surface-based matching application.
A new camera model within HALCON now allows the corrections of distortions in images that were recorded with hypercentric (also known as pericentric) camera lenses. These lenses can depict several sides of an object simultaneously, thus enabling a 360-degree view of the test object. With this technology, users only need a single camera system to inspect, for example, cylindrical objects.
HALCON 18.11 includes a new method for inspecting specular and partially specular reflecting surfaces to detect defects like dents or scratches which can hardly be identified using conventional surface inspection techniques. Deflectometry uses specular reflections by observing mirror images of known patterns and their deformations on the surface.
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.
HALCON now provides the new GigEVision2 interface which supports devices complying with the GigE Vision 2.x standard and replaces the old GigEVision interface. In particular, this new interface supports the transmission of chunk data and additional payload types including the multipart payload. In combination with a 3D sensor that supports the multipart payload type the GigEVision2 interface is now able to directly create an ObjectModel3D when using grab_data or grab_data_async.
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.
HALCON 188.8.131.52 Steady licenses are not compatible with previous HALCON versions. Please contact your local distributor.
Furthermore, please note the following compatibility issues related to licenses:
Compared to HALCON 13.0.2, many extensions have been introduced. Thus, the HALCON 184.108.40.206 Steady libraries are not binary compatible with HALCON 13.0.2 or earlier versions. However, HALCON 220.127.116.11 Steady is mostly source-code compatible to HALCON 13.0.2 except for the changes listed below:
- The operators calibrate_cameras, binocular_calibration, and the camera calibration in calibrate_hand_eye in rare cases might return slightly different optimized parameters and reprojection error. More information.
- The operator classify_class_gmm returns different values fo the k-sigma probability 'KSigmaProb' for Gaussian Mixture Models with covariance type 'spherical' or 'diag'. Since classify_image_class_gmm uses the k-sigma probability to reject pixels, the class regions returned by classify_image_class_gmm now might differ from those of previous HALCON versions. More information.
- The operators create_scaled_shape_model, create_aniso_shape_model, determine_shape_model_params, create_planar_uncalib_deformable_model, create_planar_calib_deformable_model, create_local_deformable_model, and determine_deformable_model_params for 'NumLevels'='auto' in rare cases might return a different number of pyramid levels when 'ScaleMin', 'ScaleRMin', or 'ScaleCMin' are set to a value < 0.7. In extremely rare cases, create_shape_model_3d might create a slightly different model. More information.
- create_sheet_of_light_model, set_sheet_of_light_param, and get_sheet_of_light_param have been extended by checks which verify whether the wanted parameters match the set 'calibration' in SheetOfLightModelID. In case they now return the error 3790 ("Parameter does not match the set 'calibration'"), please use set_sheet_of_light_param (SheetOfLightModelID, 'calibration', Calibration) to adapt the model accordingly. More information.
- The speedup of deviation_image might lead to results that differ by a gray value of 1 from the results in previous HALCON versions. More information.
- The results and the score of find_planar_calib_deformable_model, find_planar_uncalib_deformable_model, and find_local_deformable_model can vary slightly from previous results and scores. More information.
- The results and the score of find_planar_calib_deformable_model and find_planar_uncalib_deformable_model with the metric 'ignore_part_polarity' can vary slightly from previous results and scores. More information.
- The results and the score of find_planar_calib_deformable_model, find_planar_uncalib_deformable_model and find_local_deformable_model can vary slightly from previous results and scores. This does not only affect the SIMD implementations but also the C version. More information.
- For find_text, do_ocr_single_class_cnn, and do_ocr_multi_class_cnn the implementation of the CNN-based OCR classifier has been improved. This can lead to slightly different results in the achieved confidences. More information.
- gen_circle_sector, gen_ellipse_sector, create_drawing_object_circle_sector, and create_drawing_object_ellipse_sector might return slightly different results. More information.
- get_calib_data for ItemType set to 'camera' and DataName set to 'params_deviations' or 'params_covariances' sometimes returns different results. More information.
- The operator get_data_code_2d_results now returns error 8831 ("Unknown parameter name") if the candidate groups 'symbology_ident' and 'structured_append' are chosen for Micro QR Codes. More information.
- The HALCON language interfaces do not support a signature with an integer variation for the parameter 'Instance' in the operators get_metrology_object_result and get_metrology_object_result_contour anymore. Instead, the signatures with HTuple or string variations of the parameter can be used. More information.
- When using a text model of type 'manual', get_text_object erroneously returned the error 1301 ("Wrong value of control parameter 1"), when passing an unsupported string for the parameter 'ResultName'. Now, the error 1302 ("Wrong value of control parameter 2") is returned. The operator get_text_object also returned no error for text models of type 'manual', when multiple values for parameter 'ResultName' have been passed. Instead, only the first parameter value has been processed. Now, the error 1202 ("Wrong type of control parameter 2") is returned. More information.
- serialize_texture_inspection_model threw the error 3801 ("Texture inspection model is not trained") if an untrained or only partially trained texture inspection model was passed as input parameter. Now, serialize_texture_inspection_model can cope with untrained models and therefore no error is returned in these cases anymore. More information.
- set_bar_code_param now throws an exception, if 'element_size_min' and 'element_size_max' are inconsistent. More information.
- The parameter 'meas_param_estimation' of set_bar_code_param and get_bar_code_param has been removed. The default behavior has been improved to cover its use cases. More information.
- The parameters
of set_data_code_2d_param and get_data_code_2d_param have been removed. Use 'module_gap_min' instead of 'module_gap_col_min'. Furthermore, use 'module_gap_row_min' and 'module_gap_max' instead of 'module_col_max' and 'module_row_max'.
- 'module_gap_row_min', and
- set_stereo_model_image_pairs and reconstruct_surface_stereo might return slightly different results, in rare cases also significantly different results. In order to obtain the old behavior, before calling set_stereo_model_image_pairs, please call
set_stereo_model_param (StereoModelID, 'rectif_method', 'geometric').
- set_stereo_model_param returned the error 1303 ("Wrong value of control parameter 3"), if GenParamName was set to 'surface_tolerance' and GenParamValue exceeded the value of 'min_thickness' stored in StereoModelID. set_stereo_model_param now returns the error 9544 ("The minimum thickness is smaller than the surface tolerance").
- The following operators may produce different results for uint2 images when the SSE41 optimization is switched off by using set_system ('sse41_enable','false'): find_local_deformable_model, find_planar_calib_deformable_model, find_planar_uncalib_deformable_model, find_ncc_model, find_ncc_models, find_aniso_shape_model, find_aniso_shape_models, find_scaled_shape_model, find_scaled_shape_models, find_shape_model, and find_shape_models. More information.
- Note that the following undocumented but public functions for setting callbacks were removed. Applications must now use the new callback functionality within set_system instead.
- tuple_regexp_match, tuple_regexp_replace, tuple_regexp_select, and tuple_regexp_test now support empty matches. Regular expressions such as '.*' or '^$' now match on an empty string. To avoid empty matches, the regular expression has to be adapted, e.g., by using '.+' instead of '.*'. More information.
- Programs that relied on the exact output of tuple_sem_type or tuple_sem_type_elem need to be adjusted for specific semantic types, as they have been renamed to be consistent with the semantic types used by other operators. In particular,
- 'surface_result' is now 'surface_matching_result',
- 'surface_result_deformable' is now 'deformable_surface_matching_result',
- 'sheet_of_light' is now 'sheet_of_light_model', and
- 'dl_classifier_training_result' is now 'dl_classifier_train_result'.
- When on an Asian system a pretrained OCR classifier from a previous HALCON version is used and the HALCON encoding is set to UTF-8, the names of the special characters €, £, and ¥ are no longer mapped to the code page 1252 codes. In this scenario the new pretrained classifier should be used and the class names should be compared to the expected real character name '€', '£', or '¥' . More information.
- The procedure plot_dl_classifier_training_progress now uses epochs instead of iterations. Therefore, you have to pass the parameters 'Epochs' and 'NumEpochs' instead of 'Iterations' and 'NumTotalIterations'. More information.
- The barcode reader could result in different decoding results compared to prior HALCON versions. More information.
- The procedures in the procedure library procedures/general/hand_eye.hdpl have been adapted to use the new container data type 'dictionary' instead of messages. More information.
- The feature cache macros of the internal region structure where removed from the HMacro.h header file because user code should not access the feature cache directly.
Please re-compile all C, C++, or .NET programs developed with HALCON 13.0.2. The incompatibility with HALCON 13.0.2 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.104.22.168 Steady, HALCON 13.0.2 and HALCON 13.0.x image acquisition interfaces are library compatible.
Please note also the following compatibility issues related to image acquisition interfaces:
- The MVTec GigE Vision Streaming Filter version 22.214.171.124 that is part of the Windows version of the new GigEVision2 interface is only compatible with revision 13.0.3 and higher of the old GigEVision interface. If both, GigEVision2 and GigEVision, interfaces should be used on the same PC you need to make sure to update to this GigEVision revision to ensure compatibility.
- Image acquisition and digital I/O interfaces listed in the reference documentation of open_framegrabber and open_io_device will return the error code H_ERR_COMPONENT_NOT_INSTALLED instead of H_ERR_DLOPEN when loading of the interfaces fails. More information.
HALCON 126.96.36.199 Steady includes only a subset of available image acquisition interfaces. The following interfaces are no longer included in the installation, but can still be downloaded from our web server and installed manually: ABS, Andor, DahengCAM, Ginga++, heliCamC3, LPS36, LuCam, MatrixVisionAcquire, Opteon, PixeLINK, Sentech, ShapeDrive, SICK-ScanningRuler, Slink, TWAIN, and VRmUsbCam.
Digital I/O Interfaces
In general, HALCON 188.8.131.52 Steady, HALCON 13.0.2 and HALCON 13.0.x digital I/O interfaces are library compatible.
HALCON 184.108.40.206 Steady includes only a subset of available digital I/O interfaces. The following interfaces are no longer included in the installation, but can still be downloaded from our web server and installed manually: ADLINK-DAQPilot, ADLINK-EOS, Advantech, Contec, Interface, NIDAQmx, and OPC_Classic.
Please re-generate your own extension packages developed with HALCON 13.0.2.
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
- Applications that store handles as numeric values (Hlong) do not work reliably with the new handle mechanism since these "raw" references are not tracked by reference counting and the handle may get destroyed while still in use. Setting the system parameter 'legacy_handle_mode' to 'true' keeps all handles alive until destroyed explicitly and also allows to pass handles as numeric input values to HALCON operators as in previous HALCON versions. Furthermore, there are API extensions due to the new type and some old API members no longer serve any function with the new handle mechanism. This introduces potential source code incompatibilities which can be prevented by compiling with the preprocessor define HCPP_LEGACY_HANDLE_API. Finally, the new reference mechanism cannot unambiguously represent all legacy ownership states. This concerns scenarios where an application managed multiple instances of OOP classes referencing the same handle (via copying or rewrapping of the handle, typically involving explicit 'Detach' and/or 'InvalidateHandle'). In such cases legacy code may need to be adapted to the new mechanism. More information.
- Due to the introduction of the new HTuple element type HHandle some casts that were allowed previously may become ambiguous. In particular, converting a handle from procedural code to a tool class as in new HShapeModel(tuple) now requires to disambiguate the desired constructor with tuple.H (when using new handles) or tuple.IP (when using legacy mode). More information.
- By converting strings consequently into the current locale the behavior of the program may slightly change and unexpected errors may occur, when characters are used in an HDevelop script that are not supported by the current locale. For instance, when using Japanese file names on a Western system with Latin-1 encoding, the file names were scrambled strings but valid Latin-1 byte sequences. Now the Japanese characters in the file names are replaced by '?' which cannot be used within a path. In addition, different Japanese strings can be re-encoded to the same Latin-1 strings when different Japanese characters are all replaced by '?', this may raise errors when these names are used as class names for a classifier. More information.
- Due to a change of the type of the Grayval parameter of the operator get_grayval, the HALCON/C interface does not provide the native type signature variant of this operator anymore, but only the tuple variant. Due to this change, the types of the passed parameters have to be changed to type HTuple and the function call has to be changed to T_get_grayval, respectively. More information.
- The previous parameter 'cmake_cpp' for the command line option '-export_type' has been renamed to 'cmake'. To specify the target language, now the additional option '-language' is available which accepts the values 'cpp' and 'cs'. More information.
- HalconDotNet.HMouseEventArgsWPF.Button is now nullable type, that means it can take null as value. More 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.
- The protection format for HDevelop files has been changed to improve security. Files with the new protection cannot be used with unpatched HALCON versions published before May 2018. If you need to open these files with older HALCON versions, please update these versions using the patches available for download from our webserver https://www.mvtec.com/download/halcon/. More information.
- By introducing the new handle type, the ownership of the handle resources passes from the user to HALCON. This might lead in conventional programming languages like C, C++ classes, or .NET to undefined behavior and crashes when HALCON handles were not held in HALCON data structures like tuples or handle classes, as HALCON will free the handle resources automatically when the last HALCON structure holding a handle reference is destroyed. For these cases, HALCON offers a legacy mode to transfer the ownership of handles to the user code, i.e., handles have to be cleared explicitly again in this mode. Note that HDevelop does not support the legacy mode. The mode can be switched via the 'legacy_handle_mode' parameter of the operator set_system. But the more proper code adaption in case of this problem is to use HALCON data types instead, like HTuple or the specific semantic handle classes. This allows to keep the ownership on behalf of HALCON and to profit of the new HALCON handle resource guarding. The legacy operators clear_all_* that clear all created handles of a specific semantic type are no longer functional and will be removed in future HALCON versions. C++ classes of former HALCON versions used a local reference counting mechanism to support a shallow copy constructor. This behavior is not fully representable by the new handle mechanism, but generally, code that did not use 'Detach' or 'InvalidateHandle' is not concerned. HALCON/C operators with long type signatures for handles run in legacy mode only. For proper use of these operators, please use the tuple type signature instead. HALCON/COM (legacy) only runs in legacy handle mode. HDevEngine applications that provide custom implementations for dev_* operators must take care when storing window handles to keep their ownership separate from the caller: Handles must be stored and returned as independent copies of HTuple or HHandle instances, not as references to existing instances or as numeric values like Hlong or IntPtr. HDevEngine/.NET applications that use stock implementations HDevFixedWindowImplementation and HDevMultiWindowImplementation are not affected. The signature of the drawing object callback type changed to Herror (stdcall *)(Hphandle,Hphandle,char*). Following error codes are inoperable and have been removed: H_ERR_SOL_INVALID_HANDLE, H_ERR_WFID, H_ERR_WSID, H_ERR_FGWH, H_ERR_IOWH, H_ERR_BC_INVALID_HANDLE, H_ERR_BAR_UNKNOWN, H_ERR_WSKEY, H_ERR_WSKEYH_ERR_WSKEY, H_ERR_INVALID_TEXT_RESULT_ID, H_ERR_METROLOGY_MODEL_INVALID. Minor API differences may prevent source code from compiling out of the box in exceptional cases. Please refer to the Programmer's Guide and the new technical note "Technical Updates" to resolve occurring problems. More information.
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:
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.
- True latin-1 characters (ISO88591) work as before because the Unicode codes of these characters are the same as their latin-1-ANSI codes.
- 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.
- 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).
- 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 transfered 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:
- The following operators became legacy:
The operators dev_open_tool and dev_close_tool can be used instead.
- 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.
The HALCON/COM interface, including the possibility to develop with Delphi, is no longer available.
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.