Linux和Windows构建的应用程序之间的OpenCV行为差异

OpenCV behavior differences between Linux and Windows built application

本文关键字：OpenCV 应用程序 Windows 构建 Linux 之间      更新时间：2023-10-16

我在Windows上编写并测试了一个使用OpenCV进行图像评估的应用程序。使用OpenCV 3.1.0，使用MinGW-W64 5.3.0编译。

现在，我已经克隆了这个应用程序，并在Linux环境中构建和测试了它。我先在Raspberry Pi上做了这个测试(Raspian Jessie)，然后在我的笔记本电脑上做了这个测试(Ubuntu 16.04, g++ 5.4.0)。我评估了相同的图像，得到了不同的结果。

有太多的代码，我发布和期望每个人排序，所以我的基本问题是，有什么是我应该特别寻找?现在我正在我的笔记本电脑上调试它，但是如果有人在过去有过类似的经历，并且知道要立即寻找的东西，可以节省我一些时间。

感谢

我应该提到我使用的函数:

cv::cvtColor
cv::Blur
cv::Canny
cv::FindContours
cv::fitLine
cv::fitEllipse

图片加载可能是其中一种情况。请尝试匹配windows &linux或mac后的imread。基于不同的版本&编解码器安装在机器上，它可以变化很小。这种像素值不匹配可能发生在jpg、png、tiff等压缩图像格式中。对于未压缩的格式，如pgm, bmp或原始格式，不应该发生这种情况。请阅读opencv文档中的以下行:

1/该函数根据内容而不是文件扩展名来确定图像的类型。

2/在Microsoft Windows OS和MacOSX上，默认使用OpenCV映像附带的编解码器(libjpeg, libpng, libtiff和libjasper)。所以，OpenCV总是可以读取jpeg, png和tiff。在MacOSX上，也有一个使用本机MacOSX图像阅读器的选项。但要注意，由于MacOSX中嵌入的颜色管理，目前这些本地图像加载器提供的图像具有不同的像素值。

3/在Linux, BSD风格和其他类unix的开源操作系统上，OpenCV寻找与操作系统映像一起提供的编解码器。安装相关软件包(不要忘记开发文件，例如，Debian和Ubuntu中的" libjpeg-dev ")以获得编解码器支持或在CMake中打开OPENCV_BUILD_3RDPARTY_LIBS标志。

链接

我发现差异与OpenCV无关，是函数"std:: fpclassifier "的行为，我正在检查一条线的斜率是否为"NaN"。我将结果与"1024"进行比较，看看它是否是一个有效的正常数字，即enum"FP_NORMAL"。但是，在linux中编译时，"FP_NORMAL"等于4而不是1024!问题解决了。

根据您提供的少量信息，我可以告诉您OpenCV算法和函数是独立于平台的。OpenCV文档中提到的唯一内容是:

可移植性，外部依赖

在形式上，代码必须符合c++ 98标准。不建议在实现级别使用c++ 11或TR1扩展，并且禁止在外部头文件中使用它。应该摆脱依赖编译器或平台的结构和系统调用，例如:

  • 编译器编译指示的
  • 特定关键字，例如__stdcall， __inline， __int64(或long long)。分别使用CV_INLINE(或c++代码中的简单内联)，CV_STDCALL(如果可能的话尽量避免使用)，int64。
  • 编译器扩展，例如min和max的特殊宏，重载宏等
  • 内联汇编
  • Unix或win32特定的调用，例如bcopy, readdir, CreateFile, WaitForSingleObject等
  • 具体的数据大小代替sizeof's (sizeof(int)而不是4)，字节顺序((int)"x1x2x3x4"是0x01020304或0x04030201或什么?)，简单的字符而不是有符号字符或无符号字符，除了文本字符串。使用简短形式uchar表示无符号字符，使用简短形式schar表示有符号字符。使用预处理器指令来封装不可移植的代码。

来源:这里

试着看看你的代码中是否有什么是平台相关的。在我看来(但这只是一种感觉)，可能它与OpenCV Mats中的数字表示有关。试着看看是否有东西依赖于平台int大小或float大小…

相关文章：