This document provides the release notes for MVTec HALCON 10.0.2, as released in November 2011. HALCON 10.0.2 is primarily a maintenance release that fixes all known bugs in HALCON 10.0.1; besides, it provides added functionality.



Overview

This document contains the following information:

Compatibility
Detailed Description of Changes in HALCON 10.0.2
Advance Notice
Known Issues
Major New Features of HALCON 10.0.1
Detailed Description of Changes in HALCON 10.0.1
Major New Features of HALCON 10.0
Detailed Description of Changes in HALCON 10.0


Compatibility

o Licenses

HALCON 10.0 licenses are also valid for HALCON 10.0.2. In contrast, all HALCON 9.0 licenses must be replaced or upgraded. Please contact your local distributor.


o HALCON Library

HALCON 10.0.2 is fully compatible with HALCON 10 except for the changed behavior of some operators due to bug fixes. Compared to HALCON 9.0, many extensions have been introduced. Thus, the HALCON 10.0.2 libraries are not compatible with HALCON 9.0 or earlier versions.


o HALCON Applications

Applications (i.e., executables) developed with HALCON 10.0 or HALCON 10.0.1 can be used with HALCON 10.0.2, i.e., HALCON 10.0.2 is binary compatible with HALCON 10.0 and HALCON 10.0.1.

The incompatibility with HALCON 9.0 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 and for HALCON 10.0 and HALCON 10.0.1, respectively.

Please note the following incompatibilities with respect to previous HALCON 10.0.x releases:

Please note that applications using HALCON/.NET (and HDevEngine/.NET) have local copies of the corresponding assemblies (halcondotnet.dll etc.). After installing HALCON 10.0.2, these applications would therefore use the old version of the HALCON/.NET interface together with the new version of the HALCON library. In order to benefit from the bug fixes in the HALCON/.NET interface as well, you must either replace the assemblies manually or re-compile the projects. If you do not recompile the application, you need to add an application configuration file mapping the application's expected assembly version to the new version. See the Programmer's Guide for more information.


o Image Acquisition Interfaces

The system requirements of the following image acquisition interfaces have been changed since HALCON 10.0.1:

  • For using the updated 1394IIDC-2 interface you must install the new version 2.1.2 of the system library libdc1394 and the new Linux kernel modules firewire-ohci and firewire-core.
  • For using the updated LuCam interface you must install the LuCam SDK version 6.1.
  • For using the updated MultiCam interface you must install the new MultiCam driver version 6.7.
  • For using the updated Opteon interface you must install the v4.0 of the Opteon software distribution.
  • For using the updated SaperaLT interface you must install the Sapera LT library version 7.0 (or higher).
  • For using the updated SICK-3DCamera interface you must install the new SICK icon API 4.3.

If you have developed your own acquisition interfaces with HALCON 10.0 or HALCON 10.0.1, you can use them with HALCON 10.0.2 without further action.


o Extension Packages

Extension packages developed with HALCON 10.0 or HALCON 10.0.1 can be used with HALCON 10.0.2 without further action. Extension packages developed with HALCON 9.0.x must be re-generated.


o ActivVisionTools
  • If you have been using ActivVisionTools 3.2, please contact your distributor for further information on how to run this version together with HALCON 10.0.2.
  • ActivVisionTools 1.0 to 3.1 cannot be used with HALCON 10.0.2. If the setup program detects such an ActivVisionTools version, it warns you that by continuing to install HALCON 10.0.2 you will disable your ActivVisionTools installation.

    If you still want to use your ActivVisionTools installation you must also keep your old HALCON installation and switch back to it as described in the Installation Guide.



Detailed Description of Changes in HALCON 10.0.2

Detailed release notes can be obtained for the following topics:

HDevelop
HALCON Library
Procedures
HDevEngine
Image Acquisition Interfaces
Manuals
Miscellaneous

HDevelop

Functionality
Bug Fixes
Examples

o Functionality:
  • The following GUI elements that display an operator or procedure name now have a detailed tool tip displaying the signature, the short description, and, if available, the warning text.
    • Operator window: the items of the operator selection combo box.
    • Program window: the procedure selection combo box, its items, and the tab card titles.
    • Call stack: the listed procedures.
    Additionally, in the Operator window now the short description of the selected operator is displayed.
  • If a new external procedure is created via the Procedure Interface dialog, the dialog now remembers the directory that was used to write the last procedure. This directory is proposed the next time a procedure is created.
  • In the Create Procedure dialog the names of the parameter selection schemes were misleading and not consistently used. The names 'Only In' and 'Only Out' did not reflect which parameters were actually suggested for the procedure's interface. The meaning of 'Only In' was that only those parameters were suggested as input parameters of the procedure that were first used as an input parameter, i.e., that were not set within the procedure before their first usage as operator input. According to this behavior, the label 'Only In' was renamed into 'First In'. The meaning of 'Only Out' in conjunction with 'Only In' was that only those parameters were suggested as output parameters of the procedure that were not used as operator input after their last modification within the selected program line from which the procedure was going to be created. For 'Only Out' in conjunction with 'All In' the behavior was different: Here, only those parameters were suggested as output parameters that were not used as input parameters at all. Now, in both 'Only Out' cases, the same behavior is applied. In particular, a variable is suggested as output parameter if it is calculated as the output parameter at its last occurrence within the selected program lines. According to this behavior, the label 'Only Out' was renamed into 'Last Out'.
  • HDevelop now allows to disable the usage of the mouse wheel in the Graphics window as well as the tool tip that shows the pixel position by pressing the Ctrl-key. This is sensible if some user interactions within the Graphics window are implemented in an HDevelop procedure, e.g., for modifying the view on a 3D object. The mouse wheel and the tool tip can be disabled and enabled via the operator dev_set_preferences and the current state can be requested via dev_get_preferences. The generic parameter names are 'graphics_window_mouse_wheel' and 'graphics_window_tool_tip', respectively. The values can be set to 'true' or 'false'. Additionally, the behavior can be controlled via the Runtime Settings tab card on the Preferences dialog.
  • In the Auto mode of the Variable window the practice for selecting the shown variables differed. In particular, the practice for the first and the last line of the procedure differed from that for the rest of the procedure. In general, all variables are displayed that are used by the currently executed program line, i.e., the one with the program counter, and the program line that was executed most recently. However, if the program counter was on the first or on the last procedure line, all variables were displayed. This was confusing and therefore has been changed. The special treatment of setting the program to the first or last program line was removed.

o Bug Fixes:
  • If HDevelop Demo (64-bit) was started on a Windows desktop with 16 bit color depth, all text elements were unreadable because all characters were displayed as a dark rectangle. This problem has been fixed.
  • HDevelop and HDevEngine could have crashed on the built-in string conversion operator $ if it was applied on a multi-value tuple. This problem has been fixed.
  • HDevelop could have crashed if a user interaction like opening a program was performed while the operator read_string was executed and waited for character input. In contrast to other operators that request a user interaction, the operator read_string did not block other user interactions with the GUI. This problem has been fixed.
  • Changing the indentation of a text block using the Shift+Tab keys may have led to wrong indention of the text line following the originally selected text. This problem has been fixed.
  • While editing a block statement in one loop, sometimes the program counter jumped unintentionally into another loop. Additionally, it could have happened that the program counter remained at an invalid block statement, e.g., after removing the block end statement. These problems have been fixed.
  • If the first executable operator of a program is a for statement, it could have happened that resetting the program (e.g., by pressing F2) did not reset the for loop. This happened if the for statement was the next statement that had to be executed while the program reset was performed, independently on whether the program was running or whether it has been stopped. This problem has been fixed.
  • After entering the operator info_framegrabber into the Operator window and selecting an available interface, wrong suggestions for the parameter 'Query' were made. This problem has been fixed.
  • When handling very big numbers beyond INT_MAX, various HDevelop operations returned different values than the corresponding HALCON tuple operators. The following operations, listed together with the corresponding HALCON operators, were affected: This problem has been fixed.
  • In some rare cases it could have happened that the line numbers in the full text editor were not synchronous to the code lines. This could have happened if a procedure had been scrolled down and later this procedure was entered during single-step execution. This problem has been fixed.
  • There have been some problems with the auto completion functionality within the full text editor for the for operator:
    • If a variable already existed, pressing TAB behind the variable name did not continue the text completion, even if the selection box was already visible and the entered variable name was one of the suggestions: for Index<TAB>
    • If the for statement ended with a wrong character where the keyword 'to' or 'by' would be expected, the auto completion inserted the wrong strings ' To' or ' By', respectively, without removing the wrong text fragments. Especially, 'for Index := 1 t<TAB>' was not replaced by 'for Index := 1 to' but by 'for Index := 1 t To'.
    These problems have been fixed.
  • If on an Asian Windows system the keyboard input mode was set to a 2 byte character language area, the HDevelop program could have been executed unintentionally up to the current program line while entering characters via the full text editor. If the Return key mode was set to 'Enter and execute', this happened with every character key that was pressed without the Shift modifier. If the execution mode was switched off, the program was executed if the Shift modifier was pressed together with an arbitrary character key. This problem has been fixed.
  • In order to store HDevelop programs and procedures with non-ASCII characters compatible to old HALCON versions prior to HALCON 8.0, HDevelop allows to save programs and procedures with the native encoding instead of UTF-8. This option can be selected via the General Options tab card on the Preferences dialog. However, non-ASCII characters that had been entered within the full text editor became corrupted while reloading such a program or procedure in HDevelop. This problem has been fixed.
  • HDevelop crashed if within the Operator window an operator with output variables that were not yet procedure variables was applied via the Apply button and afterwards in the Variable window a cleanup has been performed, so that the variables that were created by the operator application have been instantly removed. If then again the Apply button was pressed or if the operator was about to be entered into the program by pressing the Enter or the Ok button, HDevelop crashed. This problem has been fixed.
  • Entering an operator name into the combo box of the Operator window and then, without pressing Enter, clicking with the left mouse button into the parameter area of the Operator window could have crashed HDevelop. This happened if the entered operator name was one of the current items of the combo box while another operator of the combo box list was displayed in the Operator window. This problem has been fixed.
  • If within the Edit Procedure Interface dialog the interface of a procedure was changed and, without pressing the Apply button, another procedure was selected, the user was correctly asked to confirm or to discard the changes. However, pressing the Save button resulted in an error message complaining that the procedure could not be saved under the selected name. Instead of using the original name, HDevelop tried to save the procedure under the most recently selected name. Additionally, pressing the Cancel button failed because it did not reset the Procedure Name combo box to the old name. These problems have been fixed.
  • If within the Edit Procedure Interface dialog the user tried to select another procedure via the Procedure Name combo box, it could have happened that a warning was displayed that the previously selected procedure was changed although the interface was not modified. This happened if the procedure had control parameters for which in a previous session on the Parameter Documentation tab card the type of the parameter was set to real, a minimum or maximum value was specified, and if in the meantime the system-wide floating point precision was changed via the Preferences dialog. This problem has been fixed.
  • HDevelop crashed if a procedure was created from the selected program lines while a Variable Inspect window was open and the inspected control variable disappeared from the procedure by automatically replacing the selected program lines with the new procedure call. This problem has been fixed.
  • There were some actions that did not work on the last line of a procedure, e.g.:
    • showing the help page for the operator in the last line by pressing F1,
    • loading the operator into the Operator window via the shortcut Ctrl-Shift-Space, or
    • setting the program counter and the insert cursor via the shortcuts Ctrl-, and Ctrl-., respectively.
    These problems have been fixed.
  • HDevelop crashed if an empty program file in the hdev format was loaded or if an empty procedure file with the extension hdvp was placed within a directory that was reachable via the external procedure paths. This problem has been fixed.
  • If a protected procedure was loaded into the full text editor, pasting arbitrary text into the Program window could have crashed HDevelop. This problem has been fixed.
  • HDevelop did not reset the state of the whole program protection on creation or loading of a new program and erroneously locked all newly created procedures with unknown passwords. This problem has been fixed.
  • The program protection was not correctly reset. If the main procedure was protected and afterwards a program that contains unprotected local procedures was loaded, these local procedures were locked. When this program was saved, even the main procedure was locked. This problem has been fixed.
  • Removing all elements of a tuple via the Variable Inspect dialog could have crashed HDevelop. This problem has been fixed.
  • In the Variable Inspect window, the functionality for removing elements from the tuple by entering an empty tuple [] as the current element value was broken: instead of removing the edited element it has been replaced by the string '[]'. This problem has been fixed.
  • In the Variable Inspect window, strings that are wider than the column width are automatically wrapped at the column border and marked by a line continuation character '>>'. If such a string was copied to the clipboard by selecting one or several cells of the table and pressing Ctrl+C, the line continuation characters followed by an additional space character were inserted into the copied string. This problem has been fixed.
  • If a tuple contains many big integer values, the mean value that is displayed in the tool tip of the Variable window, the status bar, and the statistic area of the Variable Inspection table could have been wrong. In the latter case, also the sum was wrong. This problem has been fixed.
  • There were some problems while editing region parameters within the ROI inspect window:
    • In some styles (e.g., Windows) the lower part of the spin boxes within the ROI shape table were truncated.
    • The maximum value of the spin boxes of the ROI shape table was 1e6. This became a problem if after drawing a region a smaller unit was selected, e.g., micrometer after meter.
    • The decimal was set to 2. This became a problem if small values had to be changed.
    These problems have been fixed.
  • HDevelop could have crashed if an XLD contour array of which the first contour had a point at DBL_MAX was assigned to an iconic variable. This problem has been fixed.
  • Under Windows it was for some operators with a file name parameter not possible to select a read-only file in the File dialog that is opened via the Operator window or the parameter selection box in the full text editor. That is, it was not possible to select a file name interactively, even if the operator only tried to read the file. The following operators were affected: Additionally, the labels in the File dialog suggested that the file is saved. These problems have been fixed.
  • HDevelop raised the result view for a Find All operation in the Find-/ Replace Dialog only on the first usage. That is, if, e.g., after the first use of the result view another window was opened that covered the window of the result view, the result view was still covered by this window even if another Find All operation was applied. This problem has been fixed.
  • HDevelop may have crashed when showing the gray histogram of an image with a large range of gray values. This problem has been fixed.
  • HDevelop's gray histogram tool sometimes showed a HALCON low-level error message. This problem has been fixed.
  • HDevelop's gray histogram tool used all image channels for the scale operation instead of the selected channel. This problem has been fixed.
  • HDevelop's gray histogram tool sometimes limited the selectable upper range to a value lower than the maximum gray level in the image. This problem has been fixed.
  • HDevelop's gray histogram tool sometimes did not correctly handle the displayed range of the plot area in horizontal mode 'increasing' when displaying new images. This problem has been fixed.
  • If a new shape model was created and saved via the Matching Assistant and if on the Code Generation tab card of the assistant the option to load this model in the generated code was selected, there were some code lines missing in the code that was generated by the Matching assistant:
    • If the option to generate code for displaying the detected model in the search image was selected, the program line for receiving the model contour with the help of the operator get_shape_model_contours was not generated so that the model contour could not be transformed into the detected position.
    • If a timeout was set, the code line for setting the timeout with the operator set_shape_model_param was not generated.
    These problems have been fixed.
  • In the Matching Assistant the ROIs for the modification of the model image were not deleted as expected. If an ROI was deleted via the Graphics window, the ROI was still in the list of ROIs, even if no region was contained in the ROI any longer. Since a modification ROI has only one Region, the ROI should have been deleted when the Region was deleted. This problem has been fixed.
  • In the Matching Assistant the changing of the image file name via the line edit was not handled correctly. The following problems could have occured:
    • If the Image Acquisition Assistant radio button was checked, entering a file name into the line edit was completely ignored.
    • If the Image File radio button was already checked, the image file was loaded and the model was recalculated. However, the internal representation was not correctly adapted: The according code line in the generated code did not contain the file name from the line edit area. Instead of that, the file name that had at last been selected via the Open File dialog was printed. If no file had been selected via the dialog until than, the file name was empty. Additionally, if a file name was selected via the Open File dialog and if the image was changed manually via the line edit area, re-selecting the first file name again via the File dialog had no effect.
    These problems have been fixed. For the first case, now the file is loaded and the source is changed to Image File as it happens when a file is selected via the Open File dialog.
  • In the Image Acquisition Assistant changing a parameter on the Connection tab could have caused a crash if live acquisition was active. This problem has been fixed.
  • In the Calibration Assistant the generated code concerning the image acquisition sometimes was wrong. In particular, if the Image Acquisition Assistant was opened before the Calibration Assistant, if it was used as the image source, and if on the Code Generation tab card the Initialize Acquisition check box was checked, not the open_framegrabber command was inserted into the program as intended but only a comment with a warning. Additionally, if the Image Acquisition Assistant was opened after the Calibration Assistant, the open_framegrabber command was generated correctly, but no corresponding close_framegrabber command was generated. These problems have been fixed.
  • In the Calibration Assistant it was possible that floating point parameters could no longer be changed in some situations, especially after using the up and down arrows to modify the value. This problem has been fixed.
  • The Min. Edge Amplitude threshold of the Measure Assistant had the following dispensable restrictions:
    • Depending on the range and type of the image, the minimum value could not be set smaller than 1 or 0.01, especially, it was not possible to set a minimum amplitude of 0.
    • Depending on the range and type of the image, there were no or only two decimal places, even if the range of the image was very small.
    These problems have been fixed.
  • HDevelop exported deactivated special comments incorrectly if the special comments were meant to be exported at the beginning or end of the file or before or after a procedure. In those cases, the deactivated special comments were not comments in the exported code. This problem has been fixed.
  • HDevelop exported special comments always with UTF-8 encoding, even if native encoding was selected in the export dialog. This problem has been fixed.
  • HDevelop sometimes crashed on a system with a multibyte language when trying to export special comments containing non-ASCII characters. This problem has been fixed.
  • HDevelop exported the bit operation functions band, bor, and bxor incorrectly to C#. This problem has been fixed.
  • HDevelop exported the [] operation incorrectly to C++ if it was used to access an array element and the index was out of range. In that case, an exception should have occurred in the exported code, corresponding to the behavior in HDevelop. This problem has been fixed.

o Examples:

HALCON has been extended by the following HDevelop example programs:

  • The new HDevelop example programs openni_2cameras.hdev, openni_create_camera_calibration.hdev, openni_parameters.hdev, openni_simple.hdev, and openni_surface_based_3d_matching.hdev in the directory examples/hdevelop/Image/Acquisition show how to use the new OpenNI interface that supports the easy acquisition of 3D depth images from OpenNI compliant 3D sensors like the popular Microsoft Kinect and the ASUS Xtion PRO.
  • The new HDevelop example program ueye_timestamp.hdev in the directory examples/hdevelop/Image/Acquisition shows how to use the newly supported time stamp functionality for the uEye interface.

The following HDevelop example programs have been modified:

  • The following HDevelop examples have been generally revised:
    • examples/hdevelop/Filters/Texture/texture_laws_mlp.hdev
    • examples/hdevelop/Applications/Measuring-2D/check_fish_stick_dimension.hdev
    • examples/hdevelop/Image/Acquisition/file.hdev
    • examples/hdevelop/Image/Acquisition/file_directory.hdev
    • examples/hdevelop/Image/Acquisition/file_sequence.hdev
  • The HDevelop example program examples/hdevelop/Applications/Measuring-3D/calibrate_sheet_of_light.hdev might have delivered erroneous values for the pose LightPlanePose if the laser line provided for the calibration of the pose of the light plane was shifted with regards to the left image border. Additionally, the pose MovementPose was not computed in the world coordinate system and was therefore erroneous. As a consequence of both problems, erroneous values were also used in the HDevelop example program reconstruct_connection_rod_calib.hdev. These problems have been fixed.

The following HDevelop example programs have been removed from the file set or replaced by new HDevelop example programs:

  • The HDevelop example program assign.hdev existed twice in the file set. The version in the subdirectory examples/hdevelop/Control and the version in the subdirectory examples/hdevelop/Manuals/HDevelop were identical except for the short description displayed in the Browse Examples dialog. To avoid confusion, the redundancy has been eliminated. In particular, the version in the subdirectory examples/hdevelop/Manuals/HDevelop has been removed from the file set.
  • For the revision of the Solution Guide on Image Acquisition, the following new HDevelop example programs in the directory examples/solution_guide/image_acquisition replace the corresponding old programs, which are not part of the file set anymore:
    • first_example_acquisition_saperalt.hdev replaces first_example_acquisition_falcon.hdev,
    • info_framegrabber__1394iidc.hdev replaces info_framegrabber_falcon.hdev,
    • multiple_boards_bitflow.hdev replaces multiple_boards_px.hdev,
    • multiple_ports_bitflow.hdev replaces multiple_ports_px.hdev,
    • port_switching_bitflow.hdev replaces port_switching_inspecta.hdev,
    • real_time_grabbing_bitflow.hdev replaces real_time_grabbing_falcon.hdev,
    • simultaneous_grabbing_bitflow.hdev replaces simultaneous_grabbing_inspecta.hdev, and
    • volatile_grabbing_bitflow.hdev replaces volatile_grabbing_falcon.hdev.

HALCON Library

Modified Operators
Bug Fixes

o Modified Operators:
  • linear_trans_color has been extended to support an arbitrary number of output channels. The number of output channels is inferred from the transformation itself, i.e., if n is the number of channels of the input image and m is the desired number of channels of the output image, the transformation must be a matrix of size m×(n+1), which is stored as a tuple of length m*(n+1). Additionally, the support of compute devices has been extended to handle up to 9 input and 3 output channels.

o Bug Fixes:
  • Some operators may have crashed with undefined input objects. This behavior was not deterministic as sometimes the correct error code 4056 ("Image data management: object-ID is NULL (0)") was returned. As undefined input objects are only possible in HALCON/C and in HALCON/.NET, only projects using these interfaces were affected. This problem has been fixed.
  • HALCON did not handle untrained SVM classifiers correctly. If an untrained SVM classifier was used, no error message was returned, which led to inconsistent memory. This problem has been fixed. Now, the error 3392 ("SVM not trained") is returned.
  • If HDevelop demo is started without the environment variable HALCONROOT being set, HALCONROOT is determined automatically from the path of the demo version executable if the executable lays in a subdirectory /bin/HALCONARCH. This did not work for UNIX systems where the executable erroneously was searched in /lib/HALCONARCH instead. This problem has been fixed. Now, hdevelop_demo can be run on all systems without HALCONROOT being set.
  • HALCON did not check if an OpenCL kernel is supported on the selected compute device prior to attempting to compile it. This problem has been fixed.
  • The bar code reader may have needed much memory, especially for large images and when many candidate regions have been found. This problem has been fixed.
  • The training mode of the bar code reader did not return the ideal minimum element size 'element_size_min' which would be the maximum of all minimum element sizes for which a bar code could be decoded. Although the returned value allowed the reading of the bar codes, the performance might not have been ideal. This problem has been fixed.
  • Some operators having multiple input image parameters and at least one output image parameter crashed when an empty object was passed to another than the first input image parameter. These operators were: This problem has been fixed.
  • clear_lexicon hung if more than two lexicons were used at the same time and the sequence of calls to clear_lexicon was not inverse to the sequence of calls to create_lexicon (last in first out principle). This problem has been fixed.
  • The handles for 3D object models were assigned in increasing order without re-using handles that were cleared with clear_object_model_3d. This led to undefined behavior after 2^31 handles were created on 32-bit systems or 2^63 handles were created on 64-bit systems. This problem has been fixed.
  • connection returned incorrect results or crashed for complemented regions if the system parameter 'clip_region' was set to 'false'. This problem has been fixed.
  • convol_image crashed if an empty tuple was passed as filter mask. Additionally, convol_image returned the error 8111 ("convol: inconsistent number of weights") in very rare cases if parallelized on internal data level. Furthermore, convol_image returned the error 3513 ("number of chords too big for num_max") if the number of zeros ('0') contained in the mask was larger than twice the height of the image. These problems have been fixed.
  • create_class_gmm did not check the consistency of the values given in NumCenters. If more than one value is given, for each pair of successive values the first value must not be larger than the second one. Incorrect settings for NumCenters, e.g., [5,2], may have led to unexpected results or a crash of the operator train_class_gmm. This problem has been fixed. Now, the error 1303 ("Wrong value of control parameter: 3") is returned.
  • The automatic contrast estimation within the shape-based matching, the component-based matching, and the deformable matching sometimes returned slightly wrong values. This applied to the following operators: This problem has been fixed.
  • If a stereo model was created by create_stereo_model with 'Model'='surface_pairwise' and then it was used with reconstruct_points_stereo or if it was created with 'Model'='points_3d' and used with reconstruct_surface_stereo, the resulting behavior was undefined. This problem has been fixed. Now, the method of the model is checked in both operators and the error 8490 ("Property or operation not supported for current stereo model type") is returned in case of a mismatching method.
  • create_uncalib_descriptor_model, when applied with DetectorType='lepetit', expected and accepted the values 'on' and 'off' for the descriptor parameter 'subpix'. This behavior deviated from the behavior of the original operator points_lepetit, which expects and accepts the values 'interpolation' and 'none' instead. This problem has been fixed. Now, create_uncalib_descriptor_model accepts the correct values. For backwards compatibility, the old values are accepted, too. The reference manual entry of create_uncalib_descriptor_model has been adapted accordingly. Additionally, for the parameter 'max_scale' values greater than 3.5 were not accepted, which was different to the description in the reference manual. This problem has been fixed, too. The reference manual now reflects the existing limitation.
  • crop_contours_xld sometimes returned additional and unnecessary contours with a length of zero. This problem has been fixed.
  • derivate_gauss may have returned invalid values (NaN) for pixels outside of the domain of definition if the SSE2 implementation was used. This problem has been fixed.
  • deviation_image might have returned the error 6002 ("Memory partition on heap has been overwritten") if an empty region was used. This problem has been fixed.
  • difference_closed_contours_xld, intersection_closed_contours_xld, symm_difference_closed_contours_xld, and union2_closed_contours_xld crashed if contours with a very large number of points (e.g., 500000) were used. This problem has been fixed.
  • Applying a display operator (disp_*) immediately after opening a window sometimes failed on Linux/UNIX. This problem has been fixed.
  • disp_xld displayed incorrect contours in zoomed windows on Linux/UNIX. disp_obj and dev_display were affected as well. This problem has been fixed.
  • find_bar_code could have failed to decode the bar code symbol in very rare cases when looking for bar codes in an image with reduced domain. This could have happened particularly if the operator generated scanlines partially outside the domain and there were edges detected in the full image. This problem has been fixed.
  • In very rare cases the ECC 200 data code reader could have crashed when calling find_data_code_2d. Additionally, in some rare cases, calling find_data_code_2d with an ECC 200 data code reader needed a very long period of time, even on a search image that was not very big. This could have happened if the model parameter 'module_grid' was set to 'variable' or 'any'. The latter is chosen automatically if the 'default_parameters' are set to 'enhanced_recognition' or 'maximum_recognition'. In that case, the timeout parameter of the data code reader was ignored. These problems have been fixed.
  • find_local_deformable_model could have been applied with a model that was created with create_planar_uncalib_deformable_model, i.e., a planar deformable model instead of a local deformable model. This led to an unpredictable behavior. This problem has been fixed. Now, in such a case a warning is displayed saying that the wrong model version is used. For local deformable matching, the model must be created with create_local_deformable_model or create_local_deformable_model_xld. A model created with create_planar_uncalib_deformable_model is not accepted anymore.
  • find_marks_and_pose returned the error 8404 ("Minimum threshold while searching for ellipses") instead of error 8431 ("Orientation of calibration plate could not be determined") if the orientation of the calibration plate could not be determined. Additionally, it returned wrong initial poses for telecentric cameras. In particular, the rotation around the z-axis was computed incorrectly. These problems have been fixed.
  • find_planar_calib_deformable_model and find_shape_model_3d did not handle polynomial distortion parameters correctly. In particular, the resulting poses were wrong if camera parameters were used that model the radial distortions based on the polynomial distortion model. This problem has been fixed.
  • find_*shape_models sometimes crashed or returned the error 6041 ("No memory block allocated at last") when executed in parallel mode with at least two threads, at least two models were passed in ModelIDs, and a tuple with the same length as ModelIDs was passed in MaxOverlap. Additionally, find_*shape_model(s) in rare cases returned different results when called multiple times. This problem occurred only if the parameter SubPixel was set to 'least_squares_high' or to 'least_squares_very_high'. Furthermore, find_*shape_model and find_*deformable_model returned the error 3513 ("number of coords too big") if MinScore was set to a very small number. Additionally, find_shape_model(s) and find_scaled_shape_model(s) returned the error 6041 ("No memory block allocated at last") if a model was passed that was created by using create_aniso_shape_model. These problems have been fixed. In the last case, no error message is returned anymore. Instead, empty tuples are returned as output parameters.
  • Some operators did not ignore empty regions although the system parameter 'empty_region_result' was set to 'true'. Instead, the operators terminated after an empty region was found. The following operators were affected: This problem has been fixed. Now, the operators ignore empty regions if 'empty_region_result' is set to 'true'.
  • gen_binocular_rectification_map returned the inappropriate error 6001 ("Not enough memory available") if the fields of view of both cameras did not intersect each other. This problem has been fixed. Now, the new error 3701 ("Fields of view of both cameras do not intersect each other") is returned in this case. Programs that evaluate the returned error messages must be adapted accordingly.
  • gen_contour_polygon_rounded_xld returned the first point of the computed contour twice. This problem has been fixed.
  • gen_gauss_pyramid returned images with displaced domains if the input image domain was shaped paraxial and rectangular, and the scale factor differed from 0.5. This problem has been fixed.
  • gen_parallel_contour_xld returned corrupted contours in rare cases if the input contour contained duplicate points. This problem has been fixed.
  • get_bar_code_object with ObjectName set to 'scanlines_all' in very rare cases returned scanline XLDs containing an invalid point. This might have happened when the bar code reader could not find an edge on a scanline. In this case, the scanline XLD consisted of three points instead of two where one point was corrupt. This problem has been fixed.
  • get_bar_code_result might have crashed if called with ResultName = 'composite_strings' when no composite component could be found. This problem has been fixed.
  • get_descriptor_model_results with the parameter ResultNames = 'point_classification' returns the point correspondences for the interest points in the search image and in the model image. This process is also called 'classification', as the interest points in the search image are 'classified' according to the interest points in the model image. The following problems were related to this classification:
    • When ObjectID is set to 'all', the classification of all search interest points must be returned. However, if only one object was found in the search image, get_descriptor_model_results returned only the classification of the interest points in the search image that were successfully matched.
    • For each point correspondence, the returned tuple contains a triple containing the search point id, the model point id, and their correspondence score (the so-called classification score). The returned scores were normalized between 0 and 1, which was conform to the reference manual entry of get_descriptor_model_results, but they were returned in an inappropriate format so that they could not be compared to the descriptor parameter 'min_score_descr'.
    These problems have been fixed. For the latter case, the reference manual entry has been adapted to reflect the new value range of the score.
  • get_object_model_3d_params crashed in rare cases if the value 'primitive_rms' with the generic parameter 'ParamName' was accessed and if no attribute of type primitive was available. This problem has been fixed.
  • gray_histo_range and tuple_histo_range might have crashed in very rare cases if real images or real tuples were used. This problem has been fixed.
  • gray_projections crashed if Region was larger than Image, Image was of type 'uint2', 'int2', or 'real', and Mode was set to 'simple'. This problem has been fixed.
  • import_lexicon had problems when reading text files containing only a single line without a newline character. If the word in this line contained only a single character, import_lexicon hung. If the word consisted of multiple characters, the word was split up into the first characters without the last character and a new word containing only the last character. These problems have been fixed.
  • inpainting_texture might have returned the error 6002 ("Memory partition on heap has been overwritten") in very rare cases. This problem has been fixed.
  • median_rect and rank_rect might have returned wrong results on 64 bit architectures if MMX and SSE2 were disabled. These problems have been fixed.
  • When executing min_image on directional images on an OpenCL device, the result was not set to undefined if one of the input values was undefined. This problem has been fixed.
  • object_model_3d_to_xyz created invalid or undefined values outside the returned ROI. This problem has been fixed.
  • paint_region and overpaint_region returned erroneous results for gray value arrays of mixed type, i.e., the gray values painted into the output image did not have the correct value. This problem has been fixed.
  • plateaus_center and lowlands_center returned a region of pixel (0,0) instead of an empty region if no plateau was found. This problem occurred if the system parameter store_empty_region was set (default). This problem has been fixed.
  • points_harris_binomial crashed if the input parameter MaskSizeGrd or MaskSizeSmooth was 1. This problem has been fixed.
  • read_object_model_3d sometimes failed to automatically detect the type of binary STL files. Additionally, it returned the error 1301 ("Wrong value of control parameter: 1") if a *.om3 file was invalid or the file had an invalid version. These problems have been fixed. In the latter case, now the error 9510 ("Invalid 3D file") or the error 9513 ("The 3D object model file has an invalid version") is returned. Programs that evaluate the returned error messages must be adapted accordingly.
  • read_region returned the error 3510 ("Exceeding the maximum number of run lengths while automatical expansion") if the system parameter 'clip_region' was set to 'true' and the region was significantly larger than the currently largest image dimensions (i.e., the system parameters 'width' and 'height'). Furthermore, read_region did not clip the input region when working with image data of type 'tif', 'png', or 'bmp'. These problems have been fixed.
  • read_tuple caused a memory leak if the input file was corrupt. This problem has been fixed.
  • reconstruct_points_stereo crashed if valid input in CovIP was combined with a camera setup model having no information about the camera parameter covariances. Whereas this could not have happened with a camera setup model that was returned by a multi-camera calibration (see get_calib_data with DataName='camera_setup_model'), the camera setup model created explicitly with create_camera_setup_model and set-up by set_camera_setup_cam_param does not have the required camera parameter covariances, which was causing a successive call to reconstruct_points_stereo to crash. This problem has been fixed. Now, reconstruct_points_stereo detects whether the required information is missing and, if necessary, skips the computation of CovWP.
  • reconstruct_surface_stereo could have crashed when the bounding box or part of it was behind the base line of any of the camera pairs. This problem has been fixed. Now, the error 8494 ("Bounding box lies partially or completely behind the base line of at least one camera pair") is returned. Additionally, reconstruct_surface_stereo could have crashed when 'rectif_interpolation' was initially set to 'none' and then, after the image pairs were already specified (with a call to set_stereo_model_image_pairs), was changed to 'bilinear'. This problem has been fixed, too. Now, in accordance with the reference manual entry, the change of the parameter does not have any effect until the next call to set_stereo_model_image_pairs.
  • scale_image was not executed on compute devices for images of type 'complex'. This problem has been fixed.
  • segment_object_model_3d sometimes crashed when the generic parameter 'output_point_coord' was set to 'false'. This problem has been fixed.
  • With set_bar_code_param and the generic parameter 'min_identical_scanlines' you can set the minimum number of identical scanlines. However, if 'min_identical_scanlines' was set to 1, two identical scanlines were needed for successful decodings. This problem has been fixed.
  • set_data_code_2d_param could not change the symbol shape from 'rectangle' to 'square' if the maximum value of 'symbol_cols_min' and 'symbol_rows_min' was greater than the minimum value of 'symbol_cols_max' and 'symbol_rows_max'. This problem has been fixed. The handling of the restrictions in the symbol size and the corresponding documentation for 'symbol_shape' in the reference manual entry have been improved.
  • Regions were displayed incorrectly if the draw mode was set to 'margin' (set_draw), the neighborhood was set to 4 (set_system), and line style was set to anything but the default (set_line_style). This problem has been fixed.
  • sobel_amp with FilterType = 'thin_sum_abs' or 'thin_sum_max' crashed if the domain of the input image was irregularly shaped. This problem has been fixed.
  • svd_matrix returned a matrix with a wrong dimension if ComputeSingularVectors was set to 'none', i.e., no matrices with the singular vectors were computed. This problem has been fixed.
  • train_class_gmm might have crashed if a Gaussian Mixture Model was to be trained, automatic operator parallelization was turned on, and the number of centers was a fixed number (instead of minimum and maximum values). The problem only occured if an internal error occured, e.g., if all input features were equal. This problem has been fixed.
  • tuple_environment and the corresponding operation environment might have returned the wrong value of environment variables in rare cases. Environment variables that begin with 'HALCONROOT' always returned the value of the variable 'HALCONROOT' or, if it was not set, the automatically determined value of HALCONROOT. On Windows systems, the values of environment variables starting with 'HALCONIMAGES' or 'HALCONEXTENSIONS' were returned with the surrounding quotes removed. This problem has been fixed.
  • tuple_gen_const, tuple_concat, and tuple_rand crashed if the length of the tuple to create was greater than or equal to pow(2,sizeof(long)*8)/16. This problem has been fixed.
  • tuple_round returned the negative value -2^31 for input values of type float larger than 2^31. On 64-bit Windows systems (x64-win64), numbers with an absolute value larger than 2^31 were handled incorrectly. These problems have been fixed.
  • tuple_select did not return an error if elements of an empty tuple were accessed. Instead, an empty tuple was returned. This was inconsistent to the [] operation in HDevelop. This problem has been fixed and tuple_select now returns the error 1402 ("Wrong number of values of control parameter: 2"). The error handling in existing applications must be adapted accordingly.
  • tuple_strchr did not allow to search for multiple characters in one string. Instead, the error 1201 ("Wrong type of control parameter: 1") was returned. This problem has been fixed.
  • vector_to_pose sometimes crashed with Method='analytic'. This problem did not appear with any other method. This problem has been fixed.
  • write_fft_optimization_data wrote corrupted files if optimize_fft_speed or optimize_rft_speed had been called for many different image dimensions. These corrupted files could not be read by read_fft_optimization_data. This problem has been fixed. Note that if necessary a new file format (version 3) is used for the optimization data that cannot be read by HALCON versions prior to HALCON 10.0.2.
  • write_image might have caused a memory leak if an error occurred while writing a PNG image, e.g., when there was not enough disk space. Additionally, it could not write TIFF images with more than 255 channels, although the documentation stated that this format has no limitations in the number of channels. These problems have been fixed. In the latter case, write_image can now write TIFF images with up to 65535 channels. The corresponding reference manual entry has been adapted accordingly.
  • write_object_model_3d produced corrupt STL files if the 3D object model did not contain triangles but faces (polygons). This problem has been fixed.

Procedures

o Bug Fixes:
  • When used with large images, the arrow heads of the external procedure disp_3d_coord_system were not well visible. This problem has been fixed.

HDevEngine

o Examples:
  • The examples hdevengine/c#/ExecExtProc and hdevengine/vb.net/ExecExtProc created a HFramegrabber object without disposing it, causing a resource leak with multiple executions. This problem has been fixed.

Image Acquisition Interfaces

The latest information about new extensions and newly supported image acquisition devices can be found on MVTec's web server.

o New Image Acquisition Interfaces:
  • HALCON now also includes the OpenNI interface that is based on the OpenNI Framework and allows the easy acquisition of 3D depth images from OpenNI compliant 3D sensors like the popular Microsoft Kinect and the ASUS Xtion PRO. The new HDevelop example programs openni_2cameras.hdev, openni_create_camera_calibration.hdev, openni_parameters.hdev, openni_simple.hdev, and openni_surface_based_3d_matching.hdev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.

o Modified Image Acquisition Interfaces:
  • The following HALCON image acquisition interfaces have been revised since HALCON 10.0.1:
    • For the 1394IIDC interface a problem in the operator grab_image in combination with low frame rates has been fixed.
    • The 1394IIDC-2 interface now is based on the new version 2.1.2 of the system library libdc1394 and the new Linux kernel modules firewire-ohci and firewire-core.
    • For the GenICamTL interface several problems have been fixed and minor enhancements have been applied. In particular, the new interface revision now supports chunk data via the operators grab_data and grab_data_async and enables to get notified in case of any device-specific events via user-specific callbacks. Furthermore, the behavior of the operator grab_image has been changed if the device's acquisition mode was set to 'Continuous' and the internal color conversion has been adapted to use the information provided by the current buffer.
    • The GigEVision interface comes with the new version 1.0.6.4 of the underlying HALCON GigE Vision Streaming Filter including a bugfix to avoid lost images in case of occasionally delayed packets. Additionally, several problems have been fixed, in particular regarding the used image size in case of binning/decimation, the internal color conversion in case of >8 bpp Bayer formats, and a problem in the Windows filter driver that caused a crash when the number of packets for one block increased after opening the device.
    • The LuCam interface now is based on the LuCam SDK version 6.1 and supports now also the GigE cameras from Lumenera. Furthermore, the new revision enables using the snapshot acquisition mode and provides more accurate information via the operator info_framegrabber.
    • The MatrixVisionAcquire interface now supports also the mvIMPACT Acquire pixel format ibpfBGR888Packed, the handling of multi-value properties in the HDevelop Image Acquisition Assistant, and provides the new parameter 'do_invalidate_property_cache'. Furthermore, problems regarding the grabbing of color images and regarding the parameters 'do_abort' and 'grab_timeout' have been fixed.
    • The MILLite interface now supports also the Morphis frame grabber boards.
    • The MultiCam interface now is based on the new MultiCam driver version 6.7 and supports now also the new GRABLINK Full/DualBase/Base boards. Additionally, the new interface revision enables the use of user-specific callbacks to indicate that a new image has been grabbed and to inform the user about the start and end of the actual exposure period. Furthermore, a problem in the operator open_framegrabber regarding the usage of an analog frame grabber board in combination with a color camera has been fixed.
    • The Opteon interface is now based on v4.0 of the Opteon software distribution. Besides several general improvements, the new interface revision supports also multiple internal strobe controllers and remote trigger mode.
    • The pylon interface now enables the use of user-specific callbacks, e.g., to indicate the end of the actual camera exposure period. Additionally, it now allows the configuration of all features (not the grabbing) of Basler Camera Link cameras and disables the setting of external trigger parameters during the call of the operator open_framegrabber. Furthermore, problems regarding the parameters 'Width', 'Height', and 'image_available', problems in the operator open_framegrabber regarding the access of a device via its serial and device number, and a problem in the operator close_framegrabber, which occured if the 'exposure_end' callback function was registered before, have been fixed.
    • The SaperaLT interface now is based on Sapera LT library version 7.0 (or higher) and allows the use of user-specific callbacks to indicate the end of the actual image transfer. Additionally, the new interface revision provides an improved internal buffer handling, new parameters to configure pixel clock and line scan cameras, and the interface has been optimized in terms of memory usage in combination with frame grabber boards. Furthermore, several problems regarding the Windows x64 memory management and the parameters 'continuous grabbing', 'image_available', and 'grab_timeout' have been fixed.
    • The SICK-3DCamera interface has been adapted to the new SICK icon API 4.3 with support of the eBus driver also for 64-bit Windows. Additionally, the new interface revision includes new parameters to query the current camera status, to delay the start of the camera, and to force the use of the socket driver. Furthermore, a problem in set_framegrabber_param regarding the setting of specific parameter values via 'module_value' and several other problems (in particular regarding lost packets when setting specific parameters and regarding message boxes of the SICK error handler) have been fixed.
    • The SiliconSoftware interface now provides an advanced continuous grabbing mode that supports to queue an arbitrary number of trigger signals. Furthermore, the new interface revision includes a new parameter to query the image tag and allows to execute command parameters for GigE Vision devices.
    • For the SonyXCI-2 interface a problem regarding the grabbing of images in external trigger mode has been fixed.
    • For the SVCam-GigE interface, problems regarding the loading of the correct SDK library on Windows x64 and regarding multiple cameras waiting for a trigger signal in case of multi-threaded applications have been fixed.
    • The SwissRanger interface now allows to read also offline images from SwissRanger stream (SRS) files. Furthermore, the new interface revision has been improved regarding a simpler and more intuitive setting of the used acquire mode.
    • The uEye interface now provides several new parameters to query the internal time stamp of the last grabbed image, to specify the number of internally used buffers, to get information about occurred and missed trigger events, and to set the internal timeout value. Additionally, a problem in the operator grab_image_async in case of continuous grabbing when called after aborting the previous grab has been fixed, The new HDevelop example program ueye_timestamp.hdev in the directory examples/hdevelop/Image/Acquisition shows how to use the new time stamp feature.

    Please refer to the corresponding documentation for information about additional changes, especially whether a new revision of the corresponding device driver is required.


Manuals

o HDevelop User's Guide:

The HDevelop User's Guide is now available in a new edition. It has been adapted to the changes in HALCON 10.0.2.


o Solution Guide Basics:

The Solution Guide Basics is now available in a new edition. In particular, it has been extended by a section describing different options of handling gray values outside of the image domain to avoid problems if more than one filter is used in sequence.


o Solution Guide on Image Acquisition:

The Solution Guide on Image Acquisition is now available in a new edition. In particular, it has been revised to comprise more modern technologies like callbacks or the use of standardized image acquisition interfaces. Note that for the revision the following HDevelop example programs in the directory examples/solution_guide/image_acquisition have been replaced by corresponding programs that use more modern image acquisition interfaces:

  • first_example_acquisition_falcon.hdev has been replaced by first_example_acquisition_saperalt.hdev,
  • info_framegrabber_falcon.hdev has been replaced by info_framegrabber_1394iidc.hdev,
  • multiple_boards_px.hdev has been replaced by multiple_boards_bitflow.hdev,
  • multiple_ports_px.hdev has been replaced by multiple_ports_bitflow.hdev,
  • port_switching_inspecta.hdev has been replaced by port_switching_bitflow.hdev,
  • real_time_grabbing_falcon.hdev has been replaced by real_time_grabbing_bitflow.hdev,
  • simultaneous_grabbing_inspecta.hdev has been replaced by simultaneous_grabbing_bitflow.hdev, and
  • volatile_grabbing_falcon.hdev has been replaced by volatile_grabbing_bitflow.hdev.

o Image Acquisition Interface Programmer's Manual:

The Image Acquisition Interface Programmer's Manual is now available in a new edition. It has been generally revised to be up-to-date.


o HALCON Operator Reference Manual:

Miscellaneous

o Installation:
  • The uninstaller might have hung during the setting of updated environment variable settings. This happened if any other running application did not process Windows messages correctly. This problem has been fixed.
  • The uninstaller did not restore the file associations for the file extensions .dev, .dvp, .hdev, and .hdvp for another version of HALCON after uninstalling the current version. This problem has been fixed.

o Pretrained OCR fonts:
  • The special characters contained in the OCR fonts 'OCRA' and 'OCRA_A-Z+' were not complete. Although listed in the documentation in the Solution Guide Basics, the curly brackets were missing. In contrast, the OCR font 'Industrial' contained too many special characters. In particular, the font contained a comma although it should not because in practice a comma and a point often will be mixed up. This problem has been fixed.



Advance Notice

The export of HDevelop programs and procedures into the .NET languages C# and Visual Basic .NET based on the HALCON/COM interface is marked as legacy and will be removed in the next major release of HALCON. Then, for these languages only the export that is based on the HALCON/.NET interface will be provided.



Known Issues

Please note the following known problems for HALCON 10: