使用自定义图像格式的奇怪OpenCV问题

时间:2013-12-16 13:17:44

标签: c++ opencv memory compilation ros

我的问题在ROS框架内,但我认为这实际上是一个OpenCV问题。

我的公司有一个我们多年使用的自定义图像数据类型。在ROS中,我需要从ImageConstPtr对象转换为我们的图像格式。作为起点,我在ROS wiki上使用了ROS映像传输订阅示例。它构建并运行良好,即,当收到图像时回调正确执行(在这种情况下,使用压缩传输提示)。但是,如果我声明我公司的image数据类型的变量,我将在.cpp文件中的任何地方调用Rgba - 即使我实际上并没有在任何地方使用它 - 我会在回调触发时得到这个:

[ERROR] [1387198570.300577803, 1386861997.933284812]: /tmp/buildd/ros-groovyopencv2-2.4.6-1precise-20131020-2316/modules/imgproc/src/color.cpp:3346: error: (-215) scn == 3 || scn == 4 in function cvtColor

奇怪的是,我认为只有当我订阅压缩传输主题时才会发生这种情况,尽管我需要重新验证它并且我没有包含raw或theora数据的包。

编辑:此代码工作正常(即输出重复打印输出“Callback suceeded!”):

#include <ros/ros.h>
#include <image_transport/image_transport.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
#include <cv_bridge/cv_bridge.h>

void imageCallback(const sensor_msgs::ImageConstPtr& msg)
{
  ROS_WARN_STREAM("Callback succeeded!");
}

int main(int argc, char **argv)
{
  ros::init(argc, argv, "image_listener");
  ros::NodeHandle nh;

  image_transport::ImageTransport it(nh);
  image_transport::Subscriber sub = it.subscribe("camera/image", 1, imageCallback);
  ros::spin();
}

此代码给出了上述错误:

#include <ros/ros.h>
#include <image_transport/image_transport.h>
#include <opencv/cv.h>
#include <opencv/highgui.h>
#include <cv_bridge/cv_bridge.h>
#include <custom_image.h> 

custom_image img_;  // This line causes the error displayed above. The callback never fires.

void imageCallback(const sensor_msgs::ImageConstPtr& msg)
{
  ROS_WARN_STREAM("Callback succeeded!");
}

int main(int argc, char **argv)
{
  ros::init(argc, argv, "image_listener");
  ros::NodeHandle nh;

  image_transport::ImageTransport it(nh);
  image_transport::Subscriber sub = it.subscribe("camera/image", 1, imageCallback);
  ros::spin();
}

可能会发生什么?我的第一个想法是,我们有一些同名的类或结构干扰OpenCV,或者我们的底层图像表示错误地管理内存。奇怪的是,只要我声明变量就会发生这种行为。如果我将它声明为指针,它就不会发生,但是只要我编写一个取消引用该指针的函数 - 再次,即使我不调用该函数 - 我也会收到此错误。一旦删除对图像类型的任何引用,问题就会消失。

有什么想法吗?

1 个答案:

答案 0 :(得分:0)

我明白了。我们的自定义图像数据类型具有libjpeg依赖性,OpenCV也是如此。版本不一样,因此在声明自定义数据类型的图像时,链接器使用我们的libjpeg版本而不是OpenCV,我们得到原始问题中描述的行为。