0
$\begingroup$

Rosanswers logo

Hello,

I just got a couple of cameras for stereo vision. I calibrated them with camera_calibration. I got the ost.txt file which looks like this:

# oST version 5.0 parameters


[image]

width
640

height
480

[stereo/left]

camera matrix
2936.789087 0.000000 583.498064
0.000000 2865.839793 254.251806
0.000000 0.000000 1.000000

distortion
-0.224767 -2.059623 -0.000719 0.023231 0.000000

rectification
0.779954 0.219443 -0.586102
-0.092957 0.966743 0.238258
0.618894 -0.131348 0.774414

projection
7412.660530 0.000000 6128.045624 0.000000
0.000000 7412.660530 -855.670516 0.000000
0.000000 0.000000 1.000000 0.000000

# oST version 5.0 parameters


[image]

width
640

height
480

[stereo/right]

camera matrix
2822.855469 0.000000 113.685666
0.000000 2746.930572 199.606104
0.000000 0.000000 1.000000

distortion
-0.986390 4.581731 0.017456 0.010306 0.000000

rectification
0.146495 0.250593 -0.956944
-0.488950 0.859289 0.150169
0.859923 0.445898 0.248409

projection
7412.660530 0.000000 6128.045624 -86524.314248
0.000000 7412.660530 -855.670516 0.000000
0.000000 0.000000 1.000000 0.000000

That file I separated left and right .ini and .yaml:

left.ini: # oST version 5.0 parameters

[image]

width
640

height
480

[nstereo/left]

camera matrix
2936.789087 0.000000 583.498064
0.000000 2865.839793 254.251806
0.000000 0.000000 1.000000

distortion
-0.224767 -2.059623 -0.000719 0.023231 0.000000

rectification
0.779954 0.219443 -0.586102
-0.092957 0.966743 0.238258
0.618894 -0.131348 0.774414

projection
7412.660530 0.000000 6128.045624 0.000000
0.000000 7412.660530 -855.670516 0.000000
0.000000 0.000000 1.000000 0.000000

right.ini:

# oST version 5.0 parameters


[image]

width
640

height
480

[stereo/right]

camera matrix
2822.855469 0.000000 113.685666
0.000000 2746.930572 199.606104
0.000000 0.000000 1.000000

distortion
-0.986390 4.581731 0.017456 0.010306 0.000000

rectification
0.146495 0.250593 -0.956944
-0.488950 0.859289 0.150169
0.859923 0.445898 0.248409

projection
7412.660530 0.000000 6128.045624 -86524.314248
0.000000 7412.660530 -855.670516 0.000000
0.000000 0.000000 1.000000 0.000000

And with rosrun camera_calibration_parsers convert left.ini left.yaml and rosrun camera_calibration_parsers convert right.ini right.yaml I obtained the .yaml.

Once I launched the node with the embedded drivers for my cameras ueye_cam node I echoed the camera_info topic from both cameras and I got every data according to the calibration.

Then I ran ROS_NAMESPACE=stereo rosrun stereo_image_proc stereo_image_proc and the images obtained (raw_image directly from the driver's node, rectified and mono from stereo_image_proc) are shown below:

images http://i64.tinypic.com/21d4qxs.png

First of all, master camera is rotated 90 deg clockwise and slave is rotated 90 counter clockwise. The calibration was with the chessboard pattern farther from the two objects I'm showing in the picture. Therefore, they were in focus. You can see that the rectified images are completely black, but the mono images (which come from stereo_image_proc, right?) are showing.

Is this issue because the cameras are rotated? Should I do rotate them so the have the same orientation before I do the calibration or I will obtain the rectified images already rotated? Can the problem come from the fact that images don't have the exact time stamp and I had to do rosrun camera_calibration cameracalibrator.py --size 8x6 --square 0.108 left:=/stereo/left/image_raw right:=/stereo/right/image_raw left_camera:=/stereo/left right_camera:=/stereo/right --approximate=0.1? Even though this is weird because I can check the timestamps:

Timestamp Master: 1449673594.512000000
Timestamp Slave: 1449673594.512000000
frame : 1

Timestamp Master: 1449673594.812000000
Timestamp Slave: 1449673594.812000000
frame : 2

Timestamp Master: 1449673595.145000000
Timestamp Slave: 1449673595.145000000
frame : 3

Timestamp Master: 1449673595.479000000
Timestamp Slave: 1449673595.479000000
frame : 4

Timestamp Master: 1449673595.779000000
Timestamp Slave: 1449673595.779000000
frame : 5

Timestamp Master: 1449673596.79000000
Timestamp Slave: 1449673596.79000000
frame : 6

Timestamp Master: 1449673596.379000000
Timestamp Slave: 1449673596.379000000
frame : 7

Timestamp Master: 1449673596.646000000
Timestamp Slave: 1449673596.646000000
frame : 8

Timestamp Master: 1449673596.946000000
Timestamp Slave: 1449673596.946000000
frame : 9

Timestamp Master: 1449673597.212000000
Timestamp Slave: 1449673597.212000000
frame : 10

Timestamp Master: 1449673597.513000000
Timestamp Slave: 1449673597.512000000
frame : 11

Timestamp Master: 1449673597.813000000
Timestamp Slave: 1449673597.813000000
frame : 12

Timestamp Master: 1449673598.113000000
Timestamp Slave: 1449673598.113000000
frame : 13

Timestamp Master: 1449673598.413000000
Timestamp Slave: 1449673598.413000000
frame : 14

Timestamp Master: 1449673598.713000000
Timestamp Slave: 1449673598.713000000
frame : 15

Thanks for the help.


Originally posted by Ariel on ROS Answers with karma: 65 on 2015-12-09

Post score: 0


Original comments

Comment by lucasw on 2015-12-10:
You could try running undistortPoints on some sample points like the center of the image, and the four corners, to see if those calibrations are reasonable. Is the calibration process stereo-aware? Maybe try calibrating a single camera and rectifying without any stereo stuff running.

Comment by Ariel on 2015-12-13:
I'm out for holidays now. I'll calibrate them separately when I get back. But shouldn't I have something to project both images to a common plane for the sterevision? And what about the extrinsic parameters then?

Comment by Miquel Massot on 2015-12-28:
In my opinion, your calibration looks wrong. The cx and cy terms should be close to the half of the resolution. Try to attach the calibration pattern to a rigid surface (wood) and repeat the calibration. Don't move the cameras, move the pattern instead, and focus the cameras.

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

I did the calibration again, this time separately, one camera at a time. They were fixed on the table and I moved the calibration pattern, which is attached to a rigid surface. I also changed the resolution of the cameras so as to have the biggest resolution they can. The results seem similar for the camera matrix, but the distortion values are not all the same and the rectification matrix is always the identity......is that correct.....?. Here are the new values:

left:

# oST version 5.0 parameters


[image]

width
1280

height
1024

[narrow_stereo]

camera matrix
2295.015272 0.000000 640.541295
0.000000 2303.682687 471.554511
0.000000 0.000000 1.000000

distortion
-0.465980 -0.188907 0.003472 0.003497 0.000000

rectification
1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000

projection
2199.656494 0.000000 642.325188 0.000000
0.000000 2244.262207 470.208280 0.000000
0.000000 0.000000 1.000000 0.000000

right:

# oST version 5.0 parameters


[image]

width
1280

height
1024

[narrow_stereo]

camera matrix
2339.253648 0.000000 634.067723
0.000000 2347.476009 479.539465
0.000000 0.000000 1.000000

distortion
-0.444712 -0.188235 0.000477 0.002607 0.000000

rectification
1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000

projection
2250.488770 0.000000 634.664472 0.000000
0.000000 2291.515381 477.643991 0.000000
0.000000 0.000000 1.000000 0.000000

Thanks again for the help!

EDIT 1: Seems to be ok. These are the rectified images and the disparity image I get after running:

ROS_NAMESPACE=stereo rosrun stereo_image_proc stereo_image_pcoc
rosrun image_view stereo_view stereo:=stereo image:=image_rect_color

And here is the result: image description http://i68.tinypic.com/9plshk.png http://oi68.tinypic.com/9plshk.jpg

Is the disparity image correct?

As one camera is rotated clockwise and the other counter-clockwise, what would be the best way to have the images rotated? Should they be rotated 'before' or 'after' the stereo_proc node? I mean, should I rotate the raw images I get directly from the cameras to be inputs of stereo_proc node? Again, thanks a lot for the help!

EDIT 1: I rotated the cameras by subscribing to the original /stereo/{left,right}/image_raw and publishing them on another topic like this:

#include <ros/ros.h>
#include <image_transport/image_transport.h>
#include <sensor_msgs/image_encodings.h>
#include <sensor_msgs/Image.h>

#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <cv_bridge/cv_bridge.h>

cv::Mat dst;

/* Subscribe and Publish class: http://answers.ros.org/question/59725/publishing-to-a-topic-via-subscriber-callback-function/ */
/* Publish image: http://answers.ros.org/question/192959/how-to-publish-and-sub-camera-in-opencv/ */

class SubscribeAndPublish
{
    public:
        SubscribeAndPublish()
        {
            //Topic to Subscribe
            subMasterImage_ = n_.subscribe("stereo/left/image_raw", 1, &SubscribeAndPublish::callbackMaster, this);
            subSlaveImage_ = n_.subscribe("stereo/right/image_raw", 1, &SubscribeAndPublish::callbackSlave, this);

            //Topic to Publish
            pubMasterImage_ = n_.advertise<sensor_msgs::Image>("stereorotated/left/image_raw", 1);
            pubSlaveImage_ = n_.advertise<sensor_msgs::Image>("stereorotated/right/image_raw", 1);
        }

        void callbackMaster(const sensor_msgs::ImageConstPtr& input)
        {
            cv_bridge::CvImage rotatedimage;
            try
            {
                // Rotate Counter-Clockwise
                cv::transpose(cv_bridge::toCvShare(input, "bgr8")->image, dst);
                cv:flip(dst, dst, 0);
                //cv::imshow("Left (Master) Rotated", dst);

                // Publish rotated image
                rotatedimage.header.seq = cv_bridge::toCvShare(input, "bgr8")->header.seq;
                rotatedimage.header.stamp = cv_bridge::toCvShare(input, "bgr8")->header.stamp;
                rotatedimage.header.frame_id = cv_bridge::toCvShare(input, "bgr8")->header.frame_id;
                rotatedimage.encoding = cv_bridge::toCvShare(input, "bgr8")->encoding;
                rotatedimage.image = dst;
                pubMasterImage_.publish(rotatedimage.toImageMsg());

                //cv::waitKey(30);
            }
            catch (cv_bridge::Exception& e)
            {
                ROS_ERROR("Could not convert from '%s' to 'bgr8'.", input->encoding.c_str());
            }
        }

        void callbackSlave(const sensor_msgs::ImageConstPtr& input)
        {
            cv_bridge::CvImage rotatedimage;
            try
            {
                // Rotate Counter-Clockwise
                cv::transpose(cv_bridge::toCvShare(input, "bgr8")->image, dst);
                cv:flip(dst, dst, 1);
                //cv::imshow("Right (Slave) Rotated", dst);

                // Publish rotated image
                rotatedimage.header.seq = cv_bridge::toCvShare(input, "bgr8")->header.seq;
                rotatedimage.header.stamp = cv_bridge::toCvShare(input, "bgr8")->header.stamp;
                rotatedimage.header.frame_id = cv_bridge::toCvShare(input, "bgr8")->header.frame_id;
                rotatedimage.encoding = cv_bridge::toCvShare(input, "bgr8")->encoding;
                rotatedimage.image = dst;
                pubSlaveImage_.publish(rotatedimage.toImageMsg());

                //cv::waitKey(30);
            }
            catch (cv_bridge::Exception& e)
            {
                ROS_ERROR("Could not convert from '%s' to 'bgr8'.", input->encoding.c_str());
            }
        }

    private:
        ros::NodeHandle n_; 
        ros::Subscriber subMasterImage_;
        ros::Subscriber subSlaveImage_;
        ros::Publisher pubMasterImage_;
        ros::Publisher pubSlaveImage_;
};

int main(int argc, char **argv)
{
    //Initiate ROS
    ros::init(argc, argv, "subscribe_and_publish");

    //Create an object of class SubscribeAndPublish that will take care of everything
    SubscribeAndPublish SAPObject;

    ros::spin();

    return 0;
}

This leaves me with this topics:

ariel@ariel-GT70:~$ rostopic list 
/nodelet_manager/bond
/rosout
/rosout_agg
/stereo/left/image_raw
/stereo/left/image_raw/compressed
/stereo/left/image_raw/compressed/parameter_descriptions
/stereo/left/image_raw/compressed/parameter_updates
/stereo/left/image_raw/compressedDepth
/stereo/left/image_raw/compressedDepth/parameter_descriptions
/stereo/left/image_raw/compressedDepth/parameter_updates
/stereo/left/image_raw/theora
/stereo/left/image_raw/theora/parameter_descriptions
/stereo/left/image_raw/theora/parameter_updates
/stereo/right/image_raw
/stereo/right/image_raw/compressed
/stereo/right/image_raw/compressed/parameter_descriptions
/stereo/right/image_raw/compressed/parameter_updates
/stereo/right/image_raw/compressedDepth
/stereo/right/image_raw/compressedDepth/parameter_descriptions
/stereo/right/image_raw/compressedDepth/parameter_updates
/stereo/right/image_raw/theora
/stereo/right/image_raw/theora/parameter_descriptions
/stereo/right/image_raw/theora/parameter_updates
/stereorotated/left/camera_info
/stereorotated/left/image_raw
/stereorotated/right/camera_info
/stereorotated/right/image_raw
/ueye_cam_nodelet_left/parameter_descriptions
/ueye_cam_nodelet_left/parameter_updates
/ueye_cam_nodelet_right/parameter_descriptions
/ueye_cam_nodelet_right/parameter_updates

Note that I have also remapped camera_info for both left and right in the launch file of the ueye_cam node (camera's node that embeds the drivers and streams the raw data from the cameras). This is done with:

For 'left' node:

<remap from="stereo/left/camera_info" to="stereorotated/left/camera_info"/>

For 'right' node:

<remap from="stereo/right/camera_info" to="stereorotated/right/camera_info"/>

But when I check the service list:

ariel@ariel-GT70:~$ rosservice list 
/nodelet_manager/get_loggers
/nodelet_manager/list
/nodelet_manager/load_nodelet
/nodelet_manager/set_logger_level
/nodelet_manager/unload_nodelet
/rosout/get_loggers
/rosout/set_logger_level
/rostopic_7724_1452692308835/get_loggers
/rostopic_7724_1452692308835/set_logger_level
/rostopic_7904_1452692311248/get_loggers
/rostopic_7904_1452692311248/set_logger_level
/rotateimages/get_loggers
/rotateimages/set_logger_level
/stereo/left/image_raw/compressed/set_parameters
/stereo/left/image_raw/compressedDepth/set_parameters
/stereo/left/image_raw/theora/set_parameters
/stereo/left/set_camera_info
/stereo/right/image_raw/compressed/set_parameters
/stereo/right/image_raw/compressedDepth/set_parameters
/stereo/right/image_raw/theora/set_parameters
/stereo/right/set_camera_info
/ueye_cam_nodelet_left/get_loggers
/ueye_cam_nodelet_left/set_logger_level
/ueye_cam_nodelet_left/set_parameters
/ueye_cam_nodelet_right/get_loggers
/ueye_cam_nodelet_right/set_logger_level
/ueye_cam_nodelet_right/set_parameters

The service is not mapped. Therefore, when I launch the stereo calibration:

ariel@ariel-GT70:~$ rosrun camera_calibration cameracalibrator.py --size 8x5 --square 0.28 right:=/stereorotated/right/image_raw left:=/stereorotated/left/image_raw right_camera:=/stereorotated/right left_camera:=/stereorotated/left 
('Waiting for service', '/stereorotated/left/set_camera_info', '...')
Service not found
('Waiting for service', '/stereorotated/right/set_camera_info', '...')
Service not found

And this big issue is because I have to publish the rotated images to a different topic....

EDIT 2:

New stereo calibration values with the rotated images:

# oST version 5.0 parameters


[image]

width
1024

height
1280

[stereo/left]

camera matrix
2347.501238 0.000000 566.244722
0.000000 2360.705173 625.648821
0.000000 0.000000 1.000000

distortion
-0.430007 -0.495300 0.001297 0.002357 0.000000

rectification
0.997911 0.001374 -0.064587
-0.000939 0.999977 0.006754
0.064594 -0.006679 0.997889

projection
2514.350972 0.000000 692.550152 0.000000
0.000000 2514.350972 604.610306 0.000000
0.000000 0.000000 1.000000 0.000000

# oST version 5.0 parameters


[image]

width
1024

height
1280

[stereo/right]

camera matrix
2372.295159 0.000000 554.061673
0.000000 2379.084533 588.899574
0.000000 0.000000 1.000000

distortion
-0.475190 -0.138807 0.002383 0.000582 0.000000

rectification
0.999106 -0.000290 -0.042282
0.000005 0.999977 -0.006722
0.042283 0.006715 0.999083

projection
2514.350972 0.000000 692.550152 -2523.386833
0.000000 2514.350972 604.610306 0.000000
0.000000 0.000000 1.000000 0.000000

Originally posted by Ariel with karma: 65 on 2016-01-12

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by lucasw on 2016-01-18:
There ought to be a standard image flip/rotate90/180/270 nodelet. (image_rotate isn't right for that when arbitrary rotations aren't needed) It would be great to get one added to image_proc.

Comment by lucasw on 2016-01-18:
The two separate calibrations look reasonable, I should have been clearer before but that is mainly a sanity check - if you can calibrate the cameras individually and run image rectification on them then you have a much better chance of doing stereo, but you still have to do a stereo calibration.

Comment by Ariel on 2016-01-19:
If I calibrate them individually and the do the stereo calibration, how do I 'merge' the result?

Comment by Ariel on 2016-01-19:
Other thing is that I can physically measure that the baseline is 10cm. Therefore, if I use the values from right P I should get the same number (4319.6/4243.1=1.01), right?(which I don't...). Considering (-right_.Tx/right_.fx). Therefore, I can check that the stereo calibration is not correct?

Comment by lucasw on 2016-01-20:
Can you run opencv decomposeProjectionMatrix on the right P matrix to get the translation calculated for you? (I'm not sure if there are ros vs. opencv P matrix differences) It ought to give you consistent units with however you defined the chessboard intersections.

$\endgroup$
0
$\begingroup$

Rosanswers logo

Looking at the images it appears you have two cameras with long focal length/high zoom. What is also readily apparent is that they have only a very small area of overlap, as the small "IDS box" is on the far right edge of the left camera image and on the far left edge of the right camera image. Valid distance (and calibration) data can only be estimated in the area of overlap, so stereo calibration might fail because of this small overlap (I'm actually surprised that it allowed you to optimize at all, as normally the "calibrate" button only becomes enabled when enough image area has been sampled).

I'm not sure if and how stereo calibration can cope with rotated cameras, so I'd recommend to rotate them before feeding them to calibration (or rectification later).

Note that calibrating both cameras standalone allows for rectifying their images, but not for proper stereo computation as there is no way to know the transform between both cameras in that case.


Originally posted by Stefan Kohlbrecher with karma: 24361 on 2016-01-12

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by Ariel on 2016-01-12:
As you said, the focal length is 12mm.It gives a small area of overlap. Could have been a non flat calibration patter the issue before? I'm in the process of writing a node to rotate the images, following the image transport tutorials and cv transpose and flip functions.Any better idea?Thanks again.

Comment by Stefan Kohlbrecher on 2016-01-12:
Yes, non-flat calibration patterns will result in larger calibration error when using calibration patterns that use flat checkerboard calibration targets. Re rotation: This should be a good start: https://github.com/ros-perception/image_pipeline/tree/indigo/image_rotate/src/nodelet

Comment by Ariel on 2016-01-12:
According to its documentation, it says: It is not recommended to use the output from this node for further computation, as it interpolates the source image, introduces black borders, and does not output a camera_info. I don't know then if I should use that....

Comment by Stefan Kohlbrecher on 2016-01-12:
What I meant is using the code (camera callback, nodelet structure etc.), throwing out all the complicated tf/rotation stuff and adding a simple cv transpose/flip at the right place :)

Comment by Ariel on 2016-01-12:
Right! My bad! I'll get to it and come back with the results after stereo calibrating with the images rotated!

Comment by Ariel on 2016-01-13:
I rotated the images using this. Originally I had stereo/{L,R}/{image_raw,camera_info}. I read the image and publish it on rotated/{L,R}/image_raw but still have issues with camera_info now. Can i remap?

Comment by Stefan Kohlbrecher on 2016-01-13:
Uhm yes, you probably need to remap the CameraInfos, because the resolution will be mixed up if you don't do so. OTOH if you calibrate using the rotated images and update the CameraInfo, things should start working.

Comment by Ariel on 2016-01-13:
I remapped the topic in the launch file of the camera, but not the service. Is it possible to do so without renaming the whole NAMESPACE?

Comment by Stefan Kohlbrecher on 2016-01-13:
Remapping works for topics, services and parameters. I'm not sure what exactly you're doing right now, but it might be easiest if you just remap everything one by one and once that works look into making things look nicer.

Comment by Ariel on 2016-01-13:
I have mapped CameraInfo so and published the rotated images with the same 'prefix' but when I launch the calibration app I get ('Waiting for service', '/rotated/left/set_camera_info', '...'). Service not found because the topic was remapped and not the topic. I did it in the launch file (Cont'd)

Comment by Ariel on 2016-01-13:
remapped each node (left and right) with /. I'd better post a new answer to make it more clear.....

Comment by Stefan Kohlbrecher on 2016-01-13:
Please don't post answers, instead edit your question. Things otherwise become pretty confusing to readers :)

Comment by Stefan Kohlbrecher on 2016-01-13:
You need to remap the services, too.

Comment by Ariel on 2016-01-13:
Of course I forgot the dumbest thing to do...remap the service! Agh!! Ok, not it's done and I can see the disparity image with the rotated raw images when calibrating. I could have been that and/or a bad calibration pattern. This is the disparity image.Too gray?

Comment by Stefan Kohlbrecher on 2016-01-13:
Have a look at http://wiki.ros.org/stereo_image_proc/Tutorials/ChoosingGoodStereoParameters. You should especially vary and step through different values for the "min_disparity" parameter.

Comment by Ariel on 2016-01-14:
I played around on with the values and I got this result.. It's slightly better I guess. Note that I had to switch to StereoSGBM algorithm, but still I cannot see the pointcloud. I believe it's all the same issue, isn't it?

Comment by Ariel on 2016-01-14:
This answer suggests to check the calibration score. Could it be that the new calibration is not so good?. It's published in the EDIT 2....

Comment by Ariel on 2016-01-14:
Also what happens if I run the calibration at 1280x1024 and the change it to 512x512 when I check the disparity and pointcloud? Could that be the reason?

Comment by Stefan Kohlbrecher on 2016-01-14:
That result looks somewhat reasonable. Interesting you got SGBM to work, it didn't work for me before. I don't see any immediate fault with the calibration (then again I'm no expert on that). You could try calibrating multiple times and see how big the variance between calibration runs is.

Comment by Ariel on 2016-01-14:
I did 4 calibrations again. With the original images and then rotated, also with two different resolutions. The black rectified images are when using the original images (which remember, left is rotated clockwise and right counter-clockwise). Rotating images with the node and performing the .....

Comment by Ariel on 2016-01-14:
....calibration I can get the rectified images. I does not seem to affect the different resolutions. The issue still is the disparity image, even after playing with the parameters such as "min_disparity" (Disp 1 Disp 2)

Comment by Stefan Kohlbrecher on 2016-01-14:
The stereo data doesn't look very dense, but somewhat reasonable. There is no texture in much of the scene and only low overlap between cameras, which explains some of the sparsity. I see you have minmal disparity range set, which limits the band for which distances can be estimated.

Comment by Ariel on 2016-01-15:
It also seems that even though exposure and gain for both cameras are the same, images are not equal.....anyways, as I was able to get the rectified images by rotating the raw images I'll close the question. Thank you Stefan for your help!

Comment by Stefan Kohlbrecher on 2016-01-18:
There might be other settings that affect image appearance. Not sure how robust the OpenCV stereo processing is to brightness/saturation differences in both images. You could also try http://wiki.ros.org/elas_ros and see how well it works.

Comment by Ariel on 2016-01-18:
I have been pointed out that the images are not the same (exposure/gain). So I checked it with the api from the manufacturer (test and there is a diff. between pics. Could the cameras be the issue? I'll try the elas node that you suggested. Thanks again!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.