Release Notes for HALCON 9.0.2  
 

 

This document provides the release notes for MVTec HALCON 9.0.2, as released in March 2010. HALCON 9.0.2 is primarily a maintenance release that fixes all known bugs in HALCON 9.0.1; besides, it provides added functionality.




Overview

This document contains the following information:

Compatibility
Major New Features of HALCON 9.0.2
Detailed Description of Changes in HALCON 9.0.2
Major New Features of HALCON 9.0.1
Detailed Description of Changes in HALCON 9.0.1
Major New Features of HALCON 9.0
Detailed Description of Changes in HALCON 9.0 (relative to HALCON 8.0.2)




Compatibility

o Licenses

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



o HALCON Library

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



o HALCON Applications

Applications (i.e., executables) developed with HALCON 9.0 or HALCON 9.0.1 can be used with HALCON 9.0.2, i.e., HALCON 9.0.2 is binary compatible with HALCON 9.0 and HALCON 9.0.1.

The incompatibility with HALCON 8.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 9.0 and HALCON 9.0.1, respectively.

Please note the following source-code incompatibilities with respect to previous HALCON 9.0.x releases:

  • Programs that evaluate specific error messages with respect to the following operators must be adapted accordingly:
  • Newly created shape models and 3D shape models might differ in comparison to shape models and 3D shape models that were created with earlier HALCON revisions. Therefore, also the matching results might change slightly if a model is recreated.
  • OCR classifiers (box, MLP, and SVM) that use specific combinations of features must be re-trained because there was an error in the calculation of features from images in several operators. Additionally, programs in which an image array is passed to do_ocr_multi_class_mlp and do_ocr_multi_class_svm must be adapted, because the number of input images is now checked and therefore it is not possible to erroneously pass an image array to the parameter Image anymore.
  • fit_ellipse_contour_xld does not allow the fitting of ellipses to contours with fewer than five points anymore. Although this was already the case for the algorithms 'fitzgibbon' and 'geometric' and all their derivatives, it is now also true for the algorithms 'voss', 'focpoint', 'fphuber', and 'fptukey'. If your program relies on the behavior that fit_ellipse_contour_xld returns ellipse parameters that represent a straight line when one of the latter algorithms was selected and when the contour has two to four points, you must determine the number of contour points with the operator contour_point_num_xld and, if the contour has two to four points, call the operator fit_line_contour_xld.
  • For StartPhi=EndPhi and PointOrder='positive', gen_ellipse_contour_xld no longer returns a full ellipse but only one point.
  • Programs that use illuminate with different values for MaskWidth and MaskHeight should be adapted because the sequence of parameters has been corrected.

Please note that applications using HALCON/.NET (and HDevEngine/.NET) have local copies of the corresponding assemblies (halcondotnet.dll etc.). After installing HALCON 9.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 9.0.1:

  • For using the updated Crevis interface you must install the new Crevis driver V2.0.0.1.
  • For using the updated mEnableVisualApplets interface you must install the driver version 4.2.25 from Silicon Software to support the new microEnable IV FULL x4 boards.
  • For using the updated MILLite interface you must install the new Matrox SDK Mil-Lite 9.0.
  • For using the updated uEye interface you must install the new driver version 3.40.

If you have developed your own acquisition interfaces with HALCON 9.0 or HALCON 9.0.1, you can use them with HALCON 9.0.2 without further action. Because of the new version of the HALCON Acquisition Integration Interface in HALCON 9.0, acquisition interfaces developed with HALCON 8.0.x or lower are not binary compatible, but mostly source-code compatible with HALCON 9.0.


o Extension Packages

Extension packages developed with HALCON 9.0 or HALCON 9.0.1 can be used with HALCON 9.0.2 without further action. Extension packages developed with HALCON 8.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 9.0.2.
  • ActivVisionTools 1.0 to 3.1 cannot be used with HALCON 9.0.2. If the setup program detects such an ActivVisionTools version, it warns you that by continuing to install HALCON 9.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.



Major New Features of HALCON 9.0.2

HDevelop:

o Image Acquisition Assistant:

The usability of the HDevelop Image Acquisition Assistant has been improved, in particular, with respect to the new features of the GigEVision interface.



HALCON Library

o 1D Bar Codes:

The 1D bar code reader has been extended:

  • The print quality assessment has been improved. In particular, you can now query also the underlying raw quality measurements.
  • 1D bar codes of type MSI are supported.
  • New parameters are available. One is provided to specify an absolute minimum for the threshold needed for the detection of the bar-space sequence within a bar code candidate region. Three new parameters are provided to control the bar code scanning.



o 2D Data Codes:

The print quality assessment for 2D data codes has been improved. In particular, you can now query also the underlying raw quality measurements.



o High Contrast Images:

The accuracy for high contrast images has been increased for

  • shape-based matching,
  • component-based matching,
  • perspective, deformable matching,
  • 3D matching, and
  • the operator edges_subpix.


Image Acquisition:

o Revised GigEVision Interface:

The GigEVision interface has been significantly improved and now provides a specific filter driver to increase the performance under Windows XP/Vista/7.



o New Image Acquisition Interfaces:

HALCON has been extended by the following new image acquisition interfaces:






Detailed Description of Changes in HALCON 9.0.2

Detailed release notes can be obtained for the following topics:

HDevelop
HALCON Library
HALCON/C++
HALCON/.NET
HALCON/COM
HDevEngine
Image Acquisition Interfaces
Manuals
Miscellaneous

HDevelop

Functionality
Bug Fixes
Examples

o Functionality:
  • The usability of the Image Acquisition Assistant has been improved:
    • When a connection parameter was changed while the Image Acquisition Assistant was connected, a small warning sign was displayed to indicate that the connection was valid, but out of date. This was confusing and has been changed. Now, the Assistant disconnects automatically.
    • It is now possible to specify a value for the parameter Generic on the 'Connection' tab (in HDevelop syntax). Note that several image acquisition interfaces now provide value lists for the corresponding combo box.
    • The status of a device can now be displayed using an icon in the device combo box on the 'Connection' tab. The GigEVision interface uses this to mark devices with a misconfigured IP address. Selecting such a device provides a suggestion for an automatic reconfiguration via the parameter Generic.
    • The mechanism for querying connection parameters from the acquisition interfaces has been optimized. In particular, there are less delays when working with the GigEVision interface (this also applies to the acquisition support in the Operator window and the full text editor).
    • Under Windows, the revision of an acquisition interface is now displayed in the 'Connection' tab even if the DLL could not be loaded due to unresolved dependencies.
    • When a grab error occurs, live acquisition is now stopped to avoid getting stuck in a loop with low level error boxes. Additionally, low level errors are now suppressed when using a slider to change the value of an acquisition parameter.
    • The value range for a numeric acquisition parameter, if available, is now appended to the tooltip description.
  • Pressing F1 while an assistant runs in the currently active window, which has the keyboard focus, will now show the assistant's help page in the Help browser instead of the 'HALCON Reference Manual' page.
  • HDevelop now checks whether %HALCONROOT% is set to the correct major version. If %HALCONROOT% is set to a different installed major version, a warning is displayed and HDevelop exits.
  • As long as the HDevelop user has not selected a language explicitly via the Preferences dialog, HDevelop uses - if supported - the language of the operating system. However, after selecting a language via the User Interface -> 'Language' tab card on the Edit -> Preferences dialog, HDevelop did not offer an opportunity to go back to the default behavior, i.e., to follow the system language. This has been changed. Now, the combo box that offers the different supported languages has an option 'System language'. This entry additionally displays the currently active system language and whether this language is supported or not. If the current system language is not supported, HDevelop uses English.
  • The help pages of procedures that are displayed in the Help window have been improved:
    • If in the procedure documentation a value range is specified (value minimum and/or value maximum), the range is now listed on the help page of the procedure.
    • In the Help window, some section labels on the procedure's page have been translated into the currently active language.
  • When the mouse cursor is moved over the Graphics window, pressing the Ctrl key opens a tooltip that displays the current mouse position and the gray values of the image at this position. However, no tooltip was shown as long as no image was displayed before in the Graphics window. This has been changed. When the mouse cursor is over a Graphics window that contains no image, from now on, pressing the control key opens a tooltip that displays the mouse position.
  • Until now, the mouse wheel could be used to zoom the contents of the Graphics window in all modes but the select mode, which is the default mode. In this mode, the mouse wheel had no function. This has been changed. Now, the mouse wheel can be used also in the select mode to zoom the contents of the Graphics window.
  • During the execution of a draw_* operator, the temporary help message that explains how to use the draw_* operator no longer occupies the whole status bar. Instead, the current mouse position remains visible in the right part of the status bar and can be used for an accurate placement of the region. Additionally, it is now also possible to open the pixel information tooltip close to the mouse cursor by pressing the Ctrl key during the execution of the draw_* operator.


o Bug Fixes:
  • Under Windows, in case of a crash of HDevelop no emergency backup was saved. This problem has been fixed.
  • The Find/Replace dialog had the following problems:
    • If it was used in the operator replacement mode and the name of an external procedure that was corrupt and could therefore not be loaded was used as the search or the replace operator name, HDevelop sometimes crashed.
    • It was unable to work correctly with the backslash character "\".
    • After a 'Find All' operation in the Find/Replace dialog a selection within the search results also selects the corresponding program lines in the program listing. However, in full text mode this selection did not work correctly. In particular, although the corresponding program lines were highlighted, 'cut', 'copy', 'delete', or similar operations in the program listing did not affect these lines.

    These problems have been fixed. Regarding the last of the stated problems, the new behavior is as follows: if multiple lines from the same procedure are selected in the search results, in the program listing the topmost program line is selected and reacts to 'cut', 'paste', etc. The other program lines are highlighted in a different color. However, due to technical reasons these lines do not react to 'cut', 'copy', etc.
  • In the Program window it is possible to set and clear breakpoints via the context menu. However, in contrast to setting the insert or program cursor, the breakpoint actions did not affect the program line under the mouse cursor but the program line with the text cursor, which was counterintuitive. This problem has been fixed. Now, the breakpoint is set on the program line under the mouse cursor.
  • Creating a procedure by selecting an invalid program line like an incomplete operator call and calling the 'Create New Procedure' action from the 'Procedures' menu or the context menu of the Program window could have led to a crash of HDevelop. This problem has been fixed.
  • If in the Procedure Interface dialog for several parameters the same name is entered, HDevelop automatically renames the additional parameters into a unique but invalid name by appending [idx]. If the same name was entered multiple times and then one of these automatically renamed parameters was edited in a specific way and finally removed, HDevelop could have crashed. This problem has been fixed.
  • For the parameter suggestions in HDevelop in some cases row and column variables were interchanged or suitable variables were not suggested. These problems have been fixed.
  • The full text editor had the following problems:
    • If within the full text editor a program line was created with a valid operator name but invalid parameters and this operator was corrected within the Operator window and re-entered into the program listing, it remained invalid until it was edited within the full text editor.
    • After entering a block end statement into the full text editor and pressing Enter, the next program line was not correctly indented. The new line always started at the first column, i.e., it had no indentation at all, instead of having the same indentation as the block end statement directly above. In addition, it was not possible to move block end statements to the right by entering additional spaces before the operator name or by selecting the statement and pressing <TAB>. The full text editor forced the block end statement to be always at the same position as the corresponding block begin statement even if the user wanted to change this explicitly.
    • If a program line was especially formatted in the full text editor, e.g., by splitting it into several lines or filling it with extra spaces, activating or deactivating the line via the menu or the short cuts F3 or F4 removed this format and simplified the program line to the line editor's format. In addition, Ctrl-Z did not restore the program line's format correctly but only the activation state.
    • After moving the text cursor in the full text editor into an empty line and pressing <ENTER>, the program listings scrolled automatically down so that the new line became the last line in the listing.

    These problems have been fixed.
  • After running HDevelop and opening modal dialogs or the Help Window on a second monitor that was connected to the computer system, the following problem occurred if the second monitor was removed from the system after finishing HDevelop: While the Main Window of the restarted HDevelop was opened correctly on the visible part of the desktop, the Help Window as well as some modal dialogs like the Print dialog, the Property dialog, or the Export dialog were opened at their old position that was now outside the desktop and therefore not visible. After opening such a modal dialog HDevelop seemed to be frozen. This problem has been fixed. Now, all dialogs are opened in the visible part of the desktop.
  • Although all parameters of the operator for accept real numbers, the semantic type of these parameters was set to 'integer'. This problem has been fixed. Now, the type is set to 'number'.
  • The suggested default value for the ErrorVar parameter of the operator dev_error_var was wrong. Instead of a valid variable name the number 0 was suggested. This problem has been fixed.
  • A German or Korean HDevelop could have crashed if the parameter Mode of the operator dev_set_check had the wrong number of values (not equal to 1). Otherwise, the text in the error message box was erroneous: While the English text is "Input parameter 'Mode' must evaluate to one value", the German and the Korean message text contained a too large number before and an invalid string within the quotes. The operators dev_update_pc and dev_update_time were also effected. This problem has been fixed.
  • On X11 systems, the clear_window operator did not work as expected. If objects were displayed in the Graphics window with the help of a normal HALCON display operator like disp_obj, disp_circle, or write_string, and then clear_window was called, the window was cleared at first, but if another object was displayed later, the old objects were re-displayed together with the new one. This problem has been fixed.
  • The Variable Inspection window for image acquisition handles contained no values under Linux 32 bit Systems. This problem has been fixed. Now, the correct values are displayed.
  • If a string with long parts without any white spaces was assigned to a variable and this variable was inspected in the Variable Inspection window, the table item with the representation of the string had the following problems:
    • The string was not wrapped, so that the text was not completely visible.
    • The height of the row was too big.

    These problems have been fixed. Now, parts of the string that are too long for being displayed in one row are wrapped even if there are no white spaces. The wrapping within a word is marked by a special character. However, if possible, wrapping at white spaces is preferred. Additionally, the table item has now a tooltip displaying the item contents.
  • By calling dev_inspect_ctrl within a procedure that was currently not visible in the program listing, it could have happened that no or the wrong Variable Inspection window was opened. In particular,
    • if the execution of the procedure was not interrupted (e.g., by a stop command) after calling dev_inspect_ctrl, the Variable Inspection window was not displayed at all, and
    • if the execution of the procedure was stopped, but the variable parameter of dev_inspect_ctrl refered to a matrix or an image acquisition handle, the general Variable Inspection window, which shows only the handle, instead of the specific Variable Inspection window was opened.

    These problems have been fixed. Now, when executing dev_inspect_ctrl the related procedure is displayed in the program listing.
  • HDevelop sometimes did not reset the visible area in the Gray Histogram after a new image was shown. This problem has been fixed.
  • The following problems occured when working with Graphics windows:
    • On Linux and UNIX systems, the Graphics window did not correctly re-paint the iconic HALCON objects if parts of the window were hidden and became visible again.
    • In SDI mode, it was not possible to open a Graphics Window with dev_open_window or via the Visualization menu with a width wider than 2/3 of the screen. Furthermore, when setting the window size with dev_set_window_extents or via the Window Size menu to a large width, the window size was also clipped to 2/3 of the width of the screen.
    • The Graphics window's 3D plot mode was corrupted if it was switched on while the magnify mode was active. In this case, pressing the left mouse button on the 3D plot area resulted in a small square area around the mouse pointer. In that area, a smaller 3D plot of the image was displayed. This plot could not be removed without leaving the 3D plot mode.
    • HDevelop crashed when using the mouse wheel in a Zoom window that was not connected to a Graphics window.
    • HDevelop lost the focus when a Graphics window was opened. In particular, neither the newly opened window nor any other HDevelop window got the focus. This sometimes led to problems if, e.g., a low level error occurred and a message box was opened. In that case, the application could have remained in an inconsistent state, allowing user interaction although the message box was still open.

    These problems have been fixed. Regarding the last of the stated problems, the new behavior is as follows: Opening a Graphics window in HDevelop now sets the focus to the newly opened window.
  • In case of a crash, HDevelop tries to save the program and all modified external procedures. However, modified external procedures were not saved under their procedure name but under the program name including the extension .dev. Because of the extension, the procedures could not be used without renaming the files. Additionally, the information about the names of the emergency backup files was printed only into the console but not into a message box. These problems have been fixed.
  • If an external procedure with invalid program lines was protected by a password before saving, it could not be re-loaded again. Trying to load such a procedure resulted in a loading error owing to an invalid file format. This problem has been fixed.
  • When closing an assistant via the close button while a draw_* operator was executed, the assistant remained deactivated even if it was re-opened later. There was no way to activate it again. This problem has been fixed.
  • It was possible to enter some unsupported parameter values for the calibration plate extraction parameters in the Calibration Assistant. This problem has been fixed.
  • Within the Image Acquisition Assistant, the default values for the resolution properties on the 'Connection' tab were always set to Full, even if the acquisition interface specified a different value such as Default. This problem has been fixed.
  • HDevelop sometimes crashed when trying to export an invalid program line to C. This happened if the invalid program line was activated and situated within a procedure that contained at least one output control parameter. This problem has been fixed.
  • The exported code for try-catch to C# (HALCON/COM) failed when the compiled application ran as a 64 bit process. This problem has been fixed.
  • HDevelop expressions containing the functions "lsh" or "rsh" were incorrectly exported to HALCON/C++ with respect to operator precedence. This problem has been fixed.
  • HDevelop exported calls to dev_clear_obj incorrectly to C, C# - HALCON/.NET, Visual Basic .NET - HALCON/.NET, C# - HALCON/COM, and Visual Basic .NET - HALCON/COM:
    • In C, dev_clear_obj was exported as a comment.
    • In C# (COM and .NET), the exported code contained the wrong variable name.
    • In Visual Basic .NET - HALCON/COM and HALCON/.NET, the variable was set to Nothing.

    These problems have been fixed. Now, in C, dev_clear_obj is exported as clear_obj followed by gen_empty_obj and in Visual Basic .NET - HALCON/COM and HALCON/.NET, it is exported as a call to ReleaseComObject and Dispose, respectively.
  • HDevelop exported programs containing exception handling incorrectly to C# - HALCON/.NET, Visual Basic .NET - HALCON, C# - HALCON/COM, and Visual Basic .NET - HALCON/COM. The exported programs sometimes caused a memory leak if an exception occurred in a procedure containing local iconic variables. This problem has been fixed.


o Examples:

HALCON has been extended by the following HDevelop example programs:

  • The new HDevelop example programs andor.dev, andor_simple.dev, and andor_parameters.dev in the directory examples/hdevelop/Image/Acquisition show how to use the new Andor interface.
  • The new HDevelop example programs sentech.dev, sentech_parameters.dev, sentech_simple.dev, and sentech_trigger.dev in the directory examples/hdevelop/Image/Acquisition show how to use the new Sentech interface.
  • The new HDevelop example programs sick-3dcamera.dev, sick-3dcamera_calibration.dev, sick-3dcamera_components.dev, sick-3dcamera_parameters.dev, and sick-3dcamera_simple.dev in the directory examples/hdevelop/Image/Acquisition show how to use the new SICK-3DCamera image acquisition interface.
  • The new HDevelop example programs svcam-gige.dev, svcam-gige_crop.dev, svcam-gige_parameters.dev, svcam-gige_simple.dev, and svcam-gige_trigger.dev in the directory examples/hdevelop/Image/Acquisition show how to use the new SVCam-GigE interface.
  • The new HDevelop example program examples/hdevelop/Tools/Barcode/msi.dev shows how to use the newly supported bar codes of type MSI. It uses the new images msi_* from the subdirectory images/barcode/msi/.
  • The new HDevelop example programs barcode_param_scanning_control.dev and barcode_param_num_scanlines.dev from the directory examples/hdevelop/Tools/Barcode/ show how to use the new parameters of the bar code reader that control the bar code scanning. The example barcode_param_scanning_control.dev uses the new image code3905 from the subdirectory images/barcode/code39.
  • The new HDevelop example program examples/hdevelop/Tools/Barcode/barcode_param_meas_thresh_abs.dev shows how to use the new parameter 'meas_thresh_abs' for the bar code reader.

The following HDevelop example programs have been modified:

  • The HDevelop example programs
    • examples/hdevelop/Tools/Barcode/composite_print_quality_isoiec15416.dev,
    • examples/hdevelop/Tools/Barcode/print_quality_isoiec15416.dev,
    • examples/hdevelop/Tools/Datacode/ecc200_print_quality.dev, and
    • examples/hdevelop/Tools/Datacode/print_quality_aimdpm_1_2006.dev

    have been adapted to the extensions of the print quality assessment for bar codes and data codes.
  • In the HDevelop example program examples/hdevelop/Applications/3D-Vision/calibrate_sheet_of_light.dev, the determination of the movement of the object between the acquisition of two successive profiles was erroneous. This problem has been fixed.
  • In the HDevelop example program examples/hdevelop/Applications/3D-Vision/reconstruct_connection_rod_calib.dev, the values of the pose MovementPose were erroneous. This problem has been fixed.
  • For the following HDevelop example programs the visualization has been improved:
    • examples/hdevelop/Applications/FA/clip.dev
    • examples/hdevelop/Tools/Barcode/ean13.dev
    • examples/hdevelop/Filter/Lines/lines_color.dev
    • examples/hdevelop/Applications/FA/circles.dev
    • examples/hdevelop/Filter/Match/gen_gauss_pyramid.dev
    • examples/hdevelop/Regions/Transformations/clip_region.dev
    • examples/hdevelop/Regions/Transformations/clip_region_rel.dev
    • examples/hdevelop/Applications/Aerial/dem.dev
    • examples/hdevelop/Filter/Color/cfa_to_rbg.dev
    • examples/hdevelop/Applications/Sequences/optical_flow_hydraulic_engineering.dev
    • examples/hdevelop/Applications/Calibration/3d_position_of_circles.dev
    • examples/hdevelop/Tools/2D-Transformations/hom_vector_to_proj_hom_mat2d.dev
    • examples/hdevelop/Regions/Transformations/distance_transform_metrics.dev
    • examples/hdevelop/Applications/Measure/fuzzy_measure_pin.dev
    • examples/hdevelop/Image/Features/area_center_gray.dev
    • examples/hdevelop/Image/Features/elliptic_axis_gray.dev
    • examples/hdevelop/Tools/Function/invert_funct_1d.dev
    • examples/hdevelop/Tools/Function/compose_funct_1d.dev

    Amongst others, clip_region_rel.dev now uses the image 'alpha2' instead of 'fabrik' and dem.dev uses a slightly different image part of 'mreut_dgm_2.0', which fits better to 'mreut_y', i.e., the other image used by the example.


HALCON Library

Enhancements
Modified Operators
Bug Fixes

o Enhancements:
  • The accuracy of the shape-based matching, the component-based matching, the perspective, deformable matching, and the 3D matching is now higher for the case that high contrast images are used as the model image or the search image. In previous HALCON revisions, the accuracy was decreased if the contrast in the images exceeded 127 for byte images or 32767 for uint2 images.
  • The accuracy of edges_subpix with Filter set to 'sobel_fast' is now higher for high contrast images. In previous HALCON revisions, the accuracy decreased if the contrast in the images exceeded 127 for byte images or 32767 for uint2 images.


o Modified Operators:
  • The print quality assessment for 1D bar codes and 2D data codes has been extended and now returns the underlying raw quality measurements, whenever applicable. These can be used for further investigations of print quality deficiencies of 1D bar code or 2D data code symbols. For 1D bar codes, they are queried within get_bar_code_result using the new parameter 'quality_isoiec_15416_values'. For 2D data codes, they are queried within get_data_code_2d_results using the new parameters 'quality_isoiec_15415_values' and 'quality_aimdpm_1_2006_values' for the standards ISO/IEC 15415 and AIM DPM-1-2006, respectively.
    The HDevelop example programs
    • examples/hdevelop/Tools/Barcode/composite_print_quality_isoiec15416.dev,
    • examples/hdevelop/Tools/Barcode/print_quality_isoiec15416.dev,
    • examples/hdevelop/Tools/Datacode/ecc200_print_quality.dev, and
    • examples/hdevelop/Tools/Datacode/print_quality_aimdpm_1_2006.dev

    have been adapted to show the new functionality.
  • Additionally, the 1D bar code reader now supports bar codes of type MSI and has a new parameter for absolute thresholds called 'meas_thresh_abs'. The threshold for the detection of the bar-space sequence within a bar code candidate region is determined automatically but can be too low for noisy images or for images of certain stacked bar codes. With the new parameter 'meas_thresh_abs' it is possible to specify an absolute minimum for this threshold. As default, the value is set to 5.0. The new functionality can be disabled by setting the value to 0.0. Furthermore, the 1D bar code reader has been extended by three new parameters that control the bar code scanning:
    • 'num_scanlines': maximal number of scanlines to be evaluated
    • 'min_identical_scanlines': required number of identical scanlines to accept a decoded barcode
    • 'start_stop_tolerance': start/stop matching criteria tolerance (currently only for Code 128)

    The new HDevelop example program examples/hdevelop/Tools/Barcode/msi.dev shows how to use the newly supported bar codes of type MSI. It uses the new images msi_* from the subdirectory images/barcode/msi/.
    The new HDevelop example program examples/hdevelop/Tools/Barcode/barcode_param_meas_thresh_abs.dev shows how to use the new parameter 'meas_thresh_abs'.
    The new HDevelop example programs barcode_param_scanning_control.dev and barcode_param_num_scanlines.dev from the directory examples/hdevelop/Tools/Barcode/ show how to use the new parameters that control the bar code scanning. The example barcode_param_scanning_control.dev uses the new example image code3905 from the subdirectory images/barcode/code39.
  • gen_spherical_mosaic and gen_cube_map_mosaic now offer a mode with nearest-neighbor interpolation if blending is not selected.
  • get_grayval_interpolated and get_grayval_contour_xld now support bicubic interpolation.
  • set_window_extents now handles negative values for Width and/or Height in a manner compatible with dev_set_window_extents in HDevelop, i.e., by leaving the corresponding window dimension unchanged.
  • set_window_param has a new parameter 'display_axes' to toggle the display of the axes in the 3D plot paint mode. get_window_param has been extended by this parameter as well.


o Bug Fixes:
  • HALCON was unable to read GIF images that contained certain extensions of the GIF89a standard. If a comment extension, a plain text extension, or an application extension was saved within a GIF file, HALCON was only able to reliably read the file if the corresponding data block was shorter than 256 bytes. For example, the Extensible Metadata Platform (XMP) saves its data within an application extension often containing more than 255 bytes. This problem has been fixed.
  • The two calibration plate description files calib/caltab_100mm_old.descr and calib/caltab_650um_old.descr were incorrect. This problem has been fixed.
  • abs_invar_fourier_coeff, invar_fourier_coeff, match_fourier_coeff, and fourier_1dim_inv returned no error message for a wrong number of input control parameters. This problem has been fixed.
  • add_image did not support the addition of an int2 with an int4 image although the documentation stated that it does. This problem has been fixed. Now, the addition of an int2 with an int4 image is supported.
  • The operators
    • add_noise_distribution,
    • add_noise_white,
    • add_noise_white_contour_xld, and
    • gen_random_region

    sometimes did not generate random iconic objects that were different from the previously generated ones. This happened if the operators were called too fast in succession. This also implies single operator calls with iconic object tuples or multi-channel images as input parameters. In addition, the operators add_noise_distribution and add_noise_white generated the same output images if called with the same input image objects. These problems have been fixed.
  • adjust_mosaic_images might have crashed if the input image tuple contained images of different size. This problem has been fixed. Now, the error 3117 ("Images with different size") is returned.
  • The following operators crashed if object tuples of different lengths were passed to the (first two) input object parameters:
    • apply_color_trans_lut,
    • bit_and,
    • bit_or,
    • bit_xor,
    • check_difference,
    • class_2dim_sup,
    • dyn_threashold,
    • energy_gabor,
    • nonmax_suppression_dir,
    • rgb3_to_gray,
    • real_to_complex,
    • real_to_vector_field,
    • select_grayvalues_from_channels,
    • trans_to_rgb, and
    • trans_from_rgb

    This problem has been fixed.
  • apply_sheet_of_light_calibration might have crashed when the disparity image provided as the input was not a float image. This problem has been fixed.
  • area_center returned wrong values for Row for certain regions. The affected regions were large and contained very large row coordinates. This problem has been fixed.
  • The operators
    • camera_calibration,
    • disp_caltab,
    • gen_image_to_world_plane_map,
    • image_to_world_plane, and
    • project_3d_point

    did not accept camera parameters for line scan cameras with the interior camera parameter Sy set to 0.0. This problem has been fixed.
  • check_par_hw_potential and the executable hcheck_parallel in very rare cases might have crashed. This problem has been fixed.
  • create_funct_1d_pairs did not check whether the input tuple for the parameter XValues contained multiple identical values. This problem has been fixed.
  • create_matrix returned an incorrect error message for a wrong number of input values of parameter 3. This problem has been fixed. Now, instead of the error 1303 ("Wrong value of control parameter: 3") the error 1403 ("Wrong number of values of control parameter: 3") is returned. Programs that evaluate the returned error messages must be adapted accordingly.
  • create_ncc_model sometimes crashed if an image with extremely different width and height was used as template image and the image domain touched the image borders. This problem has been fixed. Additionally, create_ncc_model returned the error 8510 ("Number of shape model points too small"). This problem has been fixed, too. Now, the error 8506 ("Number of template points too small") is returned. Programs that evaluate the returned error messages must be adapted accordingly.
  • create_ocr_class_mlp returned the error 6041 ("No memory block allocated at last") in case that the user provided duplicate entries for the parameter Characters. This problem has been fixed.
  • The shape models that were created with
    • create_shape_model,
    • create_scaled_shape_model,
    • create_aniso_shape_model,
    • create_component_model,
    • create_trained_component_model,
    • create_planar_uncalib_deformable_model, or
    • create_planar_calib_deformable_model

    sometimes contained incorrect contours at the border of the model region. This could have happened if the model image contained contours within the model region that continue outside the model region. inspect_shape_model showed the same behavior. These problems have been fixed. Note that the created shape models might differ in comparison to shape models that were created with earlier HALCON revisions. Therefore, also the matching results might change if the model is recreated.
  • The automatic contrast estimation in create_shape_model, all its derivatives, and determine_shape_model_params in rare cases returned slightly different values on different architectures for the contrast value or the hysteresis contrast values. This problem has been fixed.
  • create_*shape_model*, create_*deformable_model, and create_*component_model in rare cases crashed when all pixels within the domain of the model image had the same gray value and automatic contrast estimation was switched on. This problem has been fixed.
  • create_shape_model_3d sometimes did not create views that are close to the poles of the spherical pose range. In particular this happened if the longitude was restricted to a small range. As a consequence, objects that are imaged from either of the two pole regions could not be found when using find_shape_model_3d. This problem has been fixed. Note that the created 3D shape models might differ in comparison to 3D shape models that were created with earlier HALCON revisions. Therefore, also the matching results might change if the model is recreated. Additionally, create_shape_model_3d returned a wrong error message when passing a 3D object model in ObjectModel3DID that did not contain any faces. In this case the error 8406 ("Error in projection: s_x = 0 or s_y = 0 or z = 0") was returned. This problem has been fixed. Now, the more appropriate new error 8944 ("3D object model does not contain any faces") is returned. Note that programs that evaluate the returned error message must be adapted accordingly.
  • create_shape_model_xld in very rare cases created a shape model where the model contours were interrupted at several positions. This problem has been fixed.
  • create_uncalib_descriptor_model sometimes crashed when the image it was trained on had too few or no point features. This problem has been fixed.
  • detect_edge_segments sometimes crashed if no line segment was found whose length is larger than the minimum length specified in MinLength. This problem has been fixed.
  • dilation_rectangle1 incorrectly returned the error 6001 ("Not enough memory available") for very large regions in HALCON XL. This problem has been fixed.
  • disp_arrow ignored the current line width that was set with the operators dev_set_line_width or set_line_width. Additionally, disp_arrow sometimes returned with an internal error if the arrowhead size was smaller than 1. These problems have been fixed.
  • disp_caltab did not display calibration plates completely for telecentric cameras if the z value of the pose was small. This problem has been fixed.
  • disp_region and dev_display did not display holes of regions if the region fill mode was set to 'margin' and if the output pattern for region contours was not set to a solid line. This problem has been fixed.
  • distance_rr_min_dil in rare cases returned the error 6001 ("Not enough memory available"). This problem has been fixed.
  • distance_transform in some cases did not work correctly if Metric was set to 'euclidean'. The resulting transformation in some cases was erroneous if Foreground was set to 'true' and the input region touched the border of the resulting image, or if Foreground was set to 'false'. This problem has been fixed.
  • div_image returned wrong results for complex images. This problem has been fixed.
  • The operators
    • do_ocr_multi,
    • do_ocr_multi_class_mlp,
    • do_ocr_multi_class_svm,
    • do_ocr_single,
    • do_ocr_single_class_mlp,
    • do_ocr_single_class_svm,
    • do_ocr_word_mlp,
    • do_ocr_word_svm,
    • get_features_ocr_class_mlp,
    • get_features_ocr_class_svm,
    • get_prep_info_ocr_class_mlp,
    • get_prep_info_ocr_class_svm,
    • ocr_get_features, and
    • testd_ocr_class_box

    returned different results if called multiple times and if the feature 'gradient_8dir' was used in combination with at least one of the following features:
    • 'chord_histo',
    • 'pixel',
    • 'pixel_binary',
    • 'pixel_invar',
    • 'projection_horizontal',
    • 'projection_horizontal_invar',
    • 'projection_vertical', or
    • 'projection_vertical_invar'.

    The variation of the results affected mostly the value of the parameter Confidence, but in rare cases it might also have affected the value of the parameter Class. The operators
    • traind_ocr_class_box,
    • trainf_ocr_class_box,
    • trainf_ocr_class_mlp, and
    • trainf_ocr_class_svm

    were also affected. They produced erroneous OCR classifiers if one of the above mentioned combinations of features was used. These problems have been fixed. Note that all OCR classifiers (box, MLP, and SVM) that use the feature 'gradient_8dir' in combination with one of the above mentioned features must be re-trained.

    Additionally, the operators
    • do_ocr_multi_class_mlp,
    • do_ocr_multi_class_svm,
    • do_ocr_single_class_mlp,
    • do_ocr_single_class_svm,
    • do_ocr_word_mlp, and
    • do_ocr_word_svm

    sometimes crashed if the entire character region lay outside the image domain.

    Furthermore, do_ocr_multi_class_mlp and do_ocr_multi_class_svm did not check the number of input images. This problem has been fixed. Now, the error 1502 ("Wrong number of values of object parameter: 2") is returned, if the input image does not consist of exactly one image. Programs in which an image array is passed to do_ocr_multi_class_mlp or do_ocr_multi_class_svm must be adapted accordingly.

    These problems have been fixed.
  • dots_image computed the first channel only when passing multi-channel images. This problem also led to different results when parallelizing on channel level. This problem has been fixed. Now, all channels are computed.
  • The operators
    • edges_image,
    • edges_color,
    • edges_sub_pix, and
    • edges_color_sub_pix

    sometimes returned additional incorrect edges at the border of the image domain if Filter was set to 'sobel_fast'. Additionally, edges_image sometimes crashed when passing object tuples. Furthermore, it accepted multi-channel images although it could not operate on multiple channels. This behavior led to different results when parallelizing on channel level. These problems have been fixed.
  • find_bar_code had the following problems:
    • The check character test of Codabar bar codes failed for the check character '0'.
    • It sometimes could not decode Codabar bar codes although valid scanlines were found. This happened if scanlines near the center could be decoded that did not intersect with the candidate region.
    • It did not decode Composite codes correctly that encode GS1 data starting with '(17)xxxxxx(xx..' or '(11)xxxxxx(xx..'.
    • It sometimes interpreted alpha-numerical data in RSS Expanded or Composite codes incorrectly, e.g., encoded data (17)130900(10)Y123W45 was read like (17)130900(10)0/79D7F3B23. This problem did not appear if the data was only numerical, like (17)130900(10)12345.

    These problems have been fixed.
  • find_data_code_2d had the following problems:
    • In rare cases, it crashed.
    • It caused a memory leak if not enough memory was available.
    • Using the QR data code reader and the gray-value-based matching together in the same application could have caused problems. In particular, calling find_data_code_2d or clear_data_code_2d_model could have caused the deletion of a previously created gray-value-based matching model.

    These problems have been fixed.
  • find_marks_and_pose allowed to set the parameters StartThresh, DeltaThresh, MinThresh, and Alpha to zero although these values should not be used. Especially, if DeltaThresh was set to zero, find_marks_and_pose might have not returned. Additionally, find_marks_and_pose had a memory leak if the orientation of the calibration plate could not be determined (error 8431 ("Orientation of calibration plate could not be determined")). These problems have been fixed.
  • find_ncc_model sometimes crashed if the parameter Image contained an image with a height of 1 pixel. This problem has been fixed.
  • find_planar_calib_deformable_model had the following problems:
    • It did not perform least squares refinement on 64 bit architectures. That is, when setting the generic parameter 'sub_pixel' to 'least_squares', 'least_squares_high', or 'least_squares_very_high', the result was the same as when setting it to 'none'.
    • In rare cases, it crashed, e.g., if small models are searched with a low minimum score and with Metric set to 'ignore_polarity', or if the least-squares adjustment of the pose did not converge.

    These problems have been fixed.
  • find_planar_uncalib_deformable_model did not perform least squares refinement on 64 bit architectures. That is, when setting the generic parameter 'sub_pixel' to 'least_squares', 'least_squares_high', or 'least_squares_very_high', the result was the same as when setting it to 'none'. This problem has been fixed.
  • find_shape_model(s), find_scaled_shape_model(s), and find_aniso_shape_model(s) had the following problems:
    • They ignored the SubPixel-mode 'none' if the increased tolerance mode was used. Instead the SubPixel-mode 'interpolation' was used.
    • In rare cases, they crashed if parallelized automatically. This was only the case if a huge number of candidates was found on the top level of the image pyramid.
    • In very rare cases, the least squares refinement did not work correctly. This especially happened if the model was searched in artificially created images.

    These problems have been fixed.
  • find_shape_model_3d sometimes could not find objects that correspond to views that are close to the poles of the spherical pole range that was passed in create_shape_model_3d. This might have even happened if the corresponding views were contained in the 3D shape model. Additionally, find_shape_model_3d in very rare cases crashed or returned wrong results if the 3D shape model contained model views in which the object appeared very small in the image with an extent of only a few pixels. This problem has been fixed.
  • fit_ellipse_contour_xld allowed the fitting of ellipses to contours with fewer than five points for the algorithms 'voss', 'focpoint', 'fphuber', and 'fptukey'. This may have lead to unspecific error messages. Especially, when the number of contour points minus twice the number of clip points was less than zero, fit_ellipse_contour_xld may have crashed. This problem has been fixed. Now, fit_ellipse_contour_xld does not allow the fitting of ellipses into contours with fewer than five points anymore. Although this was already the case for the algorithms 'fitzgibbon' and 'geometric' and all their derivatives, it is now also true for the algorithms 'voss', 'focpoint', 'fphuber', and 'fptukey'. If your program relies on the behavior that fit_ellipse_contour_xld returns ellipse parameters that represent a straight line when one of the latter algorithms was selected and when the contour has two to four points, you must determine the number of contour points with the operator contour_point_num_xld and, if the contour has two to four points, call the operator fit_line_contour_xld.
  • gauss_distribution did not work for Sigma values smaller than 0.01 even though the documentation stated that Sigma values equal or greater than 0 were allowed. For Sigma values smaller than 0.01 the error 1301 ("Wrong value of control parameter: 1") was returned. This problem has been fixed. Now, values equal or greater than 0 are allowed.
  • gen_arbitrary_distortion_map crashed when the parameter GridWidth was passed a value of zero. This problem has been fixed.
  • gen_binocular_rectification_map and gen_image_to_world_plane_map in rare cases crashed with the polynomial camera model. This was only the case if the input camera parameters were poor (this could be caused by too few input images in camera_calibration). This problem has been fixed. Now, the new error 8441 ("Error in calibration data") is returned.
  • gen_checker_region crashed if the pattern size was not in the valid range. Additionally, gen_checker_region exchanged the error messages of the input control parameters. These problems have been fixed.
  • gen_circle_contour_xld and gen_ellipse_contour_xld sometimes created wrong results with an angle extent of 360 degrees. Instead of the full ellipse, a contour with three identical points was returned. Additionally, for StartPhi=EndPhi and PointOrder='positive', gen_ellipse_contour_xld returned a full ellipse instead of one point. Furthermore, for ellipses with no angle extent, gen_ellipse_contour_xld returned a contour with three identical points. These problems have been fixed. Now, for StartPhi=EndPhi and PointOrder='positive', gen_ellipse_contour_xld no longer returns a full ellipse but only one point.
  • gen_circle_contour_xld crashed with very large circles, i.e., if there was not enough memory available to allocate the number of points required to represent the circle. This problem has been fixed. Now, gen_circle_contour_xld returns the error 3253 ("Maximum contour length exceeded").
  • gen_cooc_matrix returned incorrect values using a reduced domain. This problem has been fixed.
  • gen_cross_contour_xld crashed if an empty tuple was passed in the parameter Angle. This problem has been fixed.
  • gen_ellipse returned a wrong region for special combinations of the parameters Radius1, Radius2, and Phi. This problem has been fixed.
  • get_data_code_2d_result had the following problems with the modularity grade (MOD) if the print quality was assessed according to the AIM DPM-1-2006 standard:
    • For ECC200, MOD was always 4.
    • For QR Code, MOD was always either 3 or 4.

    These grades were reported for symbols with average or bad quality, which should have been graded 0, 1, 2, or 3 instead. Additionally, when assessing the print quality of 2D data codes of type 'Truncated PDF417', the returned 'Start/Stop Pattern' grade sometimes was 0 although the symbol had a good quality. These problems have been fixed.
  • get_deformable_model_params returned angle_end instead of angle_extent. This problem has been fixed.
  • get_region_thickness returned slightly wrong results. Often, the returned thickness was one pixel too small. In some cases, also the number of returned values was incorrect. This problem has been fixed.
  • get_sheet_of_light_result might have returned invalid values (NaN) for pixels outside of the domain of definition. Consequently, subsequent operator calls (especially filtering operators) might have crashed. Additionally, get_sheet_of_light_results crashed when the parameter 'calibration' of the sheet-of-light model was set to 'none' and the operator get_sheet_of_light_results was used to retrieve one of the calibrated results, i.e., when setting the parameter ResultName to 'x','y' or 'z'. These problems have been fixed.
  • The operators
    • gray_erosion_rect,
    • gray_dilation_rect,
    • gray_opening_rect,
    • gray_closing_rect, and
    • gray_range_rect

    computed the first channel only when passing multi-channel images. This problem also led to different results when parallelizing on channel level. This problem has been fixed. Now, all channels are computed. Additionally, gray_erosion_rect,gray_dilation_rect, and gray_range_rect did not return an error for too large mask dimensions, i.e., masks that are too large for the input image. This problem has been fixed as well. Now, the error 3033 ("Filter size exceeds image size") is returned in this case.
  • The operators
    • gray_erosion_shape,
    • gray_dilation_shape,
    • gray_opening_shape, and
    • gray_closing_shape

    had the following problems:
    • They sometimes accepted different values for the parameters MaskHeight and MaskWidth although the MaskShape was 'rhombus' or 'octagon'. They accepted the dimensions if the values rounded up to the next odd integer were equal.
    • They in rare cases returned wrong results if parallelized on domain level and together with tuple/channel parallelization simultaneously. This was the case if parallelization was switched on and the number of threads was bigger than the number of channels or objects in the parameter Image.

    Additionally, gray_erosion_shape and gray_dilation_shape consumed more memory than required if masks with subpixel accuracy were used. These problems have been fixed.
  • gray_range_rect returned an incorrect image for a 1x1 mask if the input image was of type 'byte', 'direction', 'cyclic', or 'uint2', and if the parallelization was turned off. This problem has been fixed.
  • histo_2dim sometimes crashed if 'clip_region' was false and the region extended beyond the image borders. This problem has been fixed.
  • illuminate used the parameters MaskWidth and MaskHeight interchanged. The parameter MaskWidth was used as the mask height and MaskHeight was used as the mask width. This problem has been fixed. Now, the parameter MaskWidth is used as the mask width and MaskHeight is used as the mask height. Note that programs that use illuminate with different values for MaskWidth and MaskHeight must be adapted accordingly.
  • intersection_closed_contours_xld, create_shape_model_3d, and find_shape_model_3d with the generic parameter 'pose_refinement' set to 'least_squares', 'least_squares_high', or 'least_squares_very_high' in very rare cases crashed. This problem has been fixed.
  • lines_facet in extremely rare cases returned wrong results or crashed. This problem has been fixed.
  • lines_gauss did not extract the line width if ExtractWidth = 'true', but CorrectPositions = 'false'. Additionally, lines_gauss in very rare circumstances (very closely spaced lines of small contrast) used an edge of incorrect polarity to determine the line width. These problems have been fixed.
  • mean_image returned wrong results if the mask was in at least one dimension at least as large as the image and if the respective image size was odd. Furthermore, if a tuple of images with different image sizes was used, if the operator parallelization was switched off, and if the mask size exceeded the image size of one of the images in the tuple, the following images of the tuple were smoothed with an incorrect mask size. This problem has been fixed.
  • The operators
    • measure_pos,
    • measure_pairs,
    • fuzzy_measure_pos,
    • fuzzy_measure_pairs, and
    • fuzzy_measure_pairing

    might have returned wrong edge values for very large sigmas (sigma > profile_length/7). This problem has been fixed.
  • measure_profile_sheet_of_light had the following problems:
    • It crashed with a null pointer exception when the sheet-of-light model parameters AmbiguitySolving were set to 'brightest' and ScoreType to 'none' or to 'intensity'.
    • It might have crashed when the domain of definition of the output region exceeded the maximum number of runs. get_sheet_of_light_result was affected as well.
    • It might have erroneously returned the error 6001 ("Not enough memory available"), especially when it was called with images containing no laser light profile and the sheet-of-light model was configured to deliver calibrated measurements. apply_sheet_of_light_calibration was affected as well.
    • It only returned the error 5224 ("Wrong output image size (height)"), when the number of processed profiles exceeded the maximum allowed image size.

    These problems have been fixed. When the number of processed profiles exceeds the maximum allowed image size, now a further low-level error with the advice to use HALCON XL is returned.
  • measure_thresh sometimes put wrong points in front of the resulting coordinates. This problem has been fixed.
  • median_separate in rare cases did not work for MaskWidth=1 for all supported image types except 'byte'. This problem has been fixed.
  • mirror_region with Mode = 'diagonal' crashed for regions with negative coordinates. This problem has been fixed.
  • open_serial could not open serial ports larger than COM9 directly. This problem has been fixed.
  • points_foerstner had a memory leak. The leak appeared when either the number of detected junction points or the number of detected area points was zero. This problem has been fixed.
  • proj_match_points_ransac, proj_match_points_ransac_guided, and zero_crossing_sub_pix do not support the processing of image tuples. Because of that, they had a different behavior when parallelized on tuple level. This problem has been fixed. Now, they cannot be parallelized on tuple level anymore.
  • project_object_model_3d did not return the complete silhouette in some cases. Especially if the parameter HiddenSurfaceRemoval was set to 'false', no silhouette was returned at all. This problem has been fixed.
  • read_contour_xld_dxf and read_polygon_xld_dxf read some elliptical arcs incorrectly such that they were rotated by 180 degrees. This problem has been fixed.
  • read_fft_optimization_data returned the error 3653 ("Storing the optimization data failed") if it was called before any other FFT-related operator (e.g., fft_image, optimize_fft_speed). This problem has been fixed.
  • Unlike other HALCON operators, read_gray_se did not try to read files both with and without automatically appended file name extension (gse), but required the file name to be given without extension. Furthermore, the default search path for filter masks (%HALCONROOT%\filter) was not used if the file name was specified without directory. This problem has been fixed.
  • read_matrix in rare cases did not read ASCII files. Additionally, the message of error 9216 was not correct. These problems have been fixed. The message of error 9216 has been changed from ("Matrix file: Unvalid character") to ("Matrix file: Invalid character"). Programs that evaluate the text of the returned error messages must be adapted accordingly.
  • read_shape_model_3d had a memory leak if the model file could not be opened. This happened if the specified file did not exist, the file had no read permission, the file was no 3D shape model file, or the file had a wrong file version. This problem has been fixed.
  • segment_characters returned an empty tuple in UsedThreshold if the operator was called in tuple mode and -1 if it was called in simple mode, if no characters were segmented. This problem has been fixed. Now, if no characters can be segmented, the parameter UsedThreshold returns -1 for both modes. Note that a single value is returned in tuple mode and in simple mode, even if more than one region is used.
  • The operators
    • send_image,
    • send_region,
    • send_tuple, and
    • send_xld

    by default did not send data immediately, but waited up to 200ms until full data packets were accumulated. This is the default setting of most operating systems. As a result, receive_* operators seemed to take 200ms (or multiples) until returning. This problem has been fixed. Now, the data is transmitted without delay.
  • set_pixel did not work with 32 bit visuals on X Windows. The error 5109 ("Wrong pixel value") was returned. This problem has been fixed.
  • set_serial_param did not support the setting of multiple modes for the parameter FlowControl at the same time. This problem has been fixed. Now, it is possible to set 'xon_xoff', 'cts_rts', and 'dtr_dsr' at the same time by concatenating the single modes separated with a space, e.g., 'cts_rts dtr_dsr'.
  • The results of the operators smallest_circle and smallest_circle_xld were slightly inaccurate on SSE2 and 64 bit architectures with regions or contours that were positioned far away from the origin. Thus, sometimes the results of select_shape, select_shape_xld, and fill_up_shape, when setting Features to 'outer_radius', and the results of shape_trans and shape_trans_xld, when setting Type to 'outer_circle', could have been slightly inaccurate. The error was correlated with the distance of the input contour from the origin, i.e., the error increased with large row or column coordinates. The inaccuracy did not concern Halcon XL. This problem has been fixed.
  • smallest_rectangle2 returned incorrect rectangles for very large regions in HALCON XL. This problem has been fixed.
  • smallest_rectangle2_xld did not return if the input contour consisted of at least two points and if all contour points were identical. This problem has been fixed.
  • split_contours_xld sometimes returned the error 6002 ("Memory partition on heap has been overwritten") when it was called with the parameter Mode set to 'dominant'. This problem has been fixed.
  • trainf_ocr_class_mlp and trainf_ocr_class_svm returned an undefined error if the trainfile contained samples with empty regions. This problem has been fixed.
  • vector_to_pose had the following problems:
    • In rare cases, it did not return.
    • Sometimes, it returned wrong results if the lens distortions were modelled with the polynomial distortion model.
    • If the pose of four non-planar points was determined the method 'analytic' sometimes returned an error.
    • If the z-axis of the object coordinate system being observed was pointing towards the camera the methods 'planar_analytic' and 'planar_analytic_svd' returned a pose that was mirrored behind the camera and the method 'analytic' returned an invalid pose.

    These problems have been fixed. In particular, for the last problem, the problems with the methods 'analytic' and 'planar_analytic' have been fixed and the reference manual entry of vector_to_pose has been extended by a warning that the method 'planar_analytic_svd' may return wrong results if the z-axis of the object coordinate system points towards the camera.
  • zoom_image_size and zoom_image_factor caused artifacts when zooming an image from a small size to a significantly larger size, e.g., from a width of 2 to a width of 30. affine_trans_image and affine_trans_image_size were affected as well. This problem has been fixed.


HALCON/C++

o Bug Fixes:
  • Operators of extension packages under HALCON/C++ might have crashed or returned an HALCON error when called as first operator. This problem has been fixed.
  • There was a memory leak in the object-oriented API of HALCON/C++ when passing iconic object arrays as input parameters. This problem has been fixed.
  • The class HException did not work properly for user exceptions exported from HDevelop (the constructor HException(HTuple) required at least 5 elements). This problem has been fixed.


HALCON/.NET

o Functionality:
  • In contrast to other language interfaces, .NET applications do not run out of the box with a different maintenance release of HALCON unless they are recompiled. When not recompiling, an application configuration file is needed to map the assembly versions. A ready-to-use application configuration file "app.config" under bin\dotnet10 and bin\dotnet20 is now included in HALCON. Furthermore, the documentation has been extended regarding compatibility issues under .NET.


o Bug Fixes:
  • The class HVariationModel did not release all allocated resources when disposed, causing a memory leak. This problem has been fixed.
  • Operators of extension packages under HALCON/.NET might have crashed or raised an exception when called as first operator. This problem has been fixed.


o Examples:
  • The new example "Interoperate" under examples/cpp.net demonstrates the use of a HALCON/C++ DLL from within a HALCON/.NET application using Visual Studio 2005 or higher.
  • The new example "MatchingWPF" under examples/c# demonstrates the use of HALCON in a Windows Presentation Foundation (WPF) application using Visual Studio 2008 or higher.


HALCON/COM

o Bug Fixes:
  • The class HVariationModelX did not release all allocated resources when destroyed, causing a memory leak. This problem has been fixed.


HDevEngine

o Bug Fixes:
  • To load and free programs and procedures in HDevEngine was not thread-safe. If several programs or procedures were loaded and freed in different threads in parallel, the HDevEngine application could have crashed or could have gotten into an undefined state. This problem has been fixed. The following methods were concerned:
    • HDevProgram::HDevProgram(const char* file_name);
    • HDevProgram::~HDevProgram();
    • HDevProgram::operator=(const HDevProgram& hdev_prog);
    • HDevProgram::LoadProgram(const char* file_name);
    • HDevProcedure::HDevProcedure(...);
    • HDevProcedure::~HDevProcedure();
    • HDevProcedure::operator=(const HDevProcedure& proc);
    • HDevProcedure::LoadProcedure(...);

    Additionally, for HDevEngine8 the following methods were concerned:
    • HDevProcedureCall::HDevProcedureCall(const char* file_name);
    • HDevProcedureCall::~HDevProcedureCall();
    • HDevEngine::LoadProgram(const char* file_name);
    • HDevEngine::SetProcedurePath(const char* path);


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 1394IIDC-2 interface to support all IIDC 1394 (FireWire) compliant cameras under Linux. It is based on the latest libdc1394 v2 library and supports in particular also IEEE 1394b cameras. Note that this new interface is the official successor of the existing HALCON 1394IIDC interface for Linux, which is still based on the old libdc1394 v1 library.
    The new HDevelop example programs 1394iidc2.dev, 1394iidc2_2cameras.dev, 1394iidc2_camera_types.dev, 1394iidc2_crop.dev, 1394iidc2_parameters.dev, 1394iidc2_simple.dev, and 1394iidc2_register_access.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.
  • HALCON now also includes the Andor interface to support the scientific cameras from Andor.
    The new HDevelop example programs andor.dev, andor_simple.dev, and andor_parameters.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.
  • HALCON now also includes the Sentech interface to support the STC USB 2.0 cameras from Sentech.
    The new HDevelop example programs sentech.dev, sentech_parameters.dev, sentech_simple.dev, and sentech_trigger.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.
  • HALCON now also includes the SICK-3DCamera interface to support all Ranger and Ruler 3D cameras from SICK including the full access to the calibration and rectification functionality from the SICK icon_API. Note that this new interface is the official successor of the existing HALCON RangerC and RangerE interfaces.
    The new HDevelop example programs sick-3dcamera.dev, sick-3dcamera_calibration.dev, sick-3dcamera_components.dev, sick-3dcamera_parameters.dev, and sick-3dcamera_simple.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.
  • HALCON now also includes the SiliconSoftware interface to support all microEnable III and microEnable IV Camera Link boards from Silicon Software based on the new SDK 5.0.2 under Windows x86 as well as under Windows x64 Editions. Note that this new unified interface is the official successor of the existing HALCON mEnableIII, mEnableIV, and mEnableVisualApplets interfaces which were based on older SDK versions.
    The new HDevelop example programs siliconsoftware.dev, siliconsoftware_simple.dev, siliconsoftware_parameters.dev, and siliconsoftware_continuous.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.
  • HALCON now also includes the SVCam-GigE interface to support the Gigabit Ethernet cameras from SVS-Vistek under Windows x86 as well as under Windows x64 Editions.
    The new HDevelop example programs svcam-gige.dev, svcam-gige_crop.dev, svcam-gige_parameters.dev, svcam-gige_simple.dev, and svcam-gige_trigger.dev in the directory examples/hdevelop/Image/Acquisition show how to use this interface.


o Modified Image Acquisition Interfaces:
  • The source code template hAcqTemplate.c for developing new acquistion interfaces has been extended to show the usage of the parameter Generic in info_framegrabber and open_framegrabber. Additionally, hAcqTemplate.c had some problems. In particular, the function GrabData did not disable the initialization of new image buffers with the value 0 and at the end of GrabData the flag fginst->async_grab was not reset to FALSE. These problems have been fixed.
  • The following HALCON image acquisition interfaces have been revised since HALCON 9.0:
    • The 1394IIDC interface now provides an improved control of the isochronous resource manager. Additionally, a problem concerning a memory leak in grab_image_start and grab_image_async in case that the parameter MaxDelay was explicitly set to a positive value and the grabbed image was actually "too old" has been fixed. Furthermore, the new revision allows to query all supported values for the Generic parameter in open_framegrabber.
    • The BitFlow interface now enables the use of a user-specific callback to indicate that a new image has been grabbed.
    • The Crevis interface now is based on the new Crevis driver V2.0.0.1 and supports the control of digital I/O lines and several new camera types including color models. Furthermore, a problem in grab_image and grab_image_start has been fixed to ensure that pending asynchronous grabs are terminated properly.
    • For the DirectFile interface a problem in positioning the current frame number in case that multiple DirectFile acquisition handles are used simultaneously has been fixed.
    • The DirectShow interface now allows the correct device initialization in special cases.
    • The GigEVision interface is now based on the latest GenICam release v2.0.1 and provides a specific filter driver to increase the performance under Windows x86. Additionally, it now allows the use of up to 65535 image buffers. Furthermore, some problems have been fixed (two of them to prevent a possible crash when increasing the payload size or when reconnecting a previously lost device in a multi-camera setup), and several new parameters and enhancements regarding device discovery, device initialization, and parameter handling have been added. Note that this new revision includes the updated version v1.0.0.2 of the underlying filter driver for Windows x86 which has to be installed seperately.
    • For the GingaDG interface a problem in the operator info_framegrabber when called with the input parameter 'parameters' has been fixed.
    • For the INSPECTA interface a problem in the color conversion for the 32BPP_XBGR pixel format has been fixed.
    • The LinX interface now enables the use of a user-specific callback to indicate that a new image has been grabbed.
    • The MatrixVisionAcquire interface now supports also YUV and additional RGB pixel formats.
    • For the mEnableIII interface and the mEnableIV interface a problem in the operators open_framegrabber, grab_image, grab_image_async, and grab_image_start regarding the use of multiple cameras connected to the same physical board has been fixed. Additionally, new parameters are provided to query the timestamp of the grabbed image and to enable direct device access. Furthermore, the new revisions allow to query all supported values for the Generic parameter in open_framegrabber.
    • The mEnableVisualApplets interface is now based on the driver version 4.2.25 to support the new microEnable IV FULL x4 boards. Additionally, a problem in the operators open_framegrabber, grab_image, grab_image_async, and grab_image_start regarding the use of multiple cameras connected to the same physical board has been fixed. Furthermore, new parameters are provided to query the timestamp of the grabbed image and to enable direct device access.
    • The MILLite interface is now based on the new Matrox SDK Mil-Lite 9.0 and supports also Windows XP/Vista x64 Editions as well as the Solios eCL/XCL-B frame grabber boards. Additionally, the new interface revision allows to explicitly set the number of internally used buffers and to manually control the buffer ordering. Furthermore, now the use of the continuous grabbing mode is provided and several problems have been fixed. These regard external triggering, aborting a pending grab, the use of multiple cameras connected to the same physical board, the use of the action parameter 'do_abort_grab' also in case that no corresponding grab operator is called concurrently, and some problems regarding the parameters of the user-specific callback functions.
    • For the pylon interface two problems regarding the first triggered image in continuous grabbing mode and the exception handling in case of wrong device names have been fixed.
    • The SaperaLT interface now supports also the RGB161616 color format and ensures the correct alignment of BGR101010 pixel data. Additionally, a new action parameter to enable software triggering and new parameters to query the current image size in combination with DALSA boards are provided. Furthermore, problems regarding the use of multiple DALSA Genie cameras, a problem in the operator open_framegrabber when using multiple cameras, and a small memory leak in close_framegrabber have been fixed.
    • For the SonyXCI-2 interface problems regarding the dynamic setting of the actual camera AOI, the control of horizontal binning via the operator set_framegrabber_param, and a problem in controlling the image size and cropping parameters have been fixed.
    • The uEye interface is now based on the new driver version 3.40 and includes several extensions and improvements such as the support of lookup tables and onboard color conversion, new parameters to abort a pending grab and to control the start of the next asynchronous grab, and a revised grab engine to avoid busy waiting. Additionally, now also Windows x64 is supported and new parameters for controlling gain, white balancing, color correction, and for loading a camera parameter ini-file are provided. Furthermore, problems regarding the parameter 'trigger_signal' and the behavior of the operator grab_image have been fixed.

    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 Installation Guide:

The Installation Guide is available in a new edition. It now has an index, which can be accessed also via the tab 'Keywords' in HDevelop.



o HDevelop User's Guide:

The HDevelop User's Guide is now available in a new edition. In particular, the description of the Image Acquisition Assistant has been extended (see also the description of changes for the Image Acquisition Assistant).



o Solution Guide I (Basics):

The Solution Guide I (Basics) is available in a new edition. The section about 1D bar codes has been adapted to the changes of the 1D bar code reader. Amongst others, it now describes the extensions for the print quality assessment.

o Solution Guide II-C on 2D Data Codes:

The Solution Guide II-C on 2D Data Codes is available in a new edition. It has been adapted to describe the extensions for the print quality assessment for 2D data codes.

o Solution Guide III-C on 3D Vision:

The Solution Guide on 3D Vision is available in a new edition. It introduces the use of 3D cameras for sheet-of-light measurements.

o Programmer's Guide:

The Programmer's Guide is available in a new edition. It describes the new ready-to-use application configuration file for .NET applications. Additionally, the section describing the tuple mode in HALCON/C has been restructured and extended.

o Image Acquisition Interface Programmer's Manual:

The description of the operator grab_image_start in the Image Acquisition Interface Programmer's Manual (section 1.6.7) was incorrect. This problem has been fixed.

o HALCON Operator Reference Manual:
  • The index of the german PDF version of the reference manual has been revised.
  • The reference manual contained some C++ examples that contained a header part for which the line "using namespace Halcon;" was missing. Because of that, they could not be compiled without errors. This problem has been fixed.
  • The reference manual entries of most of the HDevelop operators (with prefix 'dev_'), operations (e.g., assign) and control statements were outdated and in some aspects incorrect:
    • For some operators the documented result state was incorrect.
    • Parallelization information was given although this makes no sense for HDevelop internal operators.
    • For the operations 'assign' and 'insert' implications by the full text editor were not mentioned.
    • References to GUI elements of HDevelop that are an alternative for configuring HDevelop, the Graphics window, or opening or closing a window were outdated.
    • The phrases in the attention slot concerning the export restrictions were outdated.
    • The German documentation was incomplete.

    These problems have been fixed.
  • The reference manual entry of affine_trans_region now specifies which type of interpolation is used when the parameter Interpolate is set to 'true'.
  • The reference manual entries of append_ocr_trainf, write_ocr_trainf_image, and write_ocr_trainf referred only to the box classifier. They have been extended to comprise also the MLP and the SVM classifier.
  • The reference manual entry of binocular_calibration contained an erroneous sequence of parameters for the relative pose. This problem has been fixed.
  • The reference manual entries of binocular_disparity and binocular_distance have been extended by details about the use cases of the different correlation methods ('sad', 'ssd', and 'ncc'). Additionally, links to the description of the methods have been added within the reference manual entries of match_essential_matrix_ransac, match_fundamental_matrix_ransac, match_rel_pose_ransac, proj_match_points_ransac, and proj_match_points_ransac_guided.
  • The reference manual entry of clear_obj now explicitly shows that the attention note is only valid for HALCON/C.
  • The reference manual entry of count_obj regarding the system variable 'no_object_result' was incorrect. In particular, it stated that for the case that no input objects are given, the return value of count_obj depends on the state of 'no_object_result'. Actually, the operator ignores the system variable. This problem has been fixed.
  • The reference manual entries of crop_part and crop_rectangle1 contained an incorrect description of the way the rectangular parts are cropped from the images. This problem has been fixed.
  • The reference manual entry of diff_of_gauss did not list the uint2 image format. This problem has been fixed.
  • The reference manual entry of gen_image_surface_first_order now correctly states that a tilted gray surface is created instead of a curved gray surface.
  • The reference manual entries of gen_rectangle2 and gen_circle have been extended. They now explain why a resulting region may contain additional pixels at the border and some individual pixels at the border may be missing.
  • The reference manual entry of gray_range_rect stated that an even valued mask size is changed to the next larger odd value although the value was changed to the next smaller odd value. This problem has been fixed.
  • The reference manual entry of median_image incorrectly described the parameter MaskType as a region. This problem has been fixed. Furthermore, the documentation now describes how a median filter works and shows typical applications of the filter.
  • The reference manual entry of project_3d_point contains an example in which the parameters of affine_trans_point_3d were in the wrong order. This problem has been fixed.
  • The reference manual entry of set_spy now contains a warning that the operator cannot be used to debug multithreaded programs or programs using the automatic operator parallelization.
  • The reference manual entry of test_obj_def now states that the operator is obsolete and must not be used.
  • The reference manual entry of tuple_mult erroneously contained the phrase '... elements of both tuples are subtracted'. The 'subtracted' has been replaced by 'multiplied'.
  • The reference manual entry of vector_to_pose has been extended by a warning that the method 'planar_analytic_svd' may return wrong results if the z-axis of the object coordinate system points towards the camera.


Miscellaneous

o Installation:
  • Under Windows, the new version HASP 4.116 of the USB dongle driver is included.
  • The silent runtime installer now verifies that an architecture selected via the /ARCH flag is actually supported by the CPU.
  • Now, the official runtime version of GenICam v2.0.1 is included. The corresponding files are located in the directory genicam under %HALCONROOT%.
  • Now, a filter driver for the GigEVision interface is included. The corresponding installation files are located in %HALCONROOT%\misc\drivers\win_xp_32.
  • The floating license manager was not installed correctly under Windows x64 Editions. In particular, it could not be started. This problem has been fixed.
  • Under Windows 7, the installation of the USB dongle driver did not work correctly when called from within the HALCON installer. This problem has been fixed.
  • When uninstalling HALCON on a system with different installed HALCON versions, the uninstaller program did not set the environment variables %HALCONROOT%, %HALCONARCH%, and %PATH% such that the instant use of the newest of the remaining installed HALCON versions was possible. This problem has been fixed.


o Example Images:







 
  © Copyright 2010 MVTec Software GmbH - All rights reserved.