Yes, all Basler cameras except the L104k (with 1k and 2k resolution) fulfill the RoHS rules and regulations according to the environmental directive 2002/95/EC.

In pylon4linux 2.3.3, you may get the following error messages when trying to run the pylon viewer (or the SpeedOMeter), even though the PYLON_ROOT and GENICAM_ROOT_V2_1 environment variables and the LD_LIBRARY_PATH were correctly exported:

"PylonViewerApp: symbol lookup error: /usr/lib/libQtNetwork.so.4:
undefined symbol: _ZN14QObjectPribate15checkWindowRoleEv"

In this case, it seems that some of the Qt libraries, i.e., libQtNetwork, were loaded from "/usr/lib" while other Qt libraries were loaded from the local pylon "pylon/bin" folder. Due to a mismatch in the different Qt versions, the pylon viewer will fail to start.

To fix the problem, you must remove (e.g., save them as a backup in a folder on the desktop or delete them permanently) all local Qt libraries and the correspondent links used by the pylon viewer that were placed in "pylon/bin".

The libraries and links (a total of 16) that should be removed are:

libQtCore*
libQtGui*
libQtNetwork*
libQtXml*

Binning increases the camera's sensitivity to light by summing the charges from adjacent pixels in the CCD sensor into one pixel. There are three types of binning available: horizontal binning, vertical binning, and full binning.
 
With horizontal binning, pairs of adjacent pixels in each line of the sensor are summed (see the drawings below). With vertical binning, pairs of adjacent pixels from two lines in the sensor are summed. Full binning is a combination of horizontal and vertical binning in which four adjacent pixels are summed.

Using horizontal or vertical binning generally increases the camera's sensitivity by up to two times normal. Full binning increases sensitivity by up to four times normal. On some camera models, using horizontal or full binning increases the camera's maximum frame rate (this is not true for all cameras and depends on the architecture of the sensor used in the camera).

With horizontal binning active, horizontal image resolution is reduced by half, for example, if a camera's normal horizontal resolution is 1300, with horizontal binning active, this would be reduced to 650. With vertical binning active, vertical image resolution is reduced by half, for example, if a camera's normal vertical resolution is 1030, with vertical binning active, this would be reduced to 515. When full binning is used, both horizontal and vertical resolution are reduced by half.

 

Some users of Basler's Pylon 2.0 software may want to build their own applications without the need to buy Microsoft Visual C++ Studio. Application notes are available that describe a way to build pylon based applications for free using Microsoft Visual C++ Express and the Microsoft Platform SDK.

Click here to download the application notes.

As you may know, applications created with Visual Studio need some Microsoft runtime libraries available to function properly (some dependencies, for example, are the CRT, MFC, and ATL runtime libraries). With Visual Studio 6, the only thing you needed to do to distribute these libraries (DLLs) was to simply place a copy of them in the same folder as your application's executable. With .NET, Microsoft introduced the concept of "assemblies". Assemblies contain all of the required runtime libraries as well as something called "manifest" files. Manifest files contain information about which version of which runtime library is explicitly needed by the application. The MSDN includes a lot of information about assemblies and about deployment of applications created with VS .NET.
 
The simplest way to redistribute the Microsoft runtime libraries is by providing the vcredist_x86.exe redistribution package together with your application. You will find vcredist_x86.exe within the following Visual Studio 8 program folder:
 
<PROGRAM FILES>\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
 
When vcredist_x86.exe is executed on the target machine, all required Microsoft runtime assemblies will be installed in the "global assembly cache" (the WinSXS folder). Your application will then be able to find all of the required C++ runtime libraries, and it will start properly.

Q: Fine, this works for release builds, but I need to deploy a debug build of my application. What should I do?

A: All required debug versions of the runtime libraries come with Visual Studio. According to the Microsoft Visual Studio license agreement, redistribution of the debug versions of the VS runtime libraries is not allowed. To run a debug build of your application, the target machine must have the same version of Visual Studio installed that you used when developing the application.

For distributions other than or newer than those officially supported, however, you needed to install additional libraries such as libXalan-c-110 (not for pylon-*-bininst-* packages), libXerces-c-27 (not for pylon-*-bininst-* packages), or QT 4.3.1 in order to make pylon work. But for these unsupported distributions, the installation of older libraries may "pollute" a system and cause other applications to not work correctly. In addition, once these older libraries are installed, the user must make sure that pylon is correctly linked to the libraries.

All of this made it quite difficult to use pylon on Linux distributions that were not officially supported.

To solve all of these problems, reworked pylon 2.3 packages for 32 bit and 64 bit Linux distributions have been created, and these new packages include all of the libraries that pylon depends on. The packages are called "pylon-2.3.3-1337-32.tar.gz" and "pylon-2.3.3-1337-64.tar.gz". They can be obtained from the Downloads section of the Basler website or from Basler's FTP server:
ftp://Pylon4Linux-ro:h50UZgkl@ftp.baslerweb.com

If you use either of these packages, you will not need to install any additional libraries. You must simply unpack the package according to the README and INSTALL files included in the package and at least set the environment variables appropriately, for example:

#(for 32 bit Linux)
export PYLON_ROOT=/opt/pylon
export GENICAM_ROOT_V2_1=${PYLON_ROOT}/genicam
export LD_LIBRARY_PATH=${PYLON_ROOT}/lib:
${GENICAM_ROOT_V2_1}/bin/Linux32_i86:$LD_LIBRARY_PATH

For more details, refer to the README and INSTALL files included in the package.

In general single-sensor color cameras use a monochrome sensor with a color filter pattern. Another way to achieve a color image with only one sensor would be to use a revolving filter wheel in front of a monochrome sensor, but this method has its limitations.

With the color filter pattern method of color imaging, no object point is projected on more than one sensor pixel, that is, only one measurement (for a single color or sum of a set of colors) can be made for each object point.

There are several different filter methods for generating a color image from a monochrome sensor. In the following some frequently used filter arrangements are detailed.

The following table 1 shows the filter pattern for a sensor of size xs x ys (xs and ys being multiples of 2):

 

 

The following table 2 shows the filter pattern for a sensor of size xs x ys (xs and ys being multiples of 2):

 

 

This is basically the same arrangement as the Bayer filter pattern, but instead of using primary colors (R, G, B) it works with complementary colors (magenta, cyan, yellow). The reason for this is that a primary color filter blocks of 2/3 of the spectrum (i.e. green and blue for a red filter) while a complementary filter blocks only 1/3 of the spectrum (i.e. blue for a yellow filter). Thus, the sensor is 2 times more sensitive. The tradeoff is a somewhat more complicated computation of the R, G, B values, requiring the input of each complementary color.

Table 3 shows the filter pattern for a sensor of size xs x ys (xs being a multiple of 4):

 

 

This arrangement is very simple and basically well suited to machine vision applications. The drawback is that the horizontal resolution is only 1/3 of the vertical resolution.

An ideal camera sensor would convert a known amount of light into an exactly predictable output voltage. Unfortunately, ideal sensors (like all other electronic devices) do not exist. Due to temperature conditions, electronic interference, etc., sensors will not convert light 100% precisely. Sometimes, the output voltage will be a bit bigger than expected and sometimes, it will be a bit smaller. The difference between the ideal signal that you expect and the real-world signal that you actually see is usually called noise. The relationship between signal and noise is called the signal-to-nose ratio (SNR).
 
Signal-to-noise ratio is commonly expressed as a factor such as 20 to 1, 30 to 1, etc. Signal-to-noise ratio is also frequently stated in decibels (dB). The formula for calculating a signal-to-noise ratio in dB is: SNR = 20 x log (Signal/Noise).
 
Once noise has become part of a signal, it can't be filtered or reduced. So it is a good idea to take precautions to reduce noise generation such as:

• using good quality sensors and electronic devices in your camera
• using a good electronic architecture when designing your camera
• lowering the temperature of the sensor and the other analog devices in your camera
• taking precautions to prevent noisy environmental conditions from influencing the signal (such as using shielded cable)

Many times, camera users will increase the gain setting on their cameras and think that they are improving signal-to-noise ratio. Actually, since increasing gain increases both the signal and the noise, the signal-to-noise ratio does not change significantly when gain is increased. Gain is not an effective tool for increasing the amount of information contained in your signal. Gain only changes the contrast of an existing image.

Basler provides two GigE Vision network drivers for interfacing Basler GigE Vision cameras:

• The Basler filter driver is a basic GigE Vision network driver that is compatible with all network adapters. The advantage of the filter driver is its extensive compatibility.
• The Basler performance driver is a hardware specific GigE Vision network driver. The performance driver is only compatible with network adapters that use specific Intel Pro 1000 chipsets ("compatible chipsets"). The advantage of the performance driver is that it significantly lowers the CPU load needed to service the network traffic between the PC and the camera(s). It also has a more robust packet resend mechanism.

 
To take advantage of the benefits of the Basler performance driver, we recommend using Intel Pro 1000 network adapters. These adapters generally work well with the performance driver. However, since the Intel Pro 1000 series has changed over the time, it may happen that the Basler performance driver does not support your particular Intel Pro 1000 adapter.

To make sure that the Pro 1000 network adapter you are using is compatible, consult the table below that lists the currently supported Intel Pro 1000 chipsets and their corresponding Hardware IDs. Note that some chipsets are compatible with pylon version 2.1 or 2.2, but not with version 2.0.
 
In the following table:

     Yes = is compatible
     Yes/M = is compatible but requires manual installation
     No = is not compatible
 

*      This device can also have "82541PI" markings.
**    pylon operation with this chipset is unreliable.
***  These devices can also have "82571GB" or "82572GI" markings (instead of "82571EB"
        or "82572EI"). The 82571GB and 82572GI devices are only used on Intel network
        interface adapters. The 82571GB is functionally equivalent to the 82571EB and the
        82572GI is functionally equivalent to the 82572EI.
†      The Intel Gigabit CT Desktop Adapter uses this chipset, but this adapter does not work
        well with the performance driver. We recommend that you use Intel Pro 1000 series
        adapters.

To check the Hardware IDs for your network adapter:

   1. Click Start > Run.
   2. Type in: devmgmt.msc
   3. Click the OK button. The device manager will start.
   4. Expand the node for Network Adapters.
 

 
   5. Right click on the name of your Intel Pro 1000 adapter
       and select Properties from the drop down menu.
   6. Click the Details tab and make sure that Hardware IDs
       is selected in the drop down list.
 

 
Check the hardware IDs in the list on the Detail Tab against the table that appears earlier in this FAQ. If hardware IDs for your adapter do not match an ID in the table, you must use the Basler filter driver with your network adapter.
 
Customers who happen to acquire an unsupported Intel Pro 1000 network adapter, but who still need to use the Basler performance driver, can contact the Basler support team. The support team will arrange shipment of the non-compatible network adapter to Basler AG and will attempt to get the adapter supported either by creating a hotfix for the performance driver or by including the adapter in the next Basler performance driver release.

February 2012