|
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)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
HDevelop:
-
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
-
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.
-
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.
-
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:
-
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.
-
New Image Acquisition Interfaces:
HALCON has been extended by the following new image acquisition
interfaces:
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
- Functionality
- Bug Fixes
- Examples
-
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.
-
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.
-
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.
- Enhancements
- Modified Operators
- Bug Fixes
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Bug Fixes:
-
The class HVariationModelX did not release all allocated resources
when destroyed, causing a memory leak. This problem has been
fixed.
-
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);
-
The latest information about new extensions and newly supported
image acquisition devices can be found on MVTec's web
server.
-
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.
-
Modified Image Acquisition Interfaces:
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Example Images:
|
|